5
Samba - Ordnerlöschen verhindern
Moin zusammen,
hier ein weiterer Post aus der Reihe "Samba und warum funktioniert das in Windows nicht!"
Infos:
Ich nutze Samba 4.7.4 auf einem Debian Stretch. Für die Shares nutze ich Posix ACLs und nicht die Windows ACLs. Ich möchte auch NICHT zu den Windows ACLs wechseln.
TL;DR:
Windows denkt als würde es Ordner von einem Samba Share löschen, und löscht alle Dateien rekursiv in einem Ordner, obwohl der Nutzer im Übergeordneten Ordner eigentlich keine Rechte hat, diesen Ordner zu löschen. Dies führt zu einem leeren Ordner. Eigentlich sollte Windows eine Fehlermeldung ausgeben, dass es nicht berechtigt ist, den Ordner zu löschen.
Folgende Problem:
Ich habe einen Share erstellt für alle meine Benutzer und Gruppen. Dieser liegt unter /srv/Share und ist im Besitz von Root, sprich keiner der Benutzer darf hier einen Ordner anlegen, haben aber die r-x Rechte um den Ordner zu betreten.
Jetzt erstelle ich hier einen Ordner für die Gruppe "Mitarbeiter" mit dem Namen "employees". Ich mache Root als Userowner und die Gruppe "Mitarbeiter" als Groupowner. Dann setze ich die Permissions auf 770 und alle Mitarbeiter können ihre Dateien darin teilen, schreiben oder löschen etc. (Dies ist so gewollt).
Letzteres, das Löschen, ist jetzt das Problem:
Wenn man sich mit Windows auf den Share verbindet so zeigt er einem den Ordner "employees" an. Wenn ich jetzt diesen Ordner von Windows aus versuche zu löschen, dann kommt erst die Abfrage, ob ich diesen Ordner unwiderruflich löschen will und dann ist der weg. Naja so halb:
Beim Löschen, löscht Windows alle Dateien in dem Ordner "Employees" und zeigt dann auch den Ordner "Employees" auch nicht mehr an. Öffnet man jetzt den Explorer neu, so existiert der Ordner wieder, aber alle Dateien darin sind gelöscht.
Betrachtet man die Linux Permissions, so hat ein Nutzer der Gruppe "Mitarbeiter" keine Permissions um im Ordner /srv/Share/ etwas zu schreiben, sprich er darf auch keine Ordner löschen. Nutze ich in Linux einen unberechtigten Nutzer so verhindert Linux auch erfolgreich das Löschen des Ordners "Employees", so wie es sein soll.
Jetzt ist die Frage, warum Samba Windows scheinbar nicht mitteilt, dass der User gar keine Rechte hat den Ordner zu löschen, sodass Windows das erklärte Verhalten aufweist.
Habe ich hier einen Konfigurationsfehler bzw gibt es eine Konfiguration dafür, um das gewünschte Verhalten zu erreichen?
Workaround:
Wenn ich in dem Ordner "Share" einen Ordner ".protect" anlegen und die Rechte root:root 777 zuweise, so kann ich den Übergeordneten Ordner "Employees" nicht mehr Löschen von Windows und ich erhalte auch eine Ordnungsgemäße Fehlermeldung. Ehrlich gesagt, finde ich dies aber ziemlich ugly, als man das einsetzen will :D.
Vielleicht hat hiermit ja bereits einer Erfahrung gemacht?
Über jede Hilfe bin ich sehr Dankbar.
hier ein weiterer Post aus der Reihe "Samba und warum funktioniert das in Windows nicht!"
Infos:
Ich nutze Samba 4.7.4 auf einem Debian Stretch. Für die Shares nutze ich Posix ACLs und nicht die Windows ACLs. Ich möchte auch NICHT zu den Windows ACLs wechseln.
TL;DR:
Windows denkt als würde es Ordner von einem Samba Share löschen, und löscht alle Dateien rekursiv in einem Ordner, obwohl der Nutzer im Übergeordneten Ordner eigentlich keine Rechte hat, diesen Ordner zu löschen. Dies führt zu einem leeren Ordner. Eigentlich sollte Windows eine Fehlermeldung ausgeben, dass es nicht berechtigt ist, den Ordner zu löschen.
Folgende Problem:
Ich habe einen Share erstellt für alle meine Benutzer und Gruppen. Dieser liegt unter /srv/Share und ist im Besitz von Root, sprich keiner der Benutzer darf hier einen Ordner anlegen, haben aber die r-x Rechte um den Ordner zu betreten.
Jetzt erstelle ich hier einen Ordner für die Gruppe "Mitarbeiter" mit dem Namen "employees". Ich mache Root als Userowner und die Gruppe "Mitarbeiter" als Groupowner. Dann setze ich die Permissions auf 770 und alle Mitarbeiter können ihre Dateien darin teilen, schreiben oder löschen etc. (Dies ist so gewollt).
Letzteres, das Löschen, ist jetzt das Problem:
Wenn man sich mit Windows auf den Share verbindet so zeigt er einem den Ordner "employees" an. Wenn ich jetzt diesen Ordner von Windows aus versuche zu löschen, dann kommt erst die Abfrage, ob ich diesen Ordner unwiderruflich löschen will und dann ist der weg. Naja so halb:
Beim Löschen, löscht Windows alle Dateien in dem Ordner "Employees" und zeigt dann auch den Ordner "Employees" auch nicht mehr an. Öffnet man jetzt den Explorer neu, so existiert der Ordner wieder, aber alle Dateien darin sind gelöscht.
Betrachtet man die Linux Permissions, so hat ein Nutzer der Gruppe "Mitarbeiter" keine Permissions um im Ordner /srv/Share/ etwas zu schreiben, sprich er darf auch keine Ordner löschen. Nutze ich in Linux einen unberechtigten Nutzer so verhindert Linux auch erfolgreich das Löschen des Ordners "Employees", so wie es sein soll.
Jetzt ist die Frage, warum Samba Windows scheinbar nicht mitteilt, dass der User gar keine Rechte hat den Ordner zu löschen, sodass Windows das erklärte Verhalten aufweist.
Habe ich hier einen Konfigurationsfehler bzw gibt es eine Konfiguration dafür, um das gewünschte Verhalten zu erreichen?
Workaround:
Wenn ich in dem Ordner "Share" einen Ordner ".protect" anlegen und die Rechte root:root 777 zuweise, so kann ich den Übergeordneten Ordner "Employees" nicht mehr Löschen von Windows und ich erhalte auch eine Ordnungsgemäße Fehlermeldung. Ehrlich gesagt, finde ich dies aber ziemlich ugly, als man das einsetzen will :D.
Vielleicht hat hiermit ja bereits einer Erfahrung gemacht?
Über jede Hilfe bin ich sehr Dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 367435
Url: https://administrator.de/contentid/367435
Ausgedruckt am: 17.12.2024 um 08:12 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
Eine Punkt Datei ist versteckt, die 777 Permissions ist totaler Bloedsinn.
777 bedeutet der Besitzer, die Gruppe und alle anderen duerfen alles.
Die Frage stellt sich hier wie die Berechtigung des uebergeordneten Verzeichnis aussehen ?
Kannst Du auch gar nicht da Linux keine Ahnung von Windows ACL's hat !
Windows denkt nicht...
Mich wuerde jetzt mal folgendes zu Deinem Problem interessieren:
Handelt es sich um den Samba als einzigsten Fileserver und handelt es sich hier nur um Windowsclients ?
Das geht leider nicht aus Deinem Post hervor.
Beschreibe doch mal die genaue Umgebung dann koennen wir auch besser darauf eingehen.
Desweiteren waere interessant wie Du denn die Linux ACL's gesetzt hast ? Hast Du die den ueberhaupt installiert ?
Gruss
Workaround:
Wenn ich in dem Ordner "Share" einen Ordner ".protect" anlegen und die Rechte root:root 777 zuweise, so kann ich den Übergeordneten Ordner
"Employees" nicht mehr Löschen von Windows und ich erhalte auch eine Ordnungsgemäße Fehlermeldung. Ehrlich gesagt, finde ich dies aber ?
ziemlich ugly, als man das einsetzen will :D.
Wenn ich in dem Ordner "Share" einen Ordner ".protect" anlegen und die Rechte root:root 777 zuweise, so kann ich den Übergeordneten Ordner
"Employees" nicht mehr Löschen von Windows und ich erhalte auch eine Ordnungsgemäße Fehlermeldung. Ehrlich gesagt, finde ich dies aber ?
ziemlich ugly, als man das einsetzen will :D.
Eine Punkt Datei ist versteckt, die 777 Permissions ist totaler Bloedsinn.
777 bedeutet der Besitzer, die Gruppe und alle anderen duerfen alles.
Die Frage stellt sich hier wie die Berechtigung des uebergeordneten Verzeichnis aussehen ?
Ich nutze Samba 4.7.4 auf einem Debian Stretch. Für die Shares nutze ich Posix ACLs und nicht die Windows ACLs. Ich möchte auch NICHT zu den Windows ACLs wechseln.
Kannst Du auch gar nicht da Linux keine Ahnung von Windows ACL's hat !
Windows denkt als würde es Ordner von einem Samba Share löschen, und löscht alle Dateien rekursiv in einem Ordner, obwohl der Nutzer im
Übergeordneten Ordner eigentlich keine Rechte hat, diesen Ordner zu löschen. Dies führt zu einem leeren Ordner. Eigentlich sollte Windows eine Fehlermeldung ausgeben, dass es nicht berechtigt ist, den Ordner zu löschen.
Übergeordneten Ordner eigentlich keine Rechte hat, diesen Ordner zu löschen. Dies führt zu einem leeren Ordner. Eigentlich sollte Windows eine Fehlermeldung ausgeben, dass es nicht berechtigt ist, den Ordner zu löschen.
Windows denkt nicht...
Mich wuerde jetzt mal folgendes zu Deinem Problem interessieren:
Handelt es sich um den Samba als einzigsten Fileserver und handelt es sich hier nur um Windowsclients ?
Das geht leider nicht aus Deinem Post hervor.
Beschreibe doch mal die genaue Umgebung dann koennen wir auch besser darauf eingehen.
Desweiteren waere interessant wie Du denn die Linux ACL's gesetzt hast ? Hast Du die den ueberhaupt installiert ?
Gruss
Hallo
Eine Punkt Datei ist versteckt, die 777 Permissions ist totaler Bloedsinn.
777 bedeutet der Besitzer, die Gruppe und alle anderen duerfen alles.
Die Frage stellt sich hier wie die Berechtigung des uebergeordneten Verzeichnis aussehen ?
Moin, sorry da habe ich mich natürlich verschrieben, sorry. Ich meine natürlich 700, sodass die Gruppe "Mitarbeiter" hier keine Schreibrechte hat.
Kannst Du auch gar nicht da Linux keine Ahnung von Windows ACL's hat !
Das stimmt teilweise. Samba4 kann sowohl Windows ACLs, als auch Posix ACLs nutzen siehe:
https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
Die Windows ACLs werden in Linux als XAttr als NtSecurityDescriptor im ByteCode gespeichert. Hierdurch hat Samba die Möglichkeit Windows ACLs zu nutzen. Insbesondere bei Samba als Domänencontrollern ist das unerlässlich zwingend erforderlich. Linux kann mit dem XAttr natürlich nichts anfangen.
Windows denkt nicht...
Wofür der Kommentar?
Ich nutze einen Samba DC, der wie bereits erwähnt, lediglich Windows ACLs nutzen kann, ist eine Spezifikation, siehe Wiki. Folglich nutze ich einen separaten Samba Fileserver, der als Client dem DC gejoint ist. Hier liegt der Share mit POSIX ACLs.
Das ist aber eigentlich völlig irrelevant, da man auch einen einen reinen Samba Server nutzen kann, ohne DC Integration.
Die Permissions von /srv/Share habe ich im ersten Thread bereits angegeben. root:root 755, sprich die Mitglieder der Gruppe "Mitarbeiter" dürfen hier in /srv/Share keinen Ordner erstellen und löschen, so wie es auch sein soll. Im Windows Client, wenn ich mich mit dem Share verbinde, ermöglicht Windows es mir aber den Ordner in /srv/Share zu löschen, obwohl der Benutzer in Linux nicht dazu berechtigt wird. Dies hat zur Folge, dass Windows alle Dateien in diesem Ordner löscht, dann angezeigt, dass der Ordner gar nicht mehr existieren kann, weil er den ja gelöscht hat. Nach einem Reload ist der leere Ordner aber wieder da. Ist natürlich verständlich, weil Samba das Löschen des Ordners verhindert hat, aber warum meckert Windows nicht direkt beim Löschen dieses Ordners mit "Keine Berechtigung". Das ist doch die eigentliche Frage.
Zur Übersicht hier die Permissions:
/srv/Share (root:root 755)
/srv/Share/Employees (root:Mitarbeiter, 770)
Das Verhalten was ich von Windows erwarte ist doch, dass der eine Fehlermeldung gibt, wenn ich Employees lösche will, weil der Nutzer in /srv/Share keine Schreibrechte hat. Das ist aber nicht der Fall.
Ich hoffe es wurde etwas klarer
Workaround:
Wenn ich in dem Ordner "Share" einen Ordner ".protect" anlegen und die Rechte root:root 777 zuweise, so kann ich den Übergeordneten Ordner
"Employees" nicht mehr Löschen von Windows und ich erhalte auch eine Ordnungsgemäße Fehlermeldung. Ehrlich gesagt, finde ich dies aber ?
ziemlich ugly, als man das einsetzen will :D.
Wenn ich in dem Ordner "Share" einen Ordner ".protect" anlegen und die Rechte root:root 777 zuweise, so kann ich den Übergeordneten Ordner
"Employees" nicht mehr Löschen von Windows und ich erhalte auch eine Ordnungsgemäße Fehlermeldung. Ehrlich gesagt, finde ich dies aber ?
ziemlich ugly, als man das einsetzen will :D.
Eine Punkt Datei ist versteckt, die 777 Permissions ist totaler Bloedsinn.
777 bedeutet der Besitzer, die Gruppe und alle anderen duerfen alles.
Die Frage stellt sich hier wie die Berechtigung des uebergeordneten Verzeichnis aussehen ?
Moin, sorry da habe ich mich natürlich verschrieben, sorry. Ich meine natürlich 700, sodass die Gruppe "Mitarbeiter" hier keine Schreibrechte hat.
Ich nutze Samba 4.7.4 auf einem Debian Stretch. Für die Shares nutze ich Posix ACLs und nicht die Windows ACLs. Ich möchte auch NICHT zu den Windows ACLs wechseln.
Kannst Du auch gar nicht da Linux keine Ahnung von Windows ACL's hat !
Das stimmt teilweise. Samba4 kann sowohl Windows ACLs, als auch Posix ACLs nutzen siehe:
https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
Die Windows ACLs werden in Linux als XAttr als NtSecurityDescriptor im ByteCode gespeichert. Hierdurch hat Samba die Möglichkeit Windows ACLs zu nutzen. Insbesondere bei Samba als Domänencontrollern ist das unerlässlich zwingend erforderlich. Linux kann mit dem XAttr natürlich nichts anfangen.
Windows denkt als würde es Ordner von einem Samba Share löschen, und löscht alle Dateien rekursiv in einem Ordner, obwohl der Nutzer im
Übergeordneten Ordner eigentlich keine Rechte hat, diesen Ordner zu löschen. Dies führt zu einem leeren Ordner. Eigentlich sollte Windows eine Fehlermeldung ausgeben, dass es nicht berechtigt ist, den Ordner zu löschen.
Übergeordneten Ordner eigentlich keine Rechte hat, diesen Ordner zu löschen. Dies führt zu einem leeren Ordner. Eigentlich sollte Windows eine Fehlermeldung ausgeben, dass es nicht berechtigt ist, den Ordner zu löschen.
Windows denkt nicht...
Mich wuerde jetzt mal folgendes zu Deinem Problem interessieren:
Handelt es sich um den Samba als einzigsten Fileserver und handelt es sich hier nur um Windowsclients ?
Das geht leider nicht aus Deinem Post hervor.
Beschreibe doch mal die genaue Umgebung dann koennen wir auch besser darauf eingehen.
Handelt es sich um den Samba als einzigsten Fileserver und handelt es sich hier nur um Windowsclients ?
Das geht leider nicht aus Deinem Post hervor.
Beschreibe doch mal die genaue Umgebung dann koennen wir auch besser darauf eingehen.
Ich nutze einen Samba DC, der wie bereits erwähnt, lediglich Windows ACLs nutzen kann, ist eine Spezifikation, siehe Wiki. Folglich nutze ich einen separaten Samba Fileserver, der als Client dem DC gejoint ist. Hier liegt der Share mit POSIX ACLs.
Das ist aber eigentlich völlig irrelevant, da man auch einen einen reinen Samba Server nutzen kann, ohne DC Integration.
Die Permissions von /srv/Share habe ich im ersten Thread bereits angegeben. root:root 755, sprich die Mitglieder der Gruppe "Mitarbeiter" dürfen hier in /srv/Share keinen Ordner erstellen und löschen, so wie es auch sein soll. Im Windows Client, wenn ich mich mit dem Share verbinde, ermöglicht Windows es mir aber den Ordner in /srv/Share zu löschen, obwohl der Benutzer in Linux nicht dazu berechtigt wird. Dies hat zur Folge, dass Windows alle Dateien in diesem Ordner löscht, dann angezeigt, dass der Ordner gar nicht mehr existieren kann, weil er den ja gelöscht hat. Nach einem Reload ist der leere Ordner aber wieder da. Ist natürlich verständlich, weil Samba das Löschen des Ordners verhindert hat, aber warum meckert Windows nicht direkt beim Löschen dieses Ordners mit "Keine Berechtigung". Das ist doch die eigentliche Frage.
Desweiteren waere interessant wie Du denn die Linux ACL's gesetzt hast ? Hast Du die den ueberhaupt installiert ?
Ja, ganz sicher und funktioniert auch. Für dieses Beispiel sind aber keine ACLs erforderlich. Hier reichen einfache Owner/Group/Other permissions, um den Fehler zu reproduzieren. (Um Verwirrung vorzubeugen: Ich spreche hier von Posix ACLs um explizit hervorzuheben, dass ich keine Windows ACLs nutze. Seht es als Synonym zu den normalen Linux Permissions an mit der Option Posix ACLs zu nutzen).Zur Übersicht hier die Permissions:
/srv/Share (root:root 755)
/srv/Share/Employees (root:Mitarbeiter, 770)
Das Verhalten was ich von Windows erwarte ist doch, dass der eine Fehlermeldung gibt, wenn ich Employees lösche will, weil der Nutzer in /srv/Share keine Schreibrechte hat. Das ist aber nicht der Fall.
Ich hoffe es wurde etwas klarer
Moin,
hast du mal geprüft, welche Rechte Samba an die Windows-Clients "meldet"?
Deine Windosen wissen nichts von den Berechtigungen im VFS. Heißt also, dass irgendwo in der "Übersetzung" des Samba was schief laufen muss.
Gruß
hast du mal geprüft, welche Rechte Samba an die Windows-Clients "meldet"?
Deine Windosen wissen nichts von den Berechtigungen im VFS. Heißt also, dass irgendwo in der "Übersetzung" des Samba was schief laufen muss.
Gruß
Danke für die Antwort
Eine sehr gute Idee, werde ich direkt machen und dann hier Editieren.
Ja die Vermutung habe ich auch, die Frage ist nur wo? Ist das ein Bug in Samba oder doch eher nur "By Design". Sonst ich einfach mal ein Bugreport anlegen in der Samba Mailinglist.
Eine sehr gute Idee, werde ich direkt machen und dann hier Editieren.
Deine Windosen wissen nichts von den Berechtigungen im VFS. Heißt also, dass irgendwo in der "Übersetzung" des Samba was schief laufen muss.
Ja die Vermutung habe ich auch, die Frage ist nur wo? Ist das ein Bug in Samba oder doch eher nur "By Design". Sonst ich einfach mal ein Bugreport anlegen in der Samba Mailinglist
.
So, ich habe mir jetzt die Rechte, die in Windows gemappt werden angeschaut:
Folgende Ordnerstruktur habe ich dafür genutzt:
/srv/Share/ (root:root, 755)
/srv/Share/Employees (root:Mitarbeiter, 750).
/srv/Share/Employees/Department (root:Mitarbeiter, 770).
Sprich die Gruppe Mitarbeiter darf in dem Ordner Department schreiben, aber nicht direkt im Ordner Employees.
Windows macht daraus folgendes:
Dies sind die Rechte des Ordners "Department". Diese sind stehen für diese Gruppe auf Vollzugriff. Man beachte das"Nur auf diesen Ordner", sprich der Nutzer hat laut Windows Vollzugriff auf dem Ordner. Laut Linux Dateisystemrechten gelten aber ja die Permissions des übergeordneten Ordners "Employees" auf diesen Ordner.
Für den Ordner Employees macht der nur "Lesen und Ausführen".
Das macht ja auch Sinn, weil ich dem Ordner selber für die Gruppe Mitarbeiter "5" -> Read, Execute Permissions gegeben habe. Demzufolge ist dieser auch nicht Löschbar.
Scheinbar mappt Samba die Ordner Permissions so, als wenn es eine Datei wäre. Stattdessen sollte der die Rechte von "Diesen Ordner" aus dem Unterordner nehmen, sodass es mit dem Linux Filesystem kompatibel ist.
Oder gibt es einen Workaround außer den besagten
Folgende Ordnerstruktur habe ich dafür genutzt:
/srv/Share/ (root:root, 755)
/srv/Share/Employees (root:Mitarbeiter, 750).
/srv/Share/Employees/Department (root:Mitarbeiter, 770).
Sprich die Gruppe Mitarbeiter darf in dem Ordner Department schreiben, aber nicht direkt im Ordner Employees.
Windows macht daraus folgendes:
Dies sind die Rechte des Ordners "Department". Diese sind stehen für diese Gruppe auf Vollzugriff. Man beachte das"Nur auf diesen Ordner", sprich der Nutzer hat laut Windows Vollzugriff auf dem Ordner. Laut Linux Dateisystemrechten gelten aber ja die Permissions des übergeordneten Ordners "Employees" auf diesen Ordner.
Für den Ordner Employees macht der nur "Lesen und Ausführen".
Das macht ja auch Sinn, weil ich dem Ordner selber für die Gruppe Mitarbeiter "5" -> Read, Execute Permissions gegeben habe. Demzufolge ist dieser auch nicht Löschbar.
Scheinbar mappt Samba die Ordner Permissions so, als wenn es eine Datei wäre. Stattdessen sollte der die Rechte von "Diesen Ordner" aus dem Unterordner nehmen, sodass es mit dem Linux Filesystem kompatibel ist.
Oder gibt es einen Workaround außer den besagten
