Fehler beim Zugriff des Mac auf Share eines Linux SMB-Servers

[picollo]

Kurz vorab: ich habe einen SMB-Server auf einem Ubuntu 20.20 aufgesetzt. Der funktioniert auch, die für macOS empfohlenen Konfiguration "fruit: ..." und andere Parameter sind in der smb.conf eingetragen. Alles funktioniert soweit.

Aber ...

Wenn ich Dateien, die im Share über das Netzwerk vom Mac abgespeichert wurden auf dem Linux-Client erst entferne oder wo anders hin kopiere, die Originale im Share lösche, die Kopien dieser auf dem Linux Client gespeicherten Dateien (gleicher Name, gleiche Größe) in das Share wieder zurück kopiere, sind diese Dateien vom Mac aus entweder nicht sichtbar oder sie werden als Verzeichnisse angezeigt. Sie sind vom Mac aus nicht bearbeitbar, im Terminal werden dafür auch Verzeichnisse mit fester Größe angezeigt. Unter Linux sind diese Datei aber weiterhin normal zu sehen und auch bearbeitbar.

Ist dieser Fehler bekannt? Es ist sicherlich ein Umstand, der im normalen Betrieb selten vorkommt. Aber mir ist es erst aufgefallen, als ich eben Dateien hin und her kopiert, gelöscht und wiederhergestellt habe (durch zurück kopieren).

smb.conf und andere Konfigurationen folgen später ...

 

[picollo]

Der Teil der smb.conf unter [global]:

# Anpassungen für macOS​

ea support = yes​

fruit:aapl = yes​

vfs objects = catia fruit streams_xattr​

fruit:metadata = stream​

# fruit:metadata = netatalk ... hat keine Auswirkungen​

fruit:model = MacSamba​

fruit:veto_appledouble = no​

# fruit:veto_appledouble = yes ... hat keine Auswirkungen​

fruitosix_rename = yes​

fruit:zero_file_id = yes​

fruit:wipe_internationally_left_blank_rfork = no​

# fruit:wipe_internationally_left_blank_rfork = yes ... hat keine Auswirkungen​

# nicht aktiv und ohne Auswirkungen:​

# fruit:copyfile = no​

# fruit:resource = xattr​

# fruit:metadata = netatalk​

# fruit:locking = netatalk​

# fruit:encoding = native​

# geaendert von no zu yes:​

# fruit:delete_empty_adfiles = yes​

# nur wenn kein SMBv1: min protocol = SMB2
# Ende Anpassungen fuer macOS

# Share Einstellungen:
[SMB_Linux]
path = /srv/1TB/SHARE/linux
public = yes
create mask = 0664
directory mask = 0775
browseable = yes
writeable = yes
force group = sambashare

 

[macati]

Ich habe das exakt gleiche Problem. Ubuntu 20.04 dient als "Server", verschiedene Macs (alle mit 10.13) greifen darauf zu. Diverse Dateien werden im Finder als versteckte Ordner angezeigt, obwohl sie auf dem Linux-Rechner ganz normal funktionieren und zu sehen sind. Hast Du eine Lösung gefunden?

 

[picollo]

Nein, leider nicht. Ich bin dazu übergegangen, die Dateien vom Mac aus zu löschen, da ich den Linux Server immer weniger als "Workstation" missbrauche.

 

[picollo]

Ach ja, wenn ich die vom Linux-Server aus lösche, aber von dort aus dem Papierkorb wieder herstelle, ist alles in Ordnung. Aber lösche ich die Datei im Share und kopiere die gleiche Datei vom Schreibtisch wieder in das Share (die exakt gleiche Datei, also eine Kopie), dann wird ein aus Sicht des Mac nicht löschbarer Ordner im Share angelegt.

 

[picollo]

Meine smb.conf (Auszug):


