Passwortabfrage beim 'mounten' eines Datenträgers

Warum Debian? Was muss ich vorher wissen? Wo geht's nach der Installation weiter?
Antworten
Benutzeravatar
Andi123
Beiträge: 19
Registriert: 21.03.2018 11:43:35

Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von Andi123 » 31.03.2018 13:53:43

Servus

Wenn ich im Dateimanager auf einen internen Datenträger, in diesem Fall eine sata SSD NTFS mit Namen DATA klicke, wird nach dem Passwort gefragt.

Bei USB Sticks wird kein Passwort verlangt.
Auch bei meiner Mint Installation wird nicht nach dem Passwort gefragt.

Die sudoers Datei ist bei beiden identisch.

Der Mountpunkt ist /media/benutzer/DATA

Ist es möglich die Passwortabfrage zu deaktivieren?

Mfg
Andi
Desktop Tuxedo, ASRock H170M Pro4, i7-7700K, 32 Gig RAM, Nvidia 1060 GTX, Mint 19 Mate 64, Windows 10 Pro 64, LibraZiK2(=Debian 9) Stretch 64 als VM,
HP Pavillion DV-7-1289eg - Core 2 Duo P8600 2.40GHz NVIDIA GeForce 9600M GT 8GB RAM Mint 18.3 Mate 64.

Benutzeravatar
Drache
Beiträge: 710
Registriert: 22.11.2009 05:49:55

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von Drache » 31.03.2018 15:23:06

Hallo Andi,

eventuell Policykit …? → https://wiki.archlinux.org/index.php/Polkit
irgendwas in der Art:

Code: Alles auswählen

[udisks2]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.eject-media-$
ResultAny=yes
ResultInactive=yes
ResultActive=yes

in /etc/polkit-1/localauthority/50-local.d/udisks2-mount.pkla könnte dann eventuell helfen, aber Achtung, mein Terminal/Kopieren hat die Ausgabe abgeschnitten → siehe $

Edit fragt mich gerade, was es mit sudoers zu tun haben soll? Eher noch mit fdisk … (Option user/users vielleicht? kann mich die Erinnerung aber trügen, eventuell gehts bei der Option ums Aushängen.) das obige hilft freilich auch nur wenn dein User in plugdev ist.
“Don't you think that if I were wrong, I'd know it?” (Dr. Sheldon Cooper)
XFCE: alt,steinhart,langweilig,immer noch da.

TomL
Beiträge: 3705
Registriert: 24.07.2014 10:56:59

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von TomL » 31.03.2018 15:57:00

Andi123 hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 13:53:43
Ist es möglich die Passwortabfrage zu deaktivieren?
Ja, es ist möglich.

Es juckt ja richtig in den Fingern, es bei dieser Antwort zu belassen.... :twisted: ... was anderes wurde ja nicht gefragt... :mrgreen: ... aber vielleicht hat ja jemand anderes auch dieses Problem... :wink:

In der Datei
/usr/share/polkit-1/actions/org.freedesktop.udisks2.policy

bei den folgenden Policies
<action id="org.freedesktop.udisks2.filesystem-mount-system">
<action id="org.freedesktop.udisks2.filesystem-fstab">
<action id="org.freedesktop.udisks2.filesystem-unmount-others">


die Einstellung
<allow_active>auth_admin_keep</allow_active>
auf
<allow_active>yes</allow_active>
ändern.

Nach einem Re-Login ggf. sogar Reboot sollte die Passwortabfrage nicht mehr kommen.
vg, Thomas

Benutzeravatar
Andi123
Beiträge: 19
Registriert: 21.03.2018 11:43:35

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von Andi123 » 31.03.2018 16:01:22

Servus Drache

das mit der sudoers war schon bei Mint ein Problem mit mount und umount usw.

da musste ich einige Einträge hinzufügen

Code: Alles auswählen

#
# 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

# 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

andreas ALL=(ALL) NOPASSWD: /usr/bin/truecrypt

%truecrypt ALL=NOPASSWD: /usr/bin/truecrypt

andreas ALL=(ALL) NOPASSWD: /usr/bin/veracrypt

%truecrypt ALL=NOPASSWD: /usr/bin/veracrypt

andreas ALL= NOPASSWD: /bin/mount

