Hallo,

bei mir läuft ein Synology DS 1618+ als Fileserver in einem Netzwerk mit Macs, jeweils aktuellstes macOS.

Seit kurzem habe ich folgendes Problem:
Wenn ich einen bestimmten Ordner duplizieren möchte, der auf dem NAS liegt vom Mac aus duplizieren möchte, kommt folgende Fehlermeldung:


Das ist seltsam, denn:
1)
Der Ordner wurde seit Jahren zigmal erfolgreich dupliziert. Da es sich um einen verschachtelten Projektvorlageordner mit vielen Unterverzeichnissen und Vorlagedateien handelt, wäre es sehr mühsam ihn neu bauen zu müssen.

2)
Die sinngemäß gleiche Fehlermeldung kommt, wenn ich den Ordner von einem Windows 11 Rechner aus duplizieren lasse. Es scheint also kein Mac zu sein.

3)
Wenn ich eine 4 Jahre alte Version des Ordners aus Backups rekonstruiere und diese duplizieren möchte, kommt der Fehler ebenfalls. Obwohl in den letzten Jahren der Ordner vielfach erfolgreich dupliziert wurde. Es kann also nicht daran liegen, dass in dem Ordner eine Veränderung passiert ist, die zu dem Rechteproblem führt.

4)
Ich hab' die Zuweisung der Benutzerrechte für den Ordner auf dem NAS geprüft. Das scheint alles zu passen.

5)
Viele andere Ordner lassen sich duplizieren. Es gibt aber auch solche, bei denen die gleiche Fehlermeldung kommt. Eine Regel kann ich dabei nicht erkennen.


Hat jemand eine Idee?
Danke für Hinweise
Fadenschein

Die Meldung habe ich auch ab und zu.

Das liegt an den neuen Sicherheitseinstellungen vom Mac ... mal sehen ob ich Beispielbilder finde. ...

Noch eine Frage:
Greifen unterschiedliche Nutzer auf die SMB Freigabe zu und hast du z. B. PDF Dateien gespeichert?

... hab gerade keine Bilder parat.

Versuche doch mal die Datei ausfindig zu machen die sich nicht duplizieren oder öffnen lässt.
Wenn dann die Meldung von macOS kommt musst du direkt in die Systemeinstellungen gehen unter Datenschutz & Sicherheit

taucht dann ganz unten im Bereich Sicherheit ein Hinweis auf, dass du die Datei trotzdem öffnen kannst.

musst du für jede Datei der Reihe nach machen.

Der ganze Mist passiert, weil unterschiedliche Nutzer an den selben Dateien arbeiten. Ist zumindest bei mir so.

Bei mir lassen sich alle Dateien öffnen. Lediglich der Versuch einen Ordner zu duplizieren, wird mit der Fehlermeldung abgebrochen.

Bei dir scheint ein anderes Problem vorzuliegen als bei mir. Im Bereich 'Sicherheit' erscheint gar nichts, wenn der Duplizieren Befehl abgebrochen wird.

Das Seltsame ist:
Bei manchen Ordnern, bei denen die Fehlermeldung kommt, kann ich jedes Teil innerhalb des Ordners problemlos duplizieren. Also bspw. jeden Unterordner und jede Datei.
Der 'Stör' Ordner selbst ist unauffällig: die Rechte scheinen korrekt vergeben.

Keine Ahnung woran das noch liegen könnte...

Arbeitest du mit mehreren Benutzern?
Kannst du das mal testen?

Bei mir ist es manchmal so, dass ein Benutzter alle Dateien öffnen kann, dann Änderungen speichert. Versucht danach der andere Benutzer die Datei zu öffnen. Geht es nicht mehr und ich muss über Systemeinstellungen/Sicherheit die Datei erst wieder „freischalten“. Das Duplizieren klappt auch erst nach der Freischaltung wieder.

Ich hab leider kein Bild davon wie es aussieht, wenn ich eine Datei in der Sicherheit wieder freischalte.

Früher war das Freischalten mit einem Rechtsklick auf die Datei möglich. Seit macOS 15 muss man das in den Systemeinstellungen/Sicherheit machen.