[global] ... # nur wenn SMBv1 benötigt wird (alte Smart-TV-Geräte): # client min protocol = NT1 # server min protocol = NT1 # Anpassungen SMB2 für macOS: server min protocol = SMB2 client min protocol = SMB2 server signing = disabled client signing = disabled smb encrypt = off deadtime = 15 multicast dns register = no host msdfs = yes # Anpassungen für macOS ea support = yes vfs objects = catia fruit streams_xattr fruit:aapl = yes fruit:metadata = stream fruit:resource = file fruit:model = MacSamba fruit:nfs_aces = yes fruit:copyfile = no fruit:veto_appledouble = no fruit:posix_rename = yes fruit:zero_file_id = yes fruit:wipe_intentionally_left_blank_rfork = yes fruit:delete_empty_adfiles = yes fruit:locking = none # "fruit:locking = netatalk" setzen, wenn AFP aktiviert wird ... # Windows Kompatibilität ntlm auth = ntlmv1-permitted inherit acls = yes inherit permissions = yes ... # ----- Share definitions ----- ... [My-Share] fruit:aapl = yes ea support = yes path = /srv/egal/auchegal public = no read only = no browseable = yes writeable = yes create mask = 0664 directory mask = 0775 valid users = @sambashare msdfs root = yes

Die Definition "valid users = @sambashare" ist für User, die Mitglied der user group "sambashare" auf dem Ubuntu Server sind.

Mit diesen Einstellungen kann ich Daten zwischen dem Linux Samba-Server und einem Mac hin- und her kopieren und auch löschen, ohne das vom Mac aus nicht löschbare "Ordner" als Dateisymbole für normale Files auftauchen.

 

[macati]

Vielen Dank, wird getestet!

 

[picollo]

Denk dran, die Mount Optionen in der /etc/fstab deines Linux-Server müssen für die Share Partition auch angepasst werden:

UUID=67f279c4- .......-7a373635/srv/egal ext4 defaults,user_xattr,acl 0

Allerdings, wenn man vom Linux-Server aus eine Datei im Share ausschneidet, die Datei auf den Server in den Schreibtisch oder wo anders hin verlagert, diese Datei doch wieder zurück kopieren möchte, gibt es Kuddelmuddel. Anscheinend ein Rechte- oder Inode-Problem, das ich noch nicht identifiziert habe.

Du kannst aber in Linux eine Datei im Share löschen und über den Papierkorb wieder herstellen oder aber Dateien von anderen Verzeichnissen aus (Mac oder Linux) hin und her kopieren. Endgültig löschen im Share würde ich immer vom Mac aus. Linux ist das egal, aber dem Mac nicht. Anscheinend gibt es doch noch Inkompatibilitäten, die bei solchen Vorgängen des jeweiligen Systems nicht richtig interpretiert werden können oder aber viel mehr Zeit zur Synchronisation benötigen.

Du musst also wissen, was dein bevorzugtes Arbeitssystem ist:
Linux-Server: im Share nur die Daten bereitstellen, auf die du vom Mac aus zugreifen willst.
Mac: endgültige Löschung von Dateien/Ordner im Share nur vom Mac aus.

 

[picollo]

Noch etwas, unter Linux im Terminal zu sehen haben die vom Mac auf dem Samba-Share gespeicherten Dateien ein "+" Zeichen hinten dran: -rwxrwxr--+

Wenn man unter Linux die Datei im Terminal mit cp -a Dateiname ... kopiert, im Share vom Linux Server aus löscht und anschließend mit cp -a Dateiname .. unter Linux wieder zurück kopiert, tritt o. g. Fehler nicht auf. Es muss also eine Änderung in den Fileeinträgen sein, der beim Ausschneiden aus dem Share vom Linux-Server aus auftritt wobei der Urzustand nicht wieder hergestellt wird.

Es ist sicherlich nicht die klassische Vorgehensweise, eine Datei vom Linux-Server aus auszuschneiden, wo anders hin zu verlagern und anschließend wieder in das Share zurück zu kopieren. Sollte das mit einer wichtigen Datei passieren, dann einfach vom Linux-Server aus diese Datei auf einen USB-Stick kopieren und im Mac wieder einspielen.

 