%users ALL = NOPASSWD: /bin/mount

andreas ALL= NOPASSWD: /bin/umount

%users ALL = NOPASSWD: /bin/umount

andreas ALL=(ALL) NOPASSWD: /bin/ntfsfix

andreas ALL = NOPASSWD: /sbin/shutdown

andreas ALL = NOPASSWD: /sbin/reboot

# User alias specification
User_Alias ABSCHALTER = andreas, andi

# Cmnd alias specification
Cmnd_Alias DOWN = /sbin/shutdown, /sbin/halt, /sbin/reboot

# User privilege specification
ABSCHALTER ALL = NOPASSWD: DOWN
Alles das was ich da eingetragen habe funktionierte bei Mint vorher nur mit dem Rootpasswort, obwohl mein Profil in der sudo Gruppe ist.

Nach den sudoers Einträgen ging dann alles ohne Passwort bei Mint.

Nur bei Debian wird das Passwort fur den NTFS Datenträger verlangt, bei Mint nicht.

Dachte nicht daß der Unterschied so groß ist.

Man denkt immer Debian - Ubuntu - Mint, das ist wohl ein Fehler.

Für die Archseite ist mein Englisch nicht tauglich.

MfG
Andi
Desktop Tuxedo, ASRock H170M Pro4, i7-7700K, 32 Gig RAM, Nvidia 1060 GTX, Mint 19 Mate 64, Windows 10 Pro 64, LibraZiK2(=Debian 9) Stretch 64 als VM,
HP Pavillion DV-7-1289eg - Core 2 Duo P8600 2.40GHz NVIDIA GeForce 9600M GT 8GB RAM Mint 18.3 Mate 64.

geier22

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von geier22 » 31.03.2018 16:26:01

Andi123 hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 13:53:43
Wenn ich im Dateimanager auf einen internen Datenträger, in diesem Fall eine sata SSD NTFS mit Namen DATA klicke, wird nach dem Passwort gefragt.
Gibt es eigentlich einen tieferen Grund, warum du eine interne Festplatte nicht per fstab einbindest und dir stattdessen einen Knoten in die Beine machst?
Ich weiß auch nicht, warum du die /etc/sudoers voll schreibst. Ich habe noch keinen einzigen Fall bei Debian erlebt (außer aus der Konsole heraus), dass ich das System nicht runter fahren oder sonst was konnte.

TomL
Beiträge: 3705
Registriert: 24.07.2014 10:56:59

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von TomL » 31.03.2018 16:31:48

Andi123 hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 16:01:22
das mit der sudoers war schon bei Mint ein Problem mit mount und umount usw.
Ja, weil die sudoers auf unseren modernen Multiuser-/Multiboot-/Multi-On-Off-/GUI-Computersystemen schlichtweg ein Designfehler ist... was man bei Mint und Ubuntu leider einfach ignoriert. Aber Debian ist GSD so ausgestaltet, dass es nach dem Default-Willen des Installers völlig ohne sudo und sudoers auskommt. Das heisst, man braucht das bei Debian nicht.
vg, Thomas

Benutzeravatar
Drache
Beiträge: 710
Registriert: 22.11.2009 05:49:55

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von Drache » 31.03.2018 18:23:07

TomL hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 15:57:00

/usr/share/polkit-1/actions/org.freedesktop.udisks2.policy

bei den folgenden Policies
<action id="org.freedesktop.udisks2.filesystem-mount-system">
<action id="org.freedesktop.udisks2.filesystem-fstab">
<action id="org.freedesktop.udisks2.filesystem-unmount-others">


die Einstellung
<allow_active>auth_admin_keep</allow_active>
auf
<allow_active>yes</allow_active>

Imho macht man das nicht so (obschon es funktioniert), sondern legt sich eine eigene pkla-Regel an…
Andi123 hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 16:01:22
Servus Drache

das mit der sudoers war schon bei Mint ein Problem mit mount und umount usw.


Für die Archseite ist mein Englisch nicht tauglich.

MfG
Andi

MIt sudoers hatte ich noch nie zu tun, was du da im Codeblock zitiert hast, sind für mich alles böhmische Dörfer.

Für ntfs ist mir gerade noch eingefallen, dass du auch noch überprüfen solltest, ob Debianntfs-3g (?) oder so ähnlich installiert ist.

