Warum gehen Dateiberechtigungen verloren, wenn Dateien auf ein NAS verschoben werden?

Dateien können auf einem Computer, einer externen Festplatte oder im Download-Ordner normal funktionieren und nach dem Verschieben auf ein NAS schreibgeschützt, für eine App unsichtbar oder unzugänglich werden. Das bedeutet normalerweise nicht, dass die Datei beschädigt ist. Es bedeutet, dass die Dateien in ein neues Dateisystem mit einem anderen Eigentums- und Berechtigungsmodell gelangt sind.

Ein geräteübergreifendes Verschieben wird üblicherweise als Kopieren gefolgt von der Löschung der Quelle ausgeführt. Das NAS erstellt neue Dateien unter Verwendung der verbundenen SMB- oder NFS-Identität, der ACLs des Zielordners, UID- und GID-Werte, Umask, Container-Benutzer und serverseitiger Erstellungsregeln. Der schnellste Weg, das Problem zu beheben, ist herauszufinden, wer die Dateien erstellt hat, wem sie jetzt gehören und welcher Benutzer oder Prozess verweigert wird.

Das Verschieben von Dateien auf ein NAS erstellt normalerweise neue Dateien

Das Ziehen eines Ordners auf ein NAS kann in Windows Explorer oder Finder wie ein gewöhnliches Verschieben aussehen. Im Hintergrund sind jedoch die Quellfestplatte und das NAS separate Dateisysteme. Der Client liest die Originaldaten, erstellt neue Zielobjekte und löscht die Originale nach erfolgreichem Transfer.

Dies unterscheidet sich vom Verschieben einer Datei zwischen zwei Ordnern desselben Dateisystems, bei dem das System möglicherweise nur den Speicherort der Datei im Verzeichnis aktualisiert. Microsofts Beschreibung des Kopier- und Verschiebeverhaltens erklärt, dass Objekte, die auf ein anderes Volume kopiert werden, die Berechtigungen des neuen Ordners erben, während ein Verschieben im selben Volume normalerweise die bestehenden Berechtigungen beibehält.

Diese Unterscheidung erklärt, warum „Ausschneiden und Einfügen“ nicht garantiert, dass Eigentümer, ACL-Einträge oder erweiterte Attribute nach einer Übertragung auf ein NAS identisch bleiben. Das Zielsystem verschiebt das ursprüngliche Dateisystemobjekt nicht einfach.

Ziel-ACLs bestimmen, welche Berechtigungen neue Dateien erben

Wenn jede neu kopierte Datei dieselben unerwarteten Berechtigungen erhält, ist das übergeordnete Verzeichnis normalerweise wichtiger als die Quelldatei. Das Ziel kann vererbte ACL-Einträge, Standard-POSIX-ACLs, NFSv4-ACL-Flags oder NAS-spezifische Berechtigungsvoreinstellungen haben.

Beispielsweise kann ein freigegebener Ordner so konfiguriert werden, dass neue Dateien die Zugriffsrechte für eine Familiengruppe, eine Mediengruppe oder ein bestimmtes SMB-Konto erben. Ein fehlendes Vererbungskennzeichen kann das Gegenteil bewirken: Benutzer können auf die Wurzel des Datensatzes zugreifen, aber nicht auf neue Dateien darin.

TrueNAS-ähnliche Berechtigungssysteme unterscheiden zwischen POSIX- und NFSv4/SMB-ACL-Modellen. Wichtig ist, dass NFSv4- und SMB-ACL-Vererbung neue Dateien und Ordner steuern kann, während POSIX-Standards und Dataset-Grenzen sich anders verhalten. Überprüfen Sie vor Änderungen an einzelnen Dateien die ACL und Vererbungsflags im Zielordner.

Das NAS verwendet das verbundene SMB-Konto

Wenn ein Windows- oder macOS-Computer eine Datei über SMB kopiert, bewahrt das NAS normalerweise nicht die lokale Benutzeridentität des Client-Computers. Es erstellt die Zieldatei als das Konto, das am SMB-Share authentifiziert ist, oder als ein Konto, dem diese Sitzung zugeordnet ist.