Das hört sich nach einem weit verbreiteten Missverständnis an. Die Rechte für einen Ordner gelten wirklich nur für diesen Ordner, nicht für seinen Inhalt. Jede Datei und jeder Unterordner hat wieder eigene Rechte. Ob ein Ordner freigegeben ist oder nicht, spielt dabei keine Rolle.

Es gibt nur zwei Ausnahmen von dieser Regel:
1. Der File Server ist ausdrücklich auf eine "altmodische" Betriebsart eingestellt, wie sie vor 30 Jahren in kleinen Privatnetzen gängig war: Da war es tatsächlich so, dass die Rechte für einen freigegebenen Ordner automatisch auch für seinen ganzen Inhalt gültig war.
2. Du hast einen Teil der Rechte für die oberen Ordner über eine Zugriffssteuerungliste (ACL) definiert und für die Zugriffssteuerungseinträge ein oder mehrere Vererbungsfunktionen aktiviert. In diesem Fall werden die betroffenen Rechte automatisch während des Anlegens neuer Objekte an untergeordnete Objekte weitergegeben. Diese kopierten Rechte können danach jedoch wieder überschrieben werden.

Du solltest also mal diese Ordnerhierarchie über die UNIX-Befehlszeile kopieren. Die sagt Dir ganz exakt, mit welcher Datei etwas nicht stimmt. Auch Fehler mit Dateinamenscodierungen oder versehentlich gesperrte Dateien werden dort genauer angezeigt, was der Finder fälschlicherweise auch als "Problem mit Zugriffsrechten" meldet. In manchen Versionen von macOS ist es sogar der Finder selbst, der den Fehler verursacht, indem er Sperren für exklusiven Zugriff bei Anzeigevorgängen zu lange auf Dateien belässt.

Das ist leider komplette Fantasie. Über Systemeinstellungen > Sicherheit kann man überhaupt keine Dateirechte beeinflussen. Man kann dort nur Programmbefugnisse steuern, also ob ein bestimmtes Programm (zusätzlich zu den Benutzerrechten, die damit überhaupt nichts zu tun haben und weiterhin gelten) Zugriffe auf datenschutzrelevante Bereiche des Computers machen darf.

Probleme mit Benutzerrechten werden als "Zugriff verweigert" gemeldet. Probleme mit Programmbefugnissen werden als "Vorgang nicht gestattet" angezeigt.

Danke für die sehr ausführlichen interessanten Erläuterungen.
Tatsächlich hatte ich im Terminal die Rechte aller Ordner, Unterordner und Dateien auflisten lassen und diese waren bei allen Elementen gleich und korrekt.
Gesperrt war auch nichts.
Und da das Phänomen auch bei einem Zugriff von Windows aus auftritt, kann ich dem Finder nicht die Schuld in die Schuhe schieben.

Ich bin ratlos aber werde weiter forschen.

Nicht nur die POSIX-Rechte, sondern auch die Zugriffssteuerungslisten und die BSD-Attribute?

Blöde Frage, aber hat der User, welcher die Ordner kopieren soll, in DSM überhaupt Schreibrechte für das Ziel der Kopieraktion? Nicht das über das User-Management von DSM lediglich Leserechte eingetragen sind.

Du wolltest ja Ideen und Hinweise: meine Idee ist die, dass das Zielverzeichnis in dem das Ordner-Duplikat angelegt werden soll, Benutzerrechte vererbt, die die Duplizier-Aktion nicht zulassen. Wenn Du Finder>Ablage>Duplizieren verwendest, wird das Duplikat ja an Ort und Stelle auf dem NAS angelegt, aber mit anderen Tools ist es auch möglich, das das Duplikat z.B. auf einem lokalen Speicherort angelegt wird, den dann nicht das NAS, sondern z.B. der Mac verwaltet. Wie Marcel Bresink schon sinngemäß sagte, ist der Finder bei Problemen mit Benutzerrechten eher suboptimal. Sehr hilfreich finde ich dafür den "Path Finder" von https://cocoatech.io . Damit kann man sich die Posix-Rechte, die ACLs und die sich ergebenden tatsächlichen Rechte anzeigen lassen. Das sieht bei mir z.B. für das Verzeichnis /Users/Shared/ auf dem Mac so aus:
Posix:

