Hallo,
wirklich viele Betroffene scheint’s nicht zu geben, sonst müsste man mehr im Internet darüber finden. Vielleicht findet von euch Käpsele ja jemand des Rätsels Lösung.
https://forum.ubuntuusers.de/topic/veracrypt-nicht-mehr-ohne-sudo-passwortabfrage
Viele Grüße
Steffen
hast du denn das Problem tatsächlich, oder nur davon gelesen ?
Welcher client?
Hast du unser Paket benutzt?
http://archive.linuxmuster.net/bionic : linuxmuster-client-veracrypt
Hallo Rüdiger,
ja, hab es.
Ubuntu 18.04, Installation aus ppa. Das ist kein LMN-Client - wir haben ja leider keine LMN mehr 
Viele Grüße
Steffen
Hi STeffen,
ich hab mich an anderer Stelle mit sudo rumgeschlagen (v7, skript als root ausführen).
Ich habe festgestellt:
schau, was in /etc/sudoers steht und schau wo dort #includedir /etc/sudoers.d/ steht, denn das ist ein Befehl und kein Kommentar!!
und dann schaust du was in /etc/sudoers.d/ steht.
Dann nennst du die DAteien darin mal so, wie es dir lexikalisch Sinn macht, denn:
das wird alles von oben nach unten abgearbeitet und der letzte Match zählt, z.B. bei mir:
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# %p_sudo ALL=NOPASSWD: ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
#ALL ALL=NOPASSWD: /etc/linuxmuster-client/scripts/login-run-as-root.sh/etc/sudoers.d# ls -l
insgesamt 24
-r--r----- 1 root root 30 Nov 10 16:50 01_global-admin
-r--r----- 1 root root 79 Nov 10 16:50 02_p_sudo
-r--r----- 1 root root 79 Nov 10 16:50 03_teachers
-r--r----- 1 root root 65 Nov 10 16:50 05_linuxmuster-client-veracrypt
-r--r----- 1 root root 102 Nov 10 16:50 10_linuxmuster-client-as-rootwenn also bei dir nicht klar ist, welche Reihenfolge die Scripte abgearbeitet werden, dann kann es sein, dass ein ALL ALL:ALL bla blub das nach deinem %sudo ALL=NOPASSWD: /usr/bin/veracrypt kommt den Befehl wieder zunichte macht. D.h. 1. aufräumen um sicherzugehen, dass es nicht an der sudoers-konfiguration liegt und dann 2. versuchen den bug zufinden, wenn es dann noch einen gibt.
VG, Tobias
Hallo Tobias,
an der /etc/sudoers wurde nichts verändert, und ich habe historisch noch alles in der /etc/sudoers und nichts in /etc/sudoers.d/. Es hat auch immer funktioniert, exakt bis zum Update von Veracrypt von Version 1.23 auf 1.24-Hotfix1.
Das ist die /etc/sudoers:
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
# Host alias specification
# User alias specification
# Cmnd alias specification
# User privilege specification
root ALL=(ALL:ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
# See sudoers(5) for more information on "#include" directives:
#includedir /etc/sudoers.d
# eigene Eintraege
# Truecrypt mit Rootrechten (ohne Sudo-Passworteingabe)
%truecrypt ALL=NOPASSWD: /usr/bin/truecrypt
# Veracrypt mit Rootrechten (ohne Sudo-Passworteingabe)
%veracrypt ALL=NOPASSWD: /usr/bin/veracrypt
# dito Samba-Freigabe-Manager
%sambaverwaltung ALL=NOPASSWD: /usr/sbin/system-config-samba
# dito grsync als root
%grsync ALL=NOPASSWD: /usr/bin/grsync
ALL ALL=(ALL) NOPASSWD : /usr/lib/jvm/java-6-openjdk-i386/bin/java -Djava.library.path\=/opt/eInstruction/DeviceManager -classpath /opt/eInstruction/DeviceManager/dm.jar\:/opt/eInstruction/DeviceManager/*\$
ALL ALL=(ALL) NOPASSWD : /usr/lib/jvm/java-7-openjdk-i386/bin/java -Djava.library.path\=/opt/eInstruction/DeviceManager -classpath /opt/eInstruction/DeviceManager/dm.jar\:/opt/eInstruction/DeviceManager/*\$
ALL ALL=(ALL) NOPASSWD : /usr/lib/jvm/java-8-openjdk-i386/bin/java -Djava.library.path\=/opt/eInstruction/DeviceManager -classpath /opt/eInstruction/DeviceManager/dm.jar\:/opt/eInstruction/DeviceManager/*\$
Defaults env_keep += "DISPLAY XAUTHORITY XAUTHLOCALHOSTNAME"
Ich hatte auch schon alles unterhalb von # eigene Eintraege außer %veracrypt ALL=NOPASSWD: /usr/bin/veracrypt auskommentiert.
Viele Grüße
Steffen
ok, dann schließt es die Reihenfolge-problematik bei dir aus.
VG, Tobias
Hallo Tobias,
ja, sehe ich auch so. Am NB habe ich Veracrypt noch nicht geupdated, da ist noch 1.23 installiert und damit funktioniert’s auch noch immer.
Ich sehe nur nicht den Zusamenhang zwischen einer neueren Programmversion von Veracrypt und dem, dass das mit der /etc/sudoers nicht mehr funktioniert, außer, dass es diesen Zusammenhang gibt.
Viele Grüße
Steffen
Hallo Steffen,
vielleicht lagert Veracrypt das eigentliche Mounten nun an einen anderen Prozess aus. Schau doch mal mittels ps -eF zum fraglichen Zeitpunkt, welche Prozesse gerade laufen – vielleicht fällt Dir ja was auf.
Beste Grüße
Jörg
hallo Jörg,
Das in Frage kommende:
root 14099 1 16 54607 10188 7 17:30 tty2 00:00:01 /usr/bin/veracrypt --core-service
root 14101 1 0 54607 2968 7 17:30 ? 00:00:00 /usr/bin/veracrypt --core-service
root 14103 1 0 107934 5524 3 17:30 ? 00:00:00 /usr/bin/veracrypt --core-service
root 14218 1 4 3915 3104 3 17:30 ? 00:00:00 /sbin/mount.ntfs /dev/mapper/veracrypt1 /media/veracrypt1 -o rw,uid=1000,gid=1000,umask=077
Vielleicht ist ja der letzte Eintrag das Problem… ?!?
Viele Grüße
Steffen
Hallo,
also ein zusätzlicher Eintrag in die /etc/sudoers
%veracrypt ALL=NOPASSWD: /sbin/mount.ntfs
bringt auch nichts.
Viele Grüße
Steffen
Hallo,
das Problem ist gelöst. Offensichtlich hat sich Veracrypt bis 1.23 immer via sudo aufgerufen und tut dies nun nicht mehr. Man muss also explizit Veracrypt mit sudo voran aufrufen und bei Verwendung der grafischen Oberfläche den Starter modifizieren.
Viele Grüße
Steffen