[macati]

Sollte das mit einer wichtigen Datei passieren, dann einfach vom Linux-Server aus diese Datei auf einen USB-Stick kopieren und im Mac wieder einspielen.

Das habe ich auch schon praktiziert (externe HDD), weil ich keine andere Möglichkeit gefunden habe, die Daten zu "retten".

 

[OmarDLittle]

Vielleicht liegt es einfach an den Zugriffsrechten, du müsstest dir die Rechteverwaltung von Linux genauer anschauen. Jedes Verzeichnis und jede Datei hat Zugriffsrechte für einen User, eine Gruppe, und für alle anderen. Mit chown kannst du User und Gruppe ändern, mit chmod kannst du die Rechte ändern, die User, Gruppe, sowie andere haben. Die beim Share festgelegten Masken in der smb.conf sollten dann auch stimmen, also create mask (Dateien) und directory mask (Verzeichnisse), da hast du wohl irgendwo was übernommen ohne es anzuschauen.

Am besten weist du dem Share eine Gruppe zu wo alle smb-User drin sind, bei dir wär das wohl sambashare. Und als User nimmst du einfach root, weil irgendwas als User drinstehen muss. Root solltest du aber nie aktiv verwenden oder extra im Samba berechtigen, das steht nur als Platzhalter für die Berechtigung drin, weil du ja einer ganzen Gruppe Zugriff gibst, und der User egal ist.

Das machst du mit

chown -R root:sambashare /srv/egal/auchegal

Wobei du darauf achten musst, dass die Gruppe sowohl auf /srv als auch auf /srv/egal berechtigt ist, weil sie sonst den Unterordner auchegal nicht öffnen kann, unabhängig von Samba, d.h. besser wäre der Befehl hier:

chown -R root:sambashare /srv

Mit dem -R werden die Rechte rekursiv auf alle Unterverzeichnisse angewandt.

In der smb.conf änderst du die Werte wie folgt ab:

create mask = 0660
directory mask = 0770

Das führt dazu, dass User und Gruppe auf Dateien und Ordner rw-Zugriff haben, und auf Ordner zusätzlich Ausführungsrechte. Ausführungsrechte werden benötigt, um Ordner öffnen zu können, Dateien brauchen das nicht (daher hat die Datei-Maske create mask mit 6 um dieses eine Recht weniger als directory mask mit 7).

Anschließend musst du unbedingt einmal alle Files auf die richtigen Masken umschreiben:

chmod -R u=rwX,g=rwX,o= /srv

chmod modifiziert hiermit die Berechtigungen so, dass der User (root) rw-Zugriff hat und X auf Verzeichnisse (also ausführen, damit sie sich öffnen lassen, das großgeschriebene X signalisiert dass die Berechtigung nur für Verzeichnisse gilt und nicht für Dateien, wo du das nicht brauchst), das gleiche für die Gruppe (sambashare), und o= heißt dass others, also alle anderen die nicht root oder in der Gruppe sind, überhaupt keinen Zugriff haben.

Und das musst du auf der allerersten Ebene /srv bereits anwenden, damit der gesamte Pfad von Anfang bis Ende korrekt berechtigt ist.

Wenn du am Fileserver selbst etwas änderst, musst du sicherstellen dass du es mit einem User tust der in der sambashare-Gruppe drin ist. Andere haben ja keine Berechtigung (sollen ja auch nicht irgendwelche User zugreifen können die nicht für den Share berechtigt sind).