Posix-ACL:

tatsächliche Rechte:

Vielleicht hilft Dir Path Finder weiter. Es gibt einen kostenlosen Testzeitraum mit vollem Funktionsumfang.
Du kannst Dir in der Listendarstellung eines Verzeichnisses auch für alle Dateien den Eigentümer und die Benutzerrechte auflisten lassen und auch danach sortieren!

Zugriffslisten ja - BSD Attribute nein
Vielleicht liegt da der Hase begraben.

ja, hat er. Wie oben beschrieben: es hat jahrelang funktioniert. Und bis auf das Duplizieren einiger Ordner geht auch nach wie vor alles problemlos.

Super Tipp, Danke

Ja, gerne. Ich hoffe, Du findest die Ursache für das Problem. Benutzerrechte (gerade mit ACLs) sind wirklich ein mächtiges Werkzeug und auch ein komplexes Thema, für das es abgesehen von den entsprechenden Terminal-Befehlen wenig Unterstützung in den Bordmitteln von macOS gibt. Würde mich interessieren, was bei Dir dabei herausgekommen ist...

Du kannst die Rechte an einem Objekt (Ordner, Datei) ja bekanntermaßen über die Informationen (Rechtsklick im Finder und dann auf "Informationen") einsehen und einstellen. Dabei hat Apple für mich die Sicherheit zuletzt für mich eher verschlimmbessert. Zwar funktioniert bei dem ausgewählten Objekt weiterhin alles wie erwartet. Dass sich die Zugriffsoptionen aber auf sämtliche Unterobjekte übertragen, bedarf jetzt eines weiteren Eingriffs.
Dazu müssen zunächst die Zugriffsrechte in den Informationen zu einem Ordner freigegeben (entsperrt) werden. Anschließend kann über das rechte Symbol die Freigabe auf sämtliche Unterordner ausgedehnt werden. Das muss auf möglichst hoher Ebene der Dateihierarchie passieren, damit nicht plötzlich zwischenzeitlich neu angelegte Objekte den Zugriff verweigern.

Ich kenne das auch auf meinen NAS (Plural) von Synology genau so. Unklar, wann und warum das passiert.
Für uns hat sich als Workaround ergeben, dass wir wie Kehrblech auch schreibt den übergeordneten Folder ansteuern, Apfel-i drücken, auf das Schloss klicken, Kennwort eingeben, und für die benötigte Gruppe (und wenn die nicht da ist oder schon die Rechte hat: everyone) lesen und schreiben anwählen und das auf alle Unterobjekte anwenden.

Es wäre so schön, dir Ursache zu kennen und es dann vorher schon vermeiden zu können. Aber soweit sind wir noch nicht, wobei ich mir den Tipp mit Pathfinder mal ansehen werde (danke dafür).

Kehrblech: der Befehl "auf alle Unterobjekte anwenden" ist wirklich mit Vorsicht zu geniessen, gerade wenn er sehr weit oben in der Dateihierarchie angewendet wird und man nur wenig Kontrolle hat, welche Art von Dateien sich in den Unterverzeichnissen befinden. Manche Dateien bzw. Pakete brauchen geeignete Benutzerrechte, sonst kommt die Software, die Dateien oder Verzeichnisse beschreibt oder irgendetwas an Metadaten (auf Dateisystem-Ebene) ändern will nicht klar. Zum Beispiel würde ich vermeiden, die Benutzerrechte der Apple Fotos Library auf diesem Weg zu ändern. Das gibt mit hoher Wahrscheinlichkeit Probleme, die sich automatisiert kaum noch rückgängig machen lassen (außer mit einem Backup). Selbst wenn die Dateien homogen sind - z.B. nur Videodateien in einer beliebigen Ordnerstruktur, ist dies mit Bordmitteln schon nicht mehr trivial, weil z.B. die Verzeichnisse andere Rechte als die Videodateien haben sollen und schon dafür muss man die entsprechenden Terminal-Befehl bemühen, um zwischen Verzeichnissen und Dateien differenzieren zu können.
Dazu kommt noch, dass im Finder meines Wissens keine Möglichkeit besteht, die ACLs zu manipulieren. Er zeigt sie noch nicht einmal an...