Falls es policykit ist, und du udisks2 installiert hast, dann

sollte folgendes helfen:

Leg die Datei

Code: Alles auswählen

/etc/polkit-1/localauthority/50-local.d/udisks2-mount.pkla 
an.

Schreib folgenden Inhalt rein

Code: Alles auswählen

[udisks2]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.eject-media-other-seat;org.freedesktop.udisks2.filesystem-fstab;org.freedesktop.udisks2.filesystem-mount;org.freedesktop.udisks2.filesystem-mount-other-seat;org.freedesktop.udisks2.filesystem-unmount-others;org.freedesktop.udisks2.open-device;org.freedesktop.udisks2.cancel-job;org.freedesktop.udisks2.filesystem-mount-system
ResultAny=yes
ResultInactive=yes
ResultActive=yes
Speichern

System neu starten.

Läuft vermutlich.

Ansonsten ist s schwierig, vor allem da ich nur solange Zeit habe, wie ich es vertreten kann, meinen Kleiner nebenzu Katzenvideos kucken zu lassen … ;)

https://bbs.archlinux.de/viewtopic.php?id=21777
https://wiki.archlinux.de/title/Laufwer ... er_mounten

sind weitgehend auf Deutsch, könnte auch noch helfen oder mal ins debianforums-wiki kucken.

P.S. Edit erinnert mich, dass ich wieder vergessen habe dazu zuschreiben: die obige Anleitung geht nur, wenn dein User (andi?) in der Gruppe plugdev ist!
“Don't you think that if I were wrong, I'd know it?” (Dr. Sheldon Cooper)
XFCE: alt,steinhart,langweilig,immer noch da.

TomL
Beiträge: 3705
Registriert: 24.07.2014 10:56:59

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von TomL » 31.03.2018 18:35:05

Drache hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 18:23:07
Imho macht man das nicht so (obschon es funktioniert), sondern legt sich eine eigene pkla-Regel an…
Richtig, wenns notwendig ist, zwischen mehreren Usern oder Gruppen zu unterscheiden. Bei einem Ein-User-Rechner kann mans natürlich auch machen, ist aber nur wieder (imho unnötiger) Mehraufwand. Ich würds jedenfalls nicht zu kompliziert machen. Als generelle Einstellung ist dieser Speicherort völlig in Ordnung. Aber der Hinweis war trotzdem ok... nun kann er sich entscheiden und selber wählen, wie es werden soll. Und die "einfachere" Variante ist keinesfalls technisch falsch...
vg, Thomas

Benutzeravatar
Andi123
Beiträge: 19
Registriert: 21.03.2018 11:43:35

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von Andi123 » 31.03.2018 18:55:33

@geier22

Runterfahren und Neustarten konnte ich schon ohne root.
Aber leider dauerte das Runterfahren mit dem normalen Schalter ewig, weil ich einige mit cifs eingebundene Netzwerkordner(FritzNas) hatte, und das System, ob Mint, Ubuntu oder Debian ewig brauchte diese auszuhängen.

Manchmal dauerte es schon 30 Sekunden bis das Profil abgemeldet war.

Nur mit shutdown, reboot ging es schneller, und die funktionierten nur mit root.

Jetzt habe ich erfolgreich bei Debian in der fstab FritzNas eingetragen, und funktioniert auch.

Code: Alles auswählen

//ipfritzbox/fritz.nas/TOExter-nalUSB3-0-01/FRITZ    /media/FritzNas     cifs	username=benutzer,password=passwort,uid=1000,gid=1000,sec=ntlmv2,noauto,users  0   0
Dieser Eintrag funktoniert bei Debian, leider nicht bei Mint.

Siehe hier

http://minthouselinuxforum.forumieren.c ... b-fritznas

TomL hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 16:31:48
Ja, weil die sudoers auf unseren modernen Multiuser-/Multiboot-/Multi-On-Off-/GUI-Computersystemen schlichtweg ein Designfehler ist... was man bei Mint und Ubuntu leider einfach ignoriert. Aber Debian ist GSD so ausgestaltet, dass es nach dem Default-Willen des Installers völlig ohne sudo und sudoers auskommt. Das heisst, man braucht das bei Debian nicht.

Das meinte ich mit "Denkfehler Debian - Ubuntu - Mint".

