Datei nicht löschbar / umbenennbar

Liebe Forum-Leser,

wir haben auf einem Fileserver ein eigenartiges Problem:

Dort wurde kürzlich (vor einem Monat) auf UCS 4.1.2 aktualisiert.
Es ist ein DC Slave.
Samba:

# smbd -V
Version 4.3.7-Debian

Dort passiert folgendes:
Benutzer können manche Files nicht löschen oder umbenennen. Wenn man es als Administrator versucht, geht es ebenfalls nicht.
Beim Umbenennen kommt eine Fehlermeldung (siehe Anhang), beim Löschen verschwindet die Datei zwar in der Ansicht, aber sie wird nicht gelöscht. Ich kann die Datei auch nicht öffnen, um sie anzusehen.

Als root am Datenserver kann ich die Datei natürlich umbenennen.
Danach kann die Datei gelöscht, umbenannt und angesehen werden.
Wenn man sie dann jedoch wieder auf den ursprünlichen Dateinamen umbenennt, kann sie danach wieder nicht gelöscht, umbenannt oder geöffnet werden …

So sehen die Berechtigungen aus:

[code]getfacl 5361-02I\ Bg.\ Frontteil\ CL-1250.pdf

file: 5361-02I Bg. Frontteil CL-1250.pdf

owner: s.bauer

group: root

user::rwx
user:s.bauer:rwx
group::rwx
group:root:rwx
group:Domain\040Admins:rwx
group:Entwicklung:rwx
group:Geschaeftsleitung:r-x
mask::rwx
other::—
[/code]

Was kann zur Klärung dieses seltsamen Verhaltens beitragen?

LG,
Roland.

Die Sache wird noch ein bisschen mysteriöser: Die Benutzer berichten, dass sie heute die betroffenen Files normal löschen konnten.
Am Server wurde nichts verändert oder neu gestartet.

Das heißt, Sie haben auch gerade keine Möglichkeit, das am lebenden Objekt zu debuggen? Das macht die Analyse leider nahezu unmöglich.

Generell: unter Linux legen nicht die Dateirechte fest, ob eine Datei gelöscht werden darf, sondern die Rechte auf dem Verzeichnis. Konkreter: der User muss Schreib- und Executerechte auf das Verzeichnis haben.

Beispiel:

[code][0 mbunkus@chai-latte ~/tmp] getfacl delete-test

file: delete-test

owner: root

group: root

user::rwx
user:mbunkus:-wx
group::—
mask::-w-
other::—

[0 mbunkus@chai-latte ~/tmp] ls -l delete-test/file.txt
ls: cannot access ‘delete-test/file.txt’: Permission denied
[2 mbunkus@chai-latte ~/tmp] sudo ls -l delete-test/file.txt
-rw------- 1 root root 0 Aug 17 11:44 delete-test/file.txt
[0 mbunkus@chai-latte ~/tmp] rm delete-test/file.txt
rm: remove write-protected regular empty file ‘delete-test/file.txt’? y
[0 mbunkus@chai-latte ~/tmp] sudo ls -l delete-test/file.txt
ls: cannot access ‘delete-test/file.txt’: No such file or directory
[0 mbunkus@chai-latte ~/tmp] sudo ls -l delete-test/file.txt
ls: cannot access ‘delete-test/file.txt’: No such file or directory[/code]

Nun zum Debuggen. Wenn’s noch mal auftritt, dann speichern Sie sich bitte als Erstes die NT-ACLs der Datei sowie des Verzeichnisses, in der die Datei liegt. Das geht als root mit »samba-tool ntacl get /pfad/zur/datei.pdf« (analog fürs Verzeichnis).

Anschließend versuchen Sie bitte mal, den Problemkreis einzuschränken. Dazu schließen Sie zuerst den Windows-Client aus, indem Sie von Linux aus mit »smbclient« auf die Share gehen und versuchen, die Datei mit dem »smbclient« zu löschen. Loggen Sie sich unbedingt mit dem selben Useraccount ein, der auch am Windows-Client benutzt wird.

Sieht dann beispielsweise so aus:

[code][0 mbunkus@chai-latte ~/tmp] smbclient //kyushu/austausch -U mbunkus
Enter mbunkus’s password:
Domain=[LINET] OS=[Windows 6.1] Server=[Samba 4.3.7-Debian]
smb: > cd mbunkus/tmp
smb: \mbunkus\tmp> ls
. D 0 Wed Aug 17 11:49:41 2016
… D 0 Wed Aug 17 11:49:33 2016
file.txt N 0 Wed Aug 17 11:49:41 2016

            2878804520 blocks of size 1024. 1866024592 blocks available

smb: \mbunkus\tmp> rm file.txt
smb: \mbunkus\tmp> ls
. D 0 Wed Aug 17 11:49:46 2016
… D 0 Wed Aug 17 11:49:33 2016

            2878804520 blocks of size 1024. 1866024532 blocks available

smb: \mbunkus\tmp>[/code]

Wenn das nicht klappt, dann ist zumindest schon mal nicht der Windows-Client schuld.

Als nächstes schließen wir Samba selber aus. Dazu unter Linux mal zu dem Useraccount wechseln, der auch am Windows-Client angemeldet ist (wenn Sie gerade »root« sind, dann z.B. »su - username«). Anschließend versuchen Sie, als dieser User die Datei zu löschen.

Mastodon