MOM2006
Aktives Mitglied
        Thread Starter
    
				
					
						- Registriert
- 21.09.2011
- Beiträge
- 3.901
- Reaktionspunkte
- 1.296
nun ja, viellicht liegt es ja an der Art und Weise wie du dein NAS eingerichtet hast und wie deinen Mac.
Auf dem NAS verwendest du ACL hast du geschrieben. So wie du das geschrieben hast, hast du das womöglich auf Ebene des Filesystesm gemacht und nicht auf Ebene von Samba. Deine Ausgabe von testparm -s gibt da nichts zu ACL her.
Ich verwende Berechtigungen am NAS, wie das Synology intern dann macht interessiert mich erstmal nicht, da es soweit funktioniert.



Vielleicht verdeutlichen die Screenshots mehr, was ich mit Berechtigungen (ACL) meine.
Die erwiterten attribute, die du im Terminal auf dem share siehst, sind _nicht_ von macOS angelegt, sondern werden von Samba so über smb ausgeliefert an macOS.
Warum?
Der ursprüngliche Ordner vor dem Kopieren hatte keine erweiterten Attribute. Und diese erw. Attritubte tauchen nach deinen Aussagen auch dann auf, wenn die Ordner von einem Windows-Client auf das Nas kopiert wurden und du im Terminal von macOS aus diese Ornder ansiehst.
Falsch hier dürftest du etwas verwechselt haben oder ich habe es nicht klar und deutlich beschrieben. Also nochmal was passiert:
Auf MacOS im Finder erstelle ich unter meinem Benutzerverzeichnis einen Ordner TempCopy. In diesen kopiere ich ein paar Videodateien rein, die ebenso auf der lokalen Disk am mac liegen. Zur Kontrolle eine dir Listening davon im Terminal.
		Code:
	
	xxx@imac-xxx ~ % ls -la
total 10936
drwxr-x---+ 29 xxx     staff    928 13 Mai 12:42 .
drwxr-xr-x   5 root    admin    160 13 Mai 08:30 ..
...
drwxr-xr-x+  4 xxx     staff    128 13 Jan 23:06 Public
drwxr-xr-x  12 xxx     staff    384 13 Mai 08:41 TempCopy
xxx@imac-xxx ~ %Der Ordner TempCopy hat noch keine erweiterten Attribute. Nun kopiere ich diesen Ordner vom iMac auf die Freigabe am Synology NAS, die per SMB eingebunden ist.
Nach dem Kopieren prüfe ich das Ergebnis aus dem Terminal vom Mac am Nas.
		Code:
	
	xxx@imac-xxx ~ % mount
...
//xxx@diskstation/diskstation/shared on /Volumes/shared (smbfs, nodev, nosuid, mounted by xxx)
xxx@imac-xxx ~ % cd /Volumes/shared/Downloads
xxx@imac-xxx Downloads % ls -la
total 280
drwx------  1 xxx     staff  16384 13 Mai 12:47 .
drwx------  1 xxx     staff  16384 12 Jan 19:08 ..
-rwx------@ 1 xxx     staff   8196 13 Mai 12:48 .DS_Store
drwx------  1 xxx     staff  16384 26 Dez 15:03 CeeCoach
drwx------  1 xxx     staff  16384 12 Jan 21:36 Dateierweiterungen anpassen
drwx------  1 xxx     staff  16384 13 Jan 23:27 Downloads Mac
drwx------  1 xxx     staff  16384 22 Feb 16:01 Downloads Windows
drwx------  1 xxx     staff  16384 22 Feb 12:31 ISO Files
drwx------@ 1 xxx     staff  16384 13 Mai 08:41 TempCopy
xxx@imac-xxx Downloads % xattr -l TempCopy
com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:
xxx@imac-xxx Downloads % xattr -c TempCopy
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
xattr: [Errno 20] Not a directory: 'TempCopy'
xxx@imac-xxx Downloads %Für meine folgenden Ausführungen unterstelle ich mal, dass dein NAS als Dateisystem ext4 verwendet und auf Linux-Basis läuft (tut ja Synology) Linux kann aber grundsätzlich nicht selbst mit Windows ACL = NFSv4 ACL (die faktisch identisch mit den ACL sind, die macOS nutzt) umgehen und diese nicht im Dateisystem selbst vollständig speichern.
Ich verwende BTRFS siehe auch Screenshot