Man glaubt weil das Eine auf das Andere "Aufgebaut" ist, müsste alles zumindest ähnlich funktionieren.


@Drache

ja das ntfs Zeugs ist installiert.

Das mit pkla werde ich natürlich machen.

Vielen Dank an Alle für eure Antworten.

Über Erfolg oder nicht werde ich berichten.

MfG
Andi
Desktop Tuxedo, ASRock H170M Pro4, i7-7700K, 32 Gig RAM, Nvidia 1060 GTX, Mint 19 Mate 64, Windows 10 Pro 64, LibraZiK2(=Debian 9) Stretch 64 als VM,
HP Pavillion DV-7-1289eg - Core 2 Duo P8600 2.40GHz NVIDIA GeForce 9600M GT 8GB RAM Mint 18.3 Mate 64.

Benutzeravatar
Andi123
Beiträge: 19
Registriert: 21.03.2018 11:43:35

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von Andi123 » 01.04.2018 11:01:04

Drache hat geschrieben: ↑ zum Beitrag ↑
31.03.2018 15:23:06
Hallo Andi,

eventuell Policykit …? → https://wiki.archlinux.org/index.php/Polkit
irgendwas in der Art:

Code: Alles auswählen

[udisks2]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.eject-media;org.freedesktop.udisks2.eject-media-$
ResultAny=yes
ResultInactive=yes
ResultActive=yes

in /etc/polkit-1/localauthority/50-local.d/udisks2-mount.pkla könnte dann eventuell helfen, aber Achtung, mein Terminal/Kopieren hat die Ausgabe abgeschnitten → siehe $
Hat super geklappt, danke.

Auch der Eintrag in die fstab funktioniert

Code: Alles auswählen

UUID=4055293307AFB1C4	/media/DATA		ntfs    defaults        0       2
Wo ist denn sowas dokunentiert?

Gruß
Andi
Desktop Tuxedo, ASRock H170M Pro4, i7-7700K, 32 Gig RAM, Nvidia 1060 GTX, Mint 19 Mate 64, Windows 10 Pro 64, LibraZiK2(=Debian 9) Stretch 64 als VM,
HP Pavillion DV-7-1289eg - Core 2 Duo P8600 2.40GHz NVIDIA GeForce 9600M GT 8GB RAM Mint 18.3 Mate 64.

KP97
Beiträge: 1437
Registriert: 01.02.2013 15:07:36

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von KP97 » 01.04.2018 12:19:30

Andi123 hat geschrieben: ↑ zum Beitrag ↑
01.04.2018 11:01:04
Wo ist denn sowas dokunentiert?
In den manpages.
Ubuntu hat mit Debian wohl nur noch das Paketformat gemeinsam, ansonsten haben sich die Wege schon vor langer Zeit getrennt. Und soweit ich weiß, setzt Mint auf Ubuntu auf, also das Gleiche.
Es gibt wohl noch LMDE, ob das aber mit Debian vergleichbar ist, möchte ich auch bezweifeln.
Also, mache Dich mit Debian vertraut.

geier22

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von geier22 » 01.04.2018 12:30:18

Manpages fstab:
http://manpages.courier-mta.org/htmlman5/fstab.5.html
und
https://wiki.debian.org/fstab#See_also

Gutes Manual systemd / fstab

https://wiki.manjaro.org/index.php?titl ... mount_(de)
und
https://wiki.archlinux.org/index.php/fs ... th_systemd

Die Option noauto,x-systemd.automount benutze ich selber bei Datenplatten, auf die ein Zugriff beim Bootvorgang nicht unbedingt
notwendig ist. Sieht dann z.B. so aus:

Code: Alles auswählen

UUID=8b535dfa-0c3f-4c55-aa95-a6bd61679344	/media/Musik	ext4	noauto,x-systemd.automount,defaults    0    0
Grrr .. nicht gespeichert also nochmal:

Zum PolicyKit:
Referenz:
https://www.freedesktop.org/software/po ... kit.8.html

Alle Berechtigungen, um die es hier ging sind in der Datei /usr/share/polkit-1/actions/org.freedesktop.UDisks2.policy geregelt: NoPaste-Eintrag40234
wo man sie auch m.E. ändern könnte. Man braucht also nichts neues.

