Posts by Lars Hennig
-
-
Was mir nicht klar ist, ist wie ich den NFS-Client dazu bringen kann, die ACLs bzw. deren Existenz zu ignorieren. Früher gab es mal die Option noacl dafür, die ist aber deprecated. Ich verstehe nicht, warum in Trixie der NFS-Client bezüglich der ACLs sich so anders verhält als andere Systeme.Zumal ja nur in der Anzeige des Dateisystems die "+" Zeichen angezeigt werden, die eigentlichen ACLs in den NFS-Mounts aber nicht verwendet werden.
Zu den Berechtigungen der Mountpoint-Verzeichnisse: Das Autofs-Basisverzeichnis zu meiner Map auto-nas ist /nas und hat 755 als Berechtigungen. Das halte ich für unkritisch, weil dort direkt kein Inhalt liegt, sondern lediglich die Mountpunkte für die Shares vom Autofs angelegt werden.
Die Berechtigungen darunter - also die der Autofs-Mountpunkte - werden von der Maske der ACLs vom NFS-Server auf dem NAS vererbt. Auf Trixie leider auch der Hinweis auf die Existenz von ACLs, ohne dass diese wirklich verwendet werden können.
-
Auf dem QNAP NAS werden diese bei "ls -l" nicht angezeigt, auch wenn sie mit getfacl abgefragt und gelistet werden können. Die ACLs auf dem NAS zu löschen habe ich mich nicht getraut. Es haben aber alle Verzeichnisse in meinem Backup-Verzeichnis ACLs, auch in anderen Shares. In keinem NFS-Mount werden diese im ls-Output angezeigt. Das Verhalten ist unabhängig von Autofs, ein manueller NFS Mount verhält sich exakt identisch.
Die Backup-Verzeichnisse im NFS Share, das per Autofs auf dem Trixie Raspi gemountet wird, zeigt ACLs in allen Unterverzeichnissen. getfacl findet hier keine ACLs.
Coderoot@raspi4:/nas/Backup# ls -ld raspi4 drwxrwx---+ 6 root root 4096 Nov 17 17:02 raspi4 root@raspi4:/nas/Backup# getfacl raspi4 # file: raspi4 # owner: root # group: root user::rwx group::rwx other::---Ich verstehe aber nicht, warum sie auf dem Trixie System angezeigt werden, auf anderen Linux-Systemen (Raspi mit Bookworm, oopenSuSE Leap 15.6). Ich verstehe das grade nicht mehr. Konsistent ist das irgendwie nicht. Beispiel für raspi auf Bookworm:
-
Nur für mein Verständnis. Ist das ein Upgrade im wörtlichen Sinn von Bookworm auf Trixie oder ist das eine Neuinstallation von Trixie?
Solche Upgrades werden, auch von offizieller Seite, nicht empfohlen. Vielleicht liegt hier der Hund begraben.
Ja, es war ein full upgrade. Bisher habe ich mit solchen Upgrades keine Probleme gehabt.
Zurück zum Thema: Die ACLs stammen von QNAP und werden wohl vom Trixie-NFS-Client erkannt und ausgewertet. Ich bin nicht sicher, ob die Exports auch ohne ACLs funktionieren bzw. wie ich den Client dazu bringen kann, sie nicht zu nutzen. Ideen?
-
... oder fehlerhafte Hardware, der Admin hat immer alles richtig gemacht.
Dabei ist ein chmod 777 auf den Mountpoint suboptimal.
Und wenn ich framps issure #938 ansehe, dann hast Du auf den Mountpoint auch noch ACLs draufgeknallt, das hat sicher eine fehlerhafte Software gemacht.
Wohl eher nicht, wenn vor dem Upgrade auf Trixie alles funktioniert hat und auf einem parallelen System beim Schreiben auf das gleiche Autofs-Verzeichnis kein Fehler mit Bookworm passiert.
Den Mountpoint setzt Autofs so auf, da habe ich nichts dran verändert, und wenn Du den Issue bei framps gelesen hättest, hättest Du selbst gemerkt, dass ich keine ACLs verwende (oder in Deinem Sprech "draufgeknallt" habe).
Hast Du auch etwas Konstruktives beizutragen?
-
Es muss heißen no_root_squash nicht no_root_sqush

Ich habe das schon verstanden, die Ursache ist aber wohl ein Bug bzgl. Trixie
-
no_root_sqush ist gesetzt. Was könnte noch fehlen?
Ein "a" SCNR
Nein, leider nicht: https://github.com/framps/raspiBackup/issues/938
-
Ausgelagert aus: Problem mit rsync
Ich habe den Fehler RBK0266E mit dem Backup auf ein Automount Verzeichnis erst nach dem Update auf Raspbian 13. NFS ist korrekt konfiguriert und no_root_sqush ist gesetzt. Was könnte noch fehlen?