Schreibrechte für Netzwerkfreigabe mit Mount Unit

[Richard]

Hallo,

ich habe eine Netzwerkfreigabe mit einer Mount Unit eingebunden, habe aber keine Rechte dort etwas zu löschen oder darin zu schreiben. Mit AutoFS geht das. Es ist eine SMB-Freigabe, die *.mount sieht so aus:

Code: Alles auswählen

[Unit]
Description=CIFS-Freigabe
[Mount]
What=//192.168.10.23/usb
Where=/automount/raspberry_usb
Options=username=pi,password=password,rw
Type=cifs
[Install]
WantedBy=multi-user.target

und die *.automount

Code: Alles auswählen

[Unit]
Description=Automount
Requires=NetworkManager.service
After=network-online.target
Wants=network-online.target
[Automount]
Where=/automount/raspberry_usb
TimeoutIdleSec=10min
[Install]
WantedBy=multi-user.target

Den Ordner /automount hat die Unit selbst erstellt, nicht ich. Ich hab versucht die Rechte mit

Code: Alles auswählen

chmod -R 777 /automount

zu ändern, das wird aber nur für den 1. Ordner gemacht, nicht für die anderen. Kann auch keine Lösung sein, weil das ja nicht für neu erstellt Ordner gelten würde, die erst später angelegt werden.

Richard

[jph]

Ich würde zunächst überprüfen, ob dein User Schreibrechte auf die Freigabe hat bzw. ob die Freigabe überhaupt rw freigegeben ist. Wenn sie auf dem Server ro freigegeben ist, kann die Mount-Unit nichts daran ändern.

Du kannst dir in der Mount-Unit übrigens die Angaben zu [Install] sparen, da du diese Unit nicht installierst (systemctl enable). Du installierst die Automount-Unit und die startet bei Bedarf die Mount-Unit.

Nachtrag: in 5 smb.conf steht: Default: read only = yes, d.h. eine Freigabe, die du nicht explizit rw freigibst, ist ro.

[Richard]

Auf dem Server kann das Problem nicht liegen, da es hier mit AutoFS und ueber den smb-client von thunar problemlos geht.

[jph]

Faszinierend. Ich bekomm’s hier auch nicht hin, und dafür brauche ich nicht mal systemd – ein simples mount -t cifs bewirkt, dass alle Dateien des Mounts root gehören. Der darf nämlich schreiben.

Zwei Workarounds habe ich entdeckt:

• mount -o vers=1.0: erzwingt die Verwendung des SMB-Protokolls in Version 1.0, die ziemlich lahm ist und diverse Sicherheitslücken hat
• mount -o uid=...,gid=... zum Überschreiben von Benutzer und Gruppe – eine Möglichkeit, wenn der Mountpoint nur von einem User verwendet werden soll

Genau wegen so einem Sch... bin ich auf NFS umgestiegen

[TomL]

Auf dem Server kann das Problem nicht liegen, da es hier mit AutoFS und ueber den smb-client von thunar problemlos geht.

Ich weiss nicht, ob das dasselbe ist ... zumindest, wenn Du hier den Build-In-Support des Filemanagers meinst. Wenn es das ist, was Du meinst, ist das eigentlich auch kein AufoFS. Vielleicht weiss da jemand anderes mehr zu.

Was passiert, wenn Du das als root im Terminal von Hand machst? Wie sieht es dann mit den Rechten auf dem Share aus?

Code: Alles auswählen

umount /automount/raspberry_usb
mount //192.168.10.23/usb /automount/raspberry_usb -t cifs -o Options=username=pi,password=password,rw

BTW, die Parameter uid=...,gid=... überschreiben Benutzer und Gruppe nur kosmetisch.... in den Views der Filemanager auf den Share. Auf tatsächlich gesetzte Rechte oder zu setzende Rechte hat das keinen Einfluss. Was wirklich passiert, entscheidet bzw. erlaubt primär das Linux des Servers und dem untergeordnet die Samba-Conf.

[novalix]

Möglicherweise brauchst Du auch gar keine eigene Unit.

In der fstab:

Code: Alles auswählen

//192.168.10.23/usb /automount/raspberry_usb cifs \
defaults,rw,noauto,username=$user,password=$password,\
x-systemd.automount,x-systemd.device-timeout=2min,x-systemd.idle-timeout=10min 0 0

und danach ein

Code: Alles auswählen

systemctl daemon-reload

* könnte schon langen.
Das "device-timeout" ist als Puffer gedacht, falls die Freigabe nicht sofort erreichbar ist.
"username" und "password" kannst Du auch in eine Datei im Heimatverzeichnis von root mit 0600 vor neugierigen Blicken verstecken und als "credentials" referenzieren.

Code: Alles auswählen

man mount.cifs

*Die Zeilenumbrüche per "\" habe ich hier nur wegen der besseren Lesbarkeit eingefügt. In der fstab haben die nichts zu suchen.

[Richard]

Genau wegen so einem Sch... bin ich auf NFS umgestiegen