Deshalb kann eine Datei, die einem Windows-Benutzer auf dem Quell-PC gehört, im Besitz von kenneth, nasuser, Gast, oder eine andere NAS-seitige Identität nach der Übertragung. Ein gespeicherter SMB-Zugang kann auch dazu führen, dass ein Computer Dateien unter einem anderen Besitzer erstellt als ein anderer Computer.

Überprüfen Sie den aktiven SMB-Benutzernamen, anstatt davon auszugehen, dass die Desktop-Anmeldung verwendet wird. Trennen Sie den Share, löschen Sie bei Bedarf veraltete Anmeldeinformationen und verbinden Sie sich erneut mit dem NAS-Konto, das die Dateien besitzen oder verwalten sollte.

Share-Zugriff und Datei-Zugriff sind separate Berechtigungsebenen

Ein Benutzer kann den SMB-Share öffnen und Ordner durchsuchen, aber dennoch keine Datei bearbeiten, umbenennen oder löschen. Das bedeutet, dass der Netzwerk-Share erreichbar ist; es beweist nicht, dass das Dateisystem die angeforderte Operation erlaubt hat.

Regeln auf Share-Ebene bestimmen, ob ein SMB- oder NFS-Client den Share betreten darf und ob die Verbindung als schreibgeschützt oder Lese-/Schreibzugriff präsentiert wird. Das zugrunde liegende Dateisystem bewertet dann für jede Datei und jedes Verzeichnis den Besitzer, die Gruppe, Modusbits, ACL-Einträge und Vererbungsregeln.

Fehlerbehebung auf beiden Ebenen. Ein als Lese-/Schreibzugriff markierter Share kann eine Dateisystem-ACL, die das Schreiben verweigert, nicht außer Kraft setzen, und permissive Dateisystem-Modi helfen nicht, wenn das SMB-Konto durch die Share-Konfiguration eingeschränkt ist.

Windows-ähnliche ACLs und POSIX-Modi stimmen nicht perfekt überein

Windows-Berechtigungen mehrere Benutzer und Gruppen, explizite Zulassungs- und Verweigerungseinträge, Vererbungsflags sowie separate Rechte für Lesen, Schreiben, Löschen und Ändern enthalten können. Traditionelle POSIX-Modusbits reduzieren den Zugriff auf Besitzer, Gruppe und andere.

Samba- und NAS-Betriebssysteme müssen zwischen diesen Modellen übersetzen. Ein Windows-Sicherheitsfenster kann eine detaillierte ACL anzeigen, obwohl ls -l zeigt nur eine vereinfachte Darstellung an. Umgekehrt führt das Ausführen von chmod kann Modusbits ändern, ohne die Windows-ähnliche ACL korrekt neu zu erstellen, die SMB-Clients erwarten.

Wenn das NAS-Dataset NFSv4- oder SMB-ACLs verwendet, überprüfen Sie die vollständige ACL über die NAS-Oberfläche oder einen ACL-kompatiblen Befehl. Gehen Sie nicht davon aus, dass eine Datei, die rwxrwx--- erzählen die gesamte Berechtigungsgeschichte.

UID- und GID-Abweichungen beeinflussen Linux, NFS und Apps

Linux-Systeme bestimmen Eigentum normalerweise über numerische Benutzer- und Gruppen-IDs. Der Benutzername ist nur ein Label, das mit diesen Zahlen verknüpft ist.

Zwei Systeme können beide einen Benutzer namens anzeigen media während der eine UID 1000 und der andere UID 1001 verwendet. Für Linux und NFS sind das unterschiedliche Identitäten. Eine Datei, die UID 1000 gehört, kann für eine Anwendung, die als UID 1001 läuft, unzugänglich sein, selbst wenn deren sichtbare Benutzernamen identisch aussehen.

Überprüfen Sie numerische Werte auf NAS, Host, Client und Anwendung:

id media
ls -ln /pfad/zu/dateien
stat /pfad/zu/dateien/beispiel.mkv

Vergleichen Sie die Zahlen und nicht nur die angezeigten Namen. Wenn mehrere Systeme dasselbe Speicherziel beschreiben müssen, stimmen Sie die erforderlichen UID/GID-Werte ab oder erstellen Sie eine gemeinsame Gruppe mit den richtigen Berechtigungen.