Samba ist da also in einem Konflikt, wie es diese ACL nun verwalten, speichern und bei Zugriffen von clients ausliefern soll. Dazu verwendet Samba erweiterte Attribute.
Wenn du nun auf dem NAS ACL verwendest (wie erwähnt, hattest du das ja so geschrieben) _muss_ Samba diese ACL auch an die Clients ausliefern.
Wenn das nun ACL sind, die du auf Ebene des Dateisystems verwendest, wird Samba diese nicht anfassen, mit der Folge, dass du die nicht über smb löschen kannst.
Das ist meine Erklörung zu deinem "Problem", auch wenn ich dir eigentlich, wegen deiner sehr persönlichen angrefenden art, eigentlich gar nicht helfen wollte. Mir ist es aber wichtig, dass andere Mitleser dieses Thread halt auch Wissen erlangen können.
Ich würde hier also als Tipp geben: verzichte auf ACL
Ok soweit verstehe ich das ja generell. Aber gemäß Codeauszug vom ls gibt es ja auch eine Datei ._DS_Store mit erweiterten Attributen. Und da kommt nun erstaunliches. Ich kann diese löschen. Also bin ich mir wiederum nicht sicher ob es an den ACLs liegt.
		Code:
	
	xxx@imac-xxx Downloads % xattr -l .DS_Store
com.apple.FinderInfo:         @
xxx@imac-xxx Downloads % xattr -c .DS_Store
xxx@imac-xxx Downloads % ls -la
total 280
drwx------  1 xxx     staff  16384 13 Mai 12:47 .
drwx------  1 xxx     staff  16384 12 Jan 19:08 ..
-rwx------  1 xxx     staff   8196 13 Mai 12:48 .DS_Store
drwx------  1 xxx     staff  16384 26 Dez 15:03 CeeCoach
drwx------  1 xxx     staff  16384 12 Jan 21:36 Dateierweiterungen anpassen
drwx------  1 xxx     staff  16384 13 Jan 23:27 Downloads Mac
drwx------  1 xxx     staff  16384 22 Feb 16:01 Downloads Windows
drwx------  1 xxx     staff  16384 22 Feb 12:31 ISO Files
drwx------@ 1 xxx     staff  16384 13 Mai 08:41 TempCopyZusammenfassend anhand der Screenshots wirst du ja eingestehen, dass es etwas komplex ist. Ausgehend davon, dass auf der Mac Platte das Verzeichnis vor dem Kopieren keine erweiterten Attribute besitzt, hat es nach dem Kopieren welche und zwar jene die der Finder setzt um im Falle des Abbruchs vom Kopieren wieder fortsetzen zu können. Das macht der Finder auch wenn Dateien oder Ordner lokal von einer Location auf die andere kopiert werden. Ist das Kopieren erfolgreich löscht "das Kopieren" diese Attribute wieder. Wir sprechen hier von den Attributen
com.apple.finder.copy.source:
com.apple.finder.copy.checkpoint#N:
com.apple.metadata:kMDItemResumableCopy:
Auf dem NAS scheint das nicht zu funktionieren, weil eben der Fehler Not a Directory kommt. Deswegen bleiben sie leer am Ordner erhalten.
Abschließend wäre das Ergebnis folgenden Tests interessant: Kopiere den Ordner zurück vom NAS auf den Mac und prüfe dann ob dort auf dem Mac erweiterte Attribute vorhanden sind und falls ja, ob du sie löschen kannst.
Here we go. Ich kopiere den Ordner extra an einen anderen Ort auf meiner lokalen Disk (~/Downloads). Ergebnis:
		Code:
	
	xxx@imac-xxx Downloads % pwd
/Volumes/shared/Downloads
xxx@imac-xxx Downloads % cd ~/Downloads
xxx@imac-xxx Downloads % pwd
/Users/xxx/Downloads
xxx@imac-xxx Downloads % ls -la
total 10564704
drwx------+ 36 xxx  staff        1152 13 Mai 13:08 .
drwxr-x---+ 29 xxx  staff         928 13 Mai 13:08 ..
-rw-r--r--@  1 xxx  staff        8196 13 Mai 13:08 .DS_Store
-rw-r--r--   1 xxx  staff           0 13 Jan 23:06 .localized
...
drwx------@ 12 xxx  staff         384 13 Mai 08:41 TempCopy
...
xxx@imac-xxx Downloads % xattr -l TempCopy
com.apple.finder.copy.source:
xxx@imac-xxx Downloads % xattr -c TempCopy
xxx@imac-xxx Downloads % ls -la
total 10564704
drwx------+ 36 xxx  staff        1152 13 Mai 13:08 .
drwxr-x---+ 29 xxx  staff         928 13 Mai 13:08 ..
-rw-r--r--@  1 xxx  staff        8196 13 Mai 13:08 .DS_Store
-rw-r--r--   1 xxx  staff           0 13 Jan 23:06 .localized
...
drwx------  12 xxx  staff         384 13 Mai 08:41 TempCopyDer Finder verändert ja diese Attribute wieder und hinterlässt auch eines davon am Verzeichnis, welches ich lokal löschen kann. Dieses hier aufgezeigte Verhalten habe ich auch, wenn ich einen Ordner vom Mac mittels Finder auf einem Share kopiere, der per SMB von Windows 11 Pro bereit gestellt wird.
Ich hoffe nun ist etwas klarer was ich genau meine.
 
 
		 
 
		 
 
		 
 
		 
 
		 
 
		 
 
		