Code: Alles auswählen

~$ pkaction |grep udisks2
org.freedesktop.udisks2.ata-check-power
org.freedesktop.udisks2.ata-secure-erase
org.freedesktop.udisks2.ata-smart-enable-disable
org.freedesktop.udisks2.ata-smart-selftest
org.freedesktop.udisks2.ata-smart-simulate
org.freedesktop.udisks2.ata-smart-update
org.freedesktop.udisks2.ata-standby
org.freedesktop.udisks2.ata-standby-other-seat
org.freedesktop.udisks2.ata-standby-system
org.freedesktop.udisks2.cancel-job
org.freedesktop.udisks2.cancel-job-other-user
org.freedesktop.udisks2.eject-media
org.freedesktop.udisks2.eject-media-other-seat
org.freedesktop.udisks2.eject-media-system
org.freedesktop.udisks2.encrypted-change-passphrase
org.freedesktop.udisks2.encrypted-change-passphrase-system
org.freedesktop.udisks2.encrypted-lock-others
org.freedesktop.udisks2.encrypted-unlock
org.freedesktop.udisks2.encrypted-unlock-crypttab
org.freedesktop.udisks2.encrypted-unlock-other-seat
org.freedesktop.udisks2.encrypted-unlock-system
org.freedesktop.udisks2.filesystem-fstab
org.freedesktop.udisks2.filesystem-mount
org.freedesktop.udisks2.filesystem-mount-other-seat
org.freedesktop.udisks2.filesystem-mount-system
org.freedesktop.udisks2.filesystem-take-ownership
org.freedesktop.udisks2.filesystem-unmount-others
org.freedesktop.udisks2.loop-delete-others
org.freedesktop.udisks2.loop-modify-others
org.freedesktop.udisks2.loop-setup
org.freedesktop.udisks2.manage-md-raid
org.freedesktop.udisks2.manage-swapspace
org.freedesktop.udisks2.modify-device
org.freedesktop.udisks2.modify-device-other-seat
org.freedesktop.udisks2.modify-device-system
org.freedesktop.udisks2.modify-drive-settings
org.freedesktop.udisks2.modify-system-configuration
org.freedesktop.udisks2.open-device
org.freedesktop.udisks2.open-device-system
org.freedesktop.udisks2.power-off-drive
org.freedesktop.udisks2.power-off-drive-other-seat
org.freedesktop.udisks2.power-off-drive-system
org.freedesktop.udisks2.read-system-configuration-secrets
org.freedesktop.udisks2.rescan

Benutzeravatar
speefak
Beiträge: 64
Registriert: 27.04.2008 13:54:20

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von speefak » 01.05.2018 15:18:37

Ich würde allerdings aus verwaltungstechnischen Gründen auch lieber eine neue Datei anlegen als eine Defaultsystemdatei zu editieren. Beim aufsetzen des System ist es dann einfacher via script die Konfiguration sprich die Datei einfach zu kopieren anstatt bestehende default Dateien zu ändern.

Warum das ganze nicht über die fstab regeln : ganz einfach : wenn man Platten im System, hat die man nur selten benötigt und via SATA Rack manuell zugeschaltete werden gibt es beim booten eine fstab Fehlermeldung.

etwas offtopic : NTFS Partitionen werden hier nur als lesend eingehängt ? ntfs-3g ist installierst, "user_allow_other" in der /etc/fuse.conf eingetragen . Beim "Einhängen via klick" werden die Partitionen via fuse eingehängt - andere Dateisysteme die uach via fuse eingehängt werden sind schreibend einghängt - nur ntfs nicht. Die Partition enthält keine Fehler ( "Fehlerbit" beim falschen aushängen der ntfs Partition ist nicht gesetzt ). Wo muss ich was ändern um auch ntfs Partitionen schreiben einzuhängen ?

Benutzeravatar
Kartman
Beiträge: 28
Registriert: 03.09.2018 14:05:00

Re: Passwortabfrage beim 'mounten' eines Datenträgers

Beitrag von Kartman » 07.09.2018 22:24:26

Ich kann auf der Platte nicht schreiben, nur lesen :(
Asus P7P55D-E / Intel Core i7 870 / Nividia Geforce GTX 1060 6GB / 12GB DDR3 RAM / 1 TB SSD

Antworten