SMB und NFS können dasselbe Dataset als unterschiedliche Benutzer beschreiben

Berechtigungsprobleme treten oft schrittweise auf, wenn SMB- und NFS-Clients beide Schreibzugriff auf dasselbe Verzeichnis haben. Über SMB hochgeladene Dateien können einem NAS-Benutzer gehören, während über NFS erstellte Dateien eine numerische UID von einem anderen System tragen.

Die beiden Protokolle können auch unterschiedliche ACL- und Identitätszuordnungsregeln anwenden. Dadurch kann ein Ordner Dateien enthalten, die für einen Benutzer identisch aussehen, aber unterschiedliche Eigentümer, Gruppen, Masken oder vererbte Einträge haben.

Wählen Sie wenn möglich ein primäres Schreibprotokoll. Wenn SMB und NFS ein Dataset teilen müssen, stimmen Sie numerische IDs, gemeinsame Gruppen, Standard-ACLs, Umask-Werte und Erstellungsverhalten ab, bevor Sie Produktionsdaten darin ablegen.

Docker-Container fügen eine weitere Benutzeridentität hinzu

Eine Datei kann über SMB lesbar sein, aber für Plex, Jellyfin, Nextcloud, einen Downloader oder einen Backup-Container nicht verfügbar sein. Docker kann den korrekten Pfad mounten, während der Prozess im Container dennoch keine Berechtigung zum Lesen oder Schreiben hat.

Ein Containerprozess läuft unter einer eigenen UID und GID. Wenn diese Identität nicht mit dem Eigentümer oder einer erlaubten Gruppe auf dem gemounteten NAS-Pfad übereinstimmt, erhält die Anwendung Zugriff verweigert. Ein Volume-Mount macht das Verzeichnis sichtbar; er umgeht nicht die Dateisystemberechtigungen.

Eine gängige Lösung ist, die UID und GID des Containers mit der Identität abzugleichen, die das gemountete Volume verwenden darf. Überprüfen Sie die tatsächliche Prozessidentität, anstatt sich nur auf ein PUID- oder PGID-Feld in einer Compose-Datei zu verlassen:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Beschreibbar"

Ein Container kann Dateien erstellen, die ein anderer nicht lesen kann

Dies passiert häufig in Media-Automatisierungs-Stacks. Ein Download-Container schreibt erfolgreich eine fertige Datei, aber der Mediaserver kann sie nicht scannen oder ein Organizer kann sie nicht umbenennen.

Die Anwendungen können unterschiedliche UID/GID-Werte oder unterschiedliche Umasks verwenden. Wenn der Downloader Dateien als erstellt 600, nur der Eigentümer kann sie lesen und schreiben. Ein Modus wie 640 erlaubt Gruppenlesen, aber nur wenn beide Anwendungen die korrekte Gruppe teilen.

Für gemeinsam genutzte Anwendungsverzeichnisse verwenden Sie eine geplante Eigentümergruppe, fügen die notwendigen Anwendungsidentitäten dieser Gruppe hinzu und wählen eine Umask, die der Gruppe den erforderlichen Zugriff gewährt. Nur alte Dateien zu reparieren hilft nicht, wenn der Downloader weiterhin neue Dateien mit restriktiven Modi erstellt.

Umask- und Server-Erstellungsregeln steuern neue Berechtigungen

Wenn alte Dateien funktionieren, aber jede neue Datei unzugänglich ist, ist der Erstellungsprozess die wahrscheinliche Ursache. Jedes Programm beginnt mit einem angeforderten Dateimodus, und seine Umask entfernt ausgewählte Berechtigungen, bevor die Datei erstellt wird.

Samba kann auch Einstellungen wie Erstellungsmaske, Verzeichnis-Maske, Benutzer erzwingen, oder Gruppen erzwingen. NAS-Oberflächen können diese hinter Berechtigungsvorlagen, Freigabeordner-Voreinstellungen oder Vererbungsoptionen verbergen.

Erstellen Sie je einen Testdatei über jeden Pfad: Windows SMB, macOS SMB, NAS-Dateimanager, NFS und jeden relevanten Container. Vergleichen Sie den resultierenden Eigentümer, die Gruppe, den Modus und die ACL. So erkennen Sie schnell, welcher Erstellungsweg die fehlerhaften Berechtigungen erzeugt.