NFS nützt mir wenig, wenn ich keinen Einfluss darauf habe was auf dem Server läuft. Und wenn das der Fall ist, ist es meist SMB (Fritzbox oder LibreELEC). Aber auch auf dem Pi bin ich inzwischen wieder zurück zu SMB gewechselt, der NFS-Server lief zuletzt unzuverlässig und ich hatte erstmal keine Lust auf Fehlersuche zu gehen. Zumal SMB ohnehin parallel lief da mein File Manager auf dem Smartphone nur SMB unterstützt.

NFS ist in der Realität leider nichts weiter als eine nette Spielerei.

Ich weiss nicht, ob das dasselbe ist ... zumindest, wenn Du hier den Build-In-Support des Filemanagers meinst. Wenn es das ist, was Du meinst, ist das eigentlich auch kein AufoFS.

Ja sicher ist es kein AutoFS wenn ich den im FM eingebauten SMB-Support für den Zugriff nutze. Ich wollte nur klar machen, dass es nicht am SMB-Server liegen kann, da es
a.) mit AutoFS ging (egal welchen FM ich da eingesetzt habe) und
b.) es mit eingebauten SMB-Clienten ging

BTW, die Parameter uid=...,gid=... überschreiben Benutzer und Gruppe nur kosmetisch.... in den Views der Filemanager auf den Share. Auf tatsächlich gesetzte Rechte oder zu setzende Rechte hat das keinen Einfluss

Das scheint aber letztlich genau die Lösung zu sein. Wenn ich uid=1000 nehme scheint es zu gehen. Zumindest konnte ich in einem kurzen Test Ordner löschen.

***************************

Hat mal jemand einen Vergleich zwischen AutoFS und Systemd Mount Units gemacht? Läuft eines davon stabiler/schneller? Im Wiki zu Mount Unit ist von AutoFS als "ältere Lösung" die Rede.

[TomL]

Das scheint aber letztlich genau die Lösung zu sein. Wenn ich uid=1000 nehme scheint es zu gehen. Zumindest konnte ich in einem kurzen Test Ordner löschen.

Ist 1000 zufällig auch Deine lokale UID auf dem Client-PC? Meiner Meinung ist die Ursache, wenn es damit funktioniert, dass dem Filemanager damit lediglich gesagt wird, was er glauben soll und das man damit auf einen zufälligen Treffer hofft. Wenn der Filemanager selber die Rechte prüft, kann es nämlich passieren, dass es ohne diesen Parameter fehlschläg, weil tatsächliche Besitz-Rechte vielleicht abweichend zu den Rechten des Users sind, weil eben die UIDs nicht passen.

Mit anderen Worten, es wird mit der UID 1000 als Standard-Parameter immer dann funktionieren, wenn der lokale Hauptbenutzer des PCs auch die 1000 hat, was auf 1-Personen-Geräten rein zufällig meistens so ist. Gibts hingegen mehrere User an einem PC, kanns sein, dass es wieder nicht funktioniert, weil alle anderen User eine zu 1000 abweichende UID haben. Ausserdem ignoriert das den Umstand, dass meine UID auf dem Server ebenfalls gar nicht 1000 sein muss und dort vielleicht jemand ganz anderem gehört. Das bedeutet, wenn ich auf dem Server der User 1022 bin, werden meine Dateien dort unter der UID 1022 gespeichert, auf meinem PC aber trotzdem mit der User 1000 angezeigt. Und mit dem Standard-UID-Parameter =1000 passt es also nur dann, wenn ich zufällig selber der User 1000 bin... aber es ist eben nur eine zufällige Übereinstimmung.

Code: Alles auswählen

# cd mnt
# mkdir 1
# mkdir 2

# mount //1.1.1.2/SSD /mnt/1 -t cifs -o username=thomas,password=abc,uid=thomas,gid=thomas
# mount //1.1.1.2/SSD /mnt/2 -t cifs -o username=thomas,password=abc

# ls /mnt/1/Home/thomas
insgesamt 6,0M
drwxr-xr-x 2 thomas thomas    0 2019-03-14 18:20 .
drwxr-xr-x 2 thomas thomas    0 2017-06-16 18:49 ..
drwxr-xr-x 2 thomas thomas    0 2018-04-02 21:24 Backup
drwxr-xr-x 2 thomas thomas    0 2019-03-14 18:23 Daten
drwxr-xr-x 2 thomas thomas    0 2014-08-10 20:55 .Trash-0
drwxr-xr-x 2 thomas thomas    0 2016-04-13 16:12 .Trash-1000
usw.

# ls /mnt/2/Home/thomas
insgesamt 6,0M
drwxr-xr-x 2 root root    0 2019-03-14 18:20 .
drwxr-xr-x 2 root root    0 2017-06-16 18:49 ..
drwxr-xr-x 2 root root    0 2018-04-02 21:24 Backup
drwxr-xr-x 2 root root    0 2019-03-14 18:23 Daten
drwxr-xr-x 2 root root    0 2014-08-10 20:55 .Trash-0
drwxr-xr-x 2 root root    0 2016-04-13 16:12 .Trash-1000
usw.