Es ist unklar, was Du mit "jetzt" meinst. Das ist bereits seit Mac OS X 10.1 so, also seit 24 Jahren. Wie oben schon gesagt, ist es aus Sicherheitsgründen erwünscht, dass für jedes einzelne Objekt eigene Rechte gelten.

Vielleicht habe ich mich falsch ausgedrückt. Ich wollte keine Dateirechte einstellen. Ich habe nur einen Weg zeigen wollen der bei mir funktioniert.
Nach deinen Ausführungen kann es sein, dass ich nur einer App Benutzerrechte erteile. Bei mir ist es dann aber so, dass ich danach die Datei wieder kopieren, umbenennen und bearbeiten kann.
Welche Fehlermeldung jetzt genau bei mir auftaucht kann ich leider aus dem Kopf nicht mehr sagen. Gefühlt würde ich sagen es ist „Zugriff verweigert“, aber das muss ich mir beim nächsten mal genau merken. Im Moment kann ich den Fehler nicht reproduzieren, denn er taucht ohne System nur ab und zu auf.

Konkret passiert es im Zusammenspiel von einem freigegebenen Ordner, zwei Benutzern, dem Finder, Vorschau und Accrobat.
Erhalte ich dann die Fehlermeldung, taucht bei mir unter Systemeinstellung > Sicherheit die Möglichkeit auf die Datei zu öffnen. Erteile ich dann die Erlaubnis, funktioniert danach wieder alles.

Bei meiner externen SSD ist das eine Komplikation, die ich erst jetzt unter Sequoia beobachte. Vorher habe ich eine externe SSD oder Festplatte angehängt, und jeder Benutzer konnte auf alle Dateien und Ordner zugreifen. Nicht mehr seit Sequoia. Das funktioniert erst nach der oben beschriebenen Freigabe wieder. Vorher war jede neue Datei/Ordner für die anderen Benutzer an meinem Mac nur lesbar. – Vielleicht wurde etwas an der Standardeinstellung geändert – und vielleicht kämpft fadenschein mit genau dem gleichen Problem?

Du hast vermutlich das Volume auf der externen SSD mit der Finder-Einstellung "Eigentümer auf diesem Volume ignorieren" betrieben.

In dem Fall werden für jedes Objekt auf dem Volume zur Laufzeit "Virtuelle Dateirechte" errechnet, wobei der Eigentümer jedes Objektes vorübergehend auf denjenigen Benutzer abgebildet wird, der sich gerade an der "vordersten" Bildschirmsitzung angemeldet hat. Dadurch hat es den Anschein, als würde "jeder" Benutzer auf alle Objekte des Volumes zugreifen können.

Diese Betriebsart ist auf einem NAS oder anderen File-Server so nicht möglich, aber bei bestimmten Protokollen (wie z.B. SMB) findet ein ähnlicher Prozess statt, den Benutzer-Account auf dem Server auf den zugreifenden Benutzer-Account des Clients abzubilden.

Welche DSM Version ist installiert und wie lange ist das DS 1618+ lt. Systeminfo schon online? Manchmal behebt auch ein reboot der DSM seltsame Probleme...

PS: Duplikate lege ich auf der DS grundsätzlich mit dem Webinterface direkt auf der Synology an, mit FileStation spare ich mir die absolut unnötigen Transfers vom NAS zum Client und zurück und bin wesentlich schneller fertig. Mit 2 offenen FileStation Fenstern und aktiviertem DragnDrop geht das sehr schnell und einfach.

Das würde mich im Fall von fadenschein´s Problem sehr interessieren, was dann passiert. Es hängt von so vielen unbekannten Faktoren ab, dass es schwer ist, eine Prognose abzugeben...

Das ist für mich ein Indiz das es unabhängig vom eingesetzten OS ist. Da läuft irgendwas quer, z.b. Virenscanner, Cache das den Kopiervorgang stört. Hatte ich auch schon mehrmals mit DSM, konnte den Fehler jedoch nicht eingrenzen. Gerade wenn z.B. auch noch auf der Synology selbst ein Virenscanner läuft kann es da zu seltsamen Kombinationen kommen. Mir wurde am Client z.b. angezeigt, ich könnte eine Datei nicht löschen, da sie im Zugriff sein (was definitiv nicht stimmte). Mit FileStation direkt im Webinterface war es aber kein Problem.