Verschiedene Übertragungstools bewahren unterschiedliche Metadaten

Finder, Windows Explorer, eine NAS-Weboberfläche, cp, und rsync garantieren keine identischen Ergebnisse. Einige bewahren Zeitstempel, andere können POSIX-Modi erhalten, und wieder andere erstellen einfach neue Dateien nach den Regeln des Ziels.

Bevor Sie eine Migrationsmethode wählen, entscheiden Sie, welche Eigenschaften erhalten bleiben müssen:

• Dateiinhalte und Verzeichnisstruktur
• Änderungszeiten
• POSIX-Berechtigungen
• Eigentümer und Gruppe
• ACL-Einträge
• Erweiterte Attribute
• Symbolische Links

Für gewöhnliche Familien-Dokumente oder Mediendateien kann die Vererbung am Ziel sinnvoller sein als das Bewahren von Quell-Computer-Konten, die auf dem NAS nicht existieren. Für Anwendungsdaten, Linux-Home-Verzeichnisse oder Servermigrationen kann das Bewahren von Eigentums- und ACL-Metadaten jedoch unerlässlich sein.

Rsync bewahrt nicht mit einem einfachen Befehl jedes Attribut

Rsync ist nützlich für kontrollierte NAS-Migrationen, aber das Ergebnis hängt von seinen Optionen, den Rechten des ausführenden Benutzers und den Fähigkeiten der Quell- und Ziel-Dateisysteme ab.

Der Archivmodus bewahrt gängige Metadaten wie Modi, Zeitstempel, Gruppen und Eigentum, sofern erlaubt. Zusätzliche Optionen sind erforderlich, wenn die Migration Berechtigungen, ACLs und erweiterte Attribute mit rsync bewahren muss. Ein typischer Linux-zu-Linux-Test könnte verwenden:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

Das -A Option erhält ACLs und -X erhält erweiterte Attribute, wenn beide Seiten sie unterstützen. --numeric-ids sollte bewusst verwendet werden, da das Beibehalten eines numerischen Eigentümers, der kein gültiges Konto auf dem NAS hat, genau die Diskrepanz reproduzieren kann, die Sie zu vermeiden versuchen.

Ein SMB-gemountetes Rsync-Ziel verhält sich möglicherweise nicht wie das NAS-Dateisystem

Das Ausführen von rsync von einem Computer in ein lokal gemountetes SMB-Share ist nicht immer gleichbedeutend mit dem direkten Ausführen von rsync über SSH gegen das NAS-Dateisystem. Die SMB-Schicht kann Besitzer zuordnen, ACLs transformieren oder Versuche, Attribute zu setzen, ablehnen.

Der Benutzer, der die SMB-Kopie durchführt, hat möglicherweise keine Berechtigung, beliebiges Eigentum zuzuweisen, selbst wenn rsync dies anfordert. Das Ziel-Dateisystem unterstützt möglicherweise auch ein anderes ACL-Modell als die Quelle.

Testen Sie zuerst ein kleines repräsentatives Verzeichnis. Untersuchen Sie die Dateien direkt auf dem NAS nach der Übertragung, nicht nur über das gemountete Share des Clients. Bestätigen Sie Eigentum, Modi, ACLs, erweiterte Attribute und Anwendungszugriff, bevor Sie das gesamte Dataset migrieren.

NAS-Berechtigungsvoreinstellungen können einfache Modusbits überschreiben

Einige NAS-Systeme verwalten den Zugriff über Dataset-ACL-Vorlagen und erweiterte Metadaten anstelle nur der traditionellen Besitzer/Gruppen/Andere-Modi. Dies kann eine manuelle chmod scheint erfolgreich zu sein, während SMB oder eine Anwendung weiterhin den Zugriff verweigert.

Ein Dataset kann auch so konfiguriert sein, dass vererbte Regeln erneut angewendet werden, wenn neue Dateien erstellt oder Berechtigungen über die Verwaltungsoberfläche bearbeitet werden. Die Mischung aus GUI-verwalten ACLs und wiederholten Änderungen über die Befehlszeile kann einen inkonsistenten Zustand erzeugen.