Ein Problem hast du aber noch: Wenn du am Fileserver etwas in den Papierkorb verschiebst, und nachher wieder zurück, dann kann es sein dass sich die Berechtigungen ändern. Weil Berechtigungen vom Zielverzeichnis beim Verschieben übernommen werden können. Du solltest alles innerhalb des Share-Verzeichnisses belassen. D.h. wenn du am Fileserver was löschen willst, leg dir einen Ordner Papierkorb innerhalb vom Share rein und verschieb die Files einfach dorthin. Dann kannst du am Ende alles aus dem Ordner entgültig löschen wie aus dem aktuellen Papierkorb auch - mit dem wichtigen Unterschied, dass die Berechtigungen nicht verändert werden, wenn du das File aus diesem Ordner wieder an seinen Ursprungsort schiebst.

Schlussendlich kannst du das alles überprüfen mit

ls -alh /srv/

womit dir die Unterordner und Dateien mit ihren Zugriffsrechten aufgelistet werden, das sollte dann so aussehen:

user@dateiserver:~$ ls -alh /srv/
total 80K
drwxrwx---  12 root sambauser  14 May 1 11:56 .
drwxr-xr-x  15 root root       15 Apr 1 15:52 ..
drwxrwx---  58 root sambauser     119 Nov 1 21:30 egal

drwxrwx---: d am Anfang zeigt an dass es ein Verzeichnis ist, rwx rwx stehen für die Rechte für User und Gruppe und die drei Striche am Ende zeigen an, dass andere User gar keinen Zugriff haben.

Wenn du doch etwas wild herumkopiert hast und auf den Clients nicht öffnen kannst, dann kannst du am Server die Rechte wieder gleichziehen, dazu einfach den chown-Befehl und den chmod-Befehl wieder ausführen. Am besten machst du aber auf einem Server gar nix, sondern alles nur auf den Clients, dann brauchst du keine Workarounds und die Zugriffsrechte können nicht kaputt werden.

 

[picollo]

Das habe ich auch schon praktiziert (externe HDD), weil ich keine andere Möglichkeit gefunden habe, die Daten zu "retten".

Es gibt noch eine andere Möglichkeit der Rettung: eine Freigabe auf dem Mac einrichten, am Linux-Server einbinden und vom Linux-Server aus darauf die Dateien kopieren. Die Rechtevergabe erfolgt dann auf dem Mac und die ist korrekt.

Wenn du die Dateien dann vom Linux-Server löschst und ein vernünftig konfiguriertes /etc/smb.conf hast (siehe oben), kannst du die Dateien zurück auf den Linux-Server kopieren. Damit besitzen diese Dateien auch auf dem Linux-Share wieder vernünftig ergänzte Rechte, die vom Mac richtig interpretiert werden können.

 

[picollo]

...
Ein Problem hast du aber noch: Wenn du am Fileserver etwas in den Papierkorb verschiebst, und nachher wieder zurück, dann kann es sein dass sich die Berechtigungen ändern. Weil Berechtigungen vom Zielverzeichnis beim Verschieben übernommen werden können. Du solltest alles innerhalb des Share-Verzeichnisses belassen. D.h. wenn du am Fileserver was löschen willst, leg dir einen Ordner Papierkorb innerhalb vom Share rein und verschieb die Files einfach dorthin. Dann kannst du am Ende alles aus dem Ordner entgültig löschen wie aus dem aktuellen Papierkorb auch - mit dem wichtigen Unterschied, dass die Berechtigungen nicht verändert werden, wenn du das File aus diesem Ordner wieder an seinen Ursprungsort schiebst.
...

Das ist ein wichtiger Tipp. Auf jeden Fall nicht die SMB interne Papierkorbfunktion aktivieren:
...
# vfs objects = recycle
# recycle:repository = .recyclebin
...
sondern so, wie @OmarDLittle es beschrieben hat. Die normale Linux spezifische Papierkorb-Funktion funktioniert zwar, aber nur für die Wiederrufen-Funktion. Einmal richtig gelöscht und wieder zurück kopieren, woher auch immer, kann zu dem von mir beschriebenen Problemen wie Ordner-Ikone statt Datei-Ikone oder nicht löschbar führen.