rmayergfx: möglicherweise ist es aber genau so, wie es die Fehlermeldung behauptet. Ich hatte die gleiche Fehlermeldung auf dem Mac, allerdings erfolgte das Duplizieren nicht auf einem NAS, sondern auf einer extern per Thunderbolt angeschlossenen SSD. Ich habe mit Path Finder die Benutzerrechte einiger Dateien im zu duplizierenden Verzeichnis auf der SSD geändert und dann ging es fehlerfrei.

Wenn die Daten tatsächlich vom Mac und von Windows aus verändert werden, kann das auch ganz andere Ursachen haben, wie zum Beispiel ungeeignete Dateinamen.

macOS und Windows verwenden in Dateinamen zwar beide Unicode in UTF-8-Codierung, aber beim Mac werden potenziell zusammengesetzte Zeichen (z.B. Umlaute) nach der Regel "Normalisierung Typ D" verarbeitet, bei Windows gemäß "Normalisierung Typ C". Auch hier ist möglich, dass der Finder falsche Fehlermeldungen anzeigt, wenn er einen verbotenen Dateinamen findet.

Ohne einen Kopierversuch im Terminal werden wir nie wissen, an welcher Datei es liegt …

Marcel Bresink: allerdings ist zu bedenken, dass das Duplizieren des Verzeichnisses in der Vergangenheit funktioniert hat, siehe fadenschein: "Der Ordner wurde seit Jahren zigmal erfolgreich dupliziert.". Irgendetwas muss sich also in letzter Zeit geändert haben. Ich nehme an, dass das Verzeichnis in der Vergangenheit also sowohl von einem Mac als auch einem Windows-Rechner aus erfolgreich dupliziert wurde (also nicht mit FileStation). Vielleicht nehmen es neuere macOS oder Windows-Versionen mit den Benutzerrechten/ACLs einfach genauer als ältere Versionen; deshalb ging es früher. Damit habe ich mich aber nie tiefergehend beschäftigt, schon gar nicht unter Windows. Ist aber ohnehin alles spekulativ ohne weitere Angaben von fadenschein...

Ist auch bei mir ein "beliebtes" Problem. Teils kann ich es so lösen, dass ich den Löschvorgang dann nochmal starte bis zu der erneuten Meldung, und dann nach 2, 3, 4, 5 Versuchen ist alles weg. Irgendwie scheint das bis zu einem imaginierten Problem zu arbeiten, dann abzubrechen, und bei einem neuen Versuch kann dann weitergelöscht werden. Und wenn das dann auch nicht mehr geht, dann muss ich über die FileStation, was ich aber nervig und Umständlich finde.

Da wir nicht mit Windows-Rechner darauf zugreifen, und auch keinen Virenschutz installiert haben, sind diese Aspekte bei uns definitiv nicht Teil des Problems.

Ja, wie gesagt sind es oft auch Bugs im Finder im Zusammenhang mit Netzsperren für exklusiven Zugriff, die das Problem auslösen.

Vielleicht stehe ich auf dem Schlauch, aber 'Duplizieren' habe ich in der Filestation noch nicht gefunden.
Und wenn ich an die gleiche Stelle kopieren will, gibt es nur die Optionen 'Überschreiben' oder 'Überspringen'.

Die Frage ist aber trotzdem spannend und kann wie folgt beantwortet werden:
1) In der Filestation von Verzeichnis A nach B kopieren geht.
2) Mit dem Mac von Verzeichnis A nach B kopieren geht nicht.
3) Mit Windows von Verzeichnis A nach B kopieren geht nicht.
4) Mit dem Mac von Verzeichnis A auf den Mac kopieren geht.

Ich lege Duplikate nie in das gleiche Verzeichnis. Ich erstelle immer Ordner mit Syntax YYYY.MM.DD und kopiere die Daten dort hinein. Das passiert aber nicht oft, nur beim Bearbeiten von Dateien wo ich jederzeit wieder auf das Original zugreifen möchte. Ansonsten sind Duplikate nur Speicherfresser.