Wählen Sie ein Berechtigungsmodell und verwalten Sie es konsequent. Wenn das Dataset für eine SMB/NFSv4-ACL konfiguriert ist, verwenden Sie den NAS-ACL-Editor oder ACL-kompatible Tools, anstatt die Struktur wiederholt mit POSIX-Modusbefehlen zu ersetzen.

Die Neuinstallation des NAS setzt nicht unbedingt die Datenberechtigungen zurück

Berechtigungen gehören normalerweise zu den Dateien und dem Dateisystem-Dataset, nicht nur zur NAS-Betriebssystemkonfiguration. Eine Neuinstallation des Bootsystems kann daher dieselben unzugänglichen Eigentums- und ACL-Einträge auf einem importierten Speicherpool hinterlassen.

Ein TrueNAS-Community-Fall zeigt, wie Dateisystemberechtigungen dem Speicherpool zugeordnet bleiben und mit den richtigen Benutzern und Zugriffskonfigurationen übereinstimmen müssen. Er zeigt auch das Risiko großer rekursiver Änderungen, ohne das beabsichtigte Identitätsmodell vorher zu verstehen.

Bevor Sie Dienste neu installieren oder neu aufbauen, prüfen Sie Besitzer, Gruppe, ACL und Anwendungsbenutzer des Datensatzes. Die Daten sind möglicherweise intakt und benötigen nur eine korrekte Wiederherstellung der Zugriffsregeln.

Warum rekursives chmod 777 keine echte Lösung ist

Wenn Tausende von Dateien unzugänglich werden, chmod -R 777 Sieht aus wie ein schneller Weg, den Zugriff wiederherzustellen. Es gewährt Lese-, Schreib- und Ausführungsrechte für Besitzer, Gruppe und jede andere lokale Identität.

Das kann private Daten offenlegen, es erlauben, dass nicht verwandte Dienste Dateien ändern, Ausführungsrechte auf gewöhnliche Dokumente setzen und eine sorgfältig vererbte ACL-Struktur beschädigen. Außerdem korrigiert es nicht den falschen Besitzer, eine nicht übereinstimmende Container-UID, fehlende Gruppenmitgliedschaft oder eine fehlerhafte SMB-Identitätszuordnung.

Verwenden Sie stattdessen das beabsichtigte Zugriffsmodell: Stellen Sie den korrekten Besitzer und die gemeinsame Gruppe ein, bauen Sie die passende ACL neu auf, setzen Sie Verzeichnis- und Dateimodi separat und korrigieren Sie zukünftige Vererbung und Umask-Einstellungen. Testen Sie an einem kleinen Ordner, bevor Sie rekursive Änderungen vornehmen.

Berechtigungen von der Identität ausgehend reparieren

Beginnen Sie mit dem verweigerten Benutzer oder Prozess, nicht mit dem Befehl, von dem Sie hoffen, dass er das Problem löst. Ein menschlicher SMB-Benutzer, ein Mediaserver und ein Backup-Container benötigen möglicherweise unterschiedliche Zugriffsebenen.

Für jeden betroffenen Workflow aufzeichnen:

• Der Benutzer oder Prozess, der Zugriff versucht
• Die numerische UID und GID, falls zutreffend
• Das verwendete Protokoll oder der Mount
• Der aktuelle Besitzer und die Gruppe der Datei
• Die vollständige ACL und vererbte Einträge
• Der tatsächlich benötigte Zugriff: lesen, erstellen, ändern oder löschen

Ändern Sie dann nur die fehlerhafte Ebene. Fügen Sie den Benutzer einer erlaubten Gruppe hinzu, korrigieren Sie den Besitz, reparieren Sie die ACL, gleichen Sie eine Container-UID an oder aktualisieren Sie die Erstellungsregel. Vermeiden Sie es, breiteren Zugriff zu gewähren als der Workflow benötigt.

Folgen Sie einer schichtweisen Fehlerbehebungsreihenfolge

Das gleichzeitige Ändern der Freigabe-ACL, Container-Identität, NFS-Export und Dateimodi zerstört nützliche Hinweise. Testen Sie jeweils eine Berechtigungsebene.