Vielleicht liegt das Problem ja darin das du im gleichen Ordner stehst. Hast du denn den Ratschlag von Marcel mal umgesetzt um zu sehen welche Datei die Fehlermeldung produziert?

In den Fällen 2,3 und 4 ist SMB aktiv, bei 1 nicht. Interessant ist, dass 4 funktioniert. Vermutlich würde 4 auch mit einem Windows-Client funktionieren. Aus der Tatsache dass 2 und 3 funktionieren kann man ziemlich sicher schlußfolgern, dass keine spezifische Samba-Version mit dem Problem in Zusammenhang steht, weil Deine Mac- und Windows-Clients unterschiedliche Samba-Versionen/Implementierungen verwenden. Da 2 und 3 aber früher auch funktionierten, tippe ich auf eine Veränderung bei Deinem NAS-System

Da fehlt ein NICHT vor dem funktionieren.

@fadenschein
Terminal ausprobieren und dann sehen wir weiter.

Ah, danke rmayergfx, Du hast Recht.
Die Schlussfolgerung bleibt ansonsten gleich, also "Aus der Tatsache dass 2 und 3 nicht funktionieren kann man ziemlich sicher schlußfolgern, dass..."

Mir fällt noch ein, dass Synology die Fehler bei 2 und 3 eigentlich nur erzeugt, wenn die Dateien sehr groß sind. Die Grenze kenne ich nicht. Bei mir hat das Kopieren einer Datei (3 MB) von Ordner A nach Ordner B mit dem Finder jedenfalls geklappt. Nur als ich eine große Datei (28 GB) kopieren wollte ging es nicht.
Ich nutze noch ext4 als Dateisystem auf der Synology.

@Fadenschein
Welches Dateisystem nutzt du auf der Synology? Btrfs oder ext4?

Ich benutze Btrfs.

Mit der Größe der Dateien hat es offenbar nichts zu tun.
Ich bin mir gar nicht sicher, ob Dateien das Problem verursachen, denn es tritt dann auf, wenn ich Ordner duplizieren möchte.

Warum manche Ordner betroffen sind und manche nicht, ist für mich nicht nachvollziehbar.

Bspw. habe ich einen Ordner 'Problembär' in dem es mehrere Unterordner und Unter-Unterordner gibt und hie und da eine Datei. Es ist möglich jeden Unterordner und Unter-Unterordner und jede Datei zu duplizieren, aber mit 'Problembär' klappt das duplizieren nicht.

JETZT wird's richtig spannend. Danke für die Erinnerung. Du meinst den Tipp den Ordner, der sich nicht duplizieren oder an andere Stelle kopieren lässt, über das Terminal zu kopieren?

Falls ja - die Auflösung ist verblüffend.
Ich habe einen Ordner, den ich nicht mit dem Finder (oder Windows) von einem Verzeichnis des NAS in ein anderes Verzeichnis kopieren kann, mit dem Befehl cp -R kopiert.

Und: es funktioniert. Völlig ohne Fehlermeldung.
Ich konnte es gar nicht glauben, und hab's gleich nochmal mit dem Finder probiert.
Geht weiterhin nicht. Mit der lapidaren Fehlermeldung mangelnder Zugriffsrechte.

Bringt das die Lösung?

Jein. Das würde bestätigen, dass der Finder selbst das Problem verursacht.

Wie gesagt wahrscheinlich ein Problem im "File Locking": Der Finder meldet beim Server exklusiven Zugriff auf die jeweils kopierten Dateien an, aber diese Sperren werden nicht schnell genug wieder entfernt.

Aber spricht da nicht dagegen, dass der Fehler unter Windows 11 auch passiert?
Wobei ich zugeben muss, dass ich das mangels PC nur unter Fusion getestet hab...

Mein Senf dazu... Hatte auch immer mal wieder Probleme mit meinem Mac und der Synology (langsame Transfers etc). Hab viele Einstellungen versucht, ohne Erfolg. Am Ende hab ich auf der Synology das Beta SMB Paket installiert und auf dem MAC die lokale nsmb.conf einfach gelöscht. Nach einem Reboot waren alle Probleme verschwunden Manchmal ists so einfach. Vermute aber mal, dass es bei deinem Problem nicht hilft...