Beginnen Sie mit einer betroffenen Datei und einem betroffenen Benutzer oder einer betroffenen Anwendung. Sobald dieser kleine Fall funktioniert, erstellen Sie eine neue Datei über den normalen Workflow und bestätigen, dass die Reparatur das Problem dauerhaft verhindert.

Verhindern Sie Berechtigungsprobleme vor einer großen NAS-Migration

Die Reparatur von Berechtigungen über Hunderttausende von Dateien ist viel schwieriger als das Testen des Zugriffsmodells vor der Migration. Erstellen Sie einen kleinen Zielordner mit derselben ACL- und Anwendungskonfiguration, die für den endgültigen Datensatz geplant ist.

Kopieren Sie mehrere Dateitypen, verschachtelte Verzeichnisse, schreibgeschützte Dateien, ausführbare Skripte und Dateien mit erweiterten Attributen. Testen Sie sie von jedem erforderlichen Pfad: SMB, NFS, der NAS-Schnittstelle, Backup-Software und relevanten Containern.

Beginnen Sie die vollständige Migration erst, wenn neue Dateien konsequent den korrekten Eigentümer, die Gruppe, ACL und den Anwendungszugriff erhalten. Bewahren Sie vor der Anwendung rekursiver Eigentums- oder Berechtigungsänderungen an bestehenden Daten einen Snapshot oder ein Backup auf.

Fazit

Dateiberechtigungen gehen nach dem Verschieben von Daten auf ein NAS verloren, weil die Übertragung normalerweise neue Dateisystemobjekte erstellt. Diese Objekte werden von dem für die Übertragung verwendeten NAS-Konto, der Ziel-ACL, UID/GID-Werten, Umask, Protokollzuordnung und der Identität der Anwendung oder des Containers gesteuert.

Beginnen Sie nicht mit chmod 777Beantworten Sie zuerst drei Fragen: Wer hat die Datei erstellt, wem gehört sie jetzt und welcher Identität wird der Zugriff verweigert? Untersuchen Sie dann den Share-Zugriff, Dateisystem-ACLs, Vererbung, Container-IDs und zukünftige Erstellungsregeln.

Eine erfolgreiche Reparatur sollte zwei Dinge bewirken: den angemessenen Zugriff auf die vorhandenen Dateien wiederherstellen und sicherstellen, dass die nächste Datei, die auf das NAS kopiert, heruntergeladen oder erstellt wird, automatisch die korrekten Berechtigungen erhält.

FAQ

Warum erben kopierte Dateien die Berechtigungen des NAS-Ordners?

Eine Übertragung zu einem NAS erstellt normalerweise neue Dateien auf einem anderen Dateisystem. Neue Objekte erhalten üblicherweise Berechtigungen aus der ACL des Zielordners, Vererbungsflags und serverseitigen Erstellungsregeln.

Warum kann ich NAS-Dateien über SMB öffnen, aber mein Docker-Container nicht?

Die SMB-Sitzung und der Container verwenden unterschiedliche Identitäten. Überprüfen Sie die tatsächliche UID und GID des Containers, die numerische Eigentümerschaft des gemounteten Pfads, die Gruppenmitgliedschaft und ob das Mount schreibgeschützt ist.

Sollte ich chmod 777 verwenden, um ein NAS-Share zu reparieren?

Nein. Es gewährt jeder lokalen Identität umfassenden Zugriff, kann die ACL-Vererbung beschädigen und löst keine falsche Eigentümerschaft oder UID/GID-Zuordnung. Definieren Sie die vorgesehenen Benutzer und Gruppen und reparieren Sie dann Eigentum und ACLs entsprechend.

Kann rsync NAS-Dateiberechtigungen erhalten?

Es kann POSIX-Berechtigungen und andere Metadaten beibehalten, wenn die ausgewählten Optionen, Ausführungsrechte und beide Dateisysteme dies unterstützen. ACLs und erweiterte Attribute erfordern zusätzliche Optionen wie -A und -X.

Warum gehen neue Dateien immer wieder kaputt, nachdem ich die alten Dateien repariert habe?

Der Erstellungsweg ist immer noch falsch. Überprüfen Sie die vererbten ACL des Zielordners, die SMB- oder NFS-Identität, die Umask der Anwendung, Samba-Erstellungsregeln und die Container-UID/GID.