Fehler RBK0266E mit dem Backup auf ein Automount Verzeichnis

Lars Hennig · November 17, 2025 at 10:33 AM

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?

Bot · Vor 5 Minuten

Fehler RBK0266E mit dem Backup auf ein Automount Verzeichnis? Schau mal ob du hier fündig wirst!

Franjo G · November 17, 2025 at 1:01 PM

Quote from Lars Hennig

no_root_sqush ist gesetzt. Was könnte noch fehlen?

Ein "a" SCNR

Lars Hennig · November 17, 2025 at 1:04 PM

Quote from Franjo G

Quote from Lars Hennig

no_root_sqush ist gesetzt. Was könnte noch fehlen?

Ein "a" SCNR

Nein, leider nicht: https://github.com/framps/raspiBackup/issues/938

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

Franjo G · November 17, 2025 at 1:10 PM

Quote from Lars Hennig

Nein, leider nicht:

Es muss heißen no_root_squash nicht no_root_sqush

Lars Hennig · November 17, 2025 at 2:00 PM

Quote from Franjo G

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

RTFM · November 17, 2025 at 7:30 PM

Quote from Lars Hennig

, die Ursache ist aber wohl ein Bug bzgl. Trixie

... 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.

Servus !

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

Lars Hennig · November 17, 2025 at 7:49 PM

Quote from RTFM

... 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?

**hyle** · November 17, 2025 at 8:35 PM

Quote from Lars Hennig

wenn vor dem Upgrade auf Trixie

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.

RTFM · November 17, 2025 at 8:43 PM

Ja, die gesetzen ACLs.

Code

I also notice another difference:

Your side:

20251117-141135 DBG 3955:          --> supportsFileAttributes /nas/Backup
20251117-141135 DBG 3972:              --- ----r-xrwx # nobody # nogroup
20251117-141135 DBG 3988:              --- Remote: ----r-xrwx+ # nobody # nogroup
20251117-141138 DBG 3988:              --- Remote: ----r-xrwx+ # nobody # nogroup
20251117-141141 DBG 3988:              --- Remote: ----r-xrwx+ # nobody # nogroup
20251117-141144 DBG 3988:              --- Remote: ----r-xrwx+ # nobody # nogroup
20251117-141147 DBG 4002:          <-- supportsFileAttributes 1

My side:

0251117-151654 DBG 3873:          --> supportsFileAttributes /backup/backup
20251117-151654 DBG 3890:              --- ----r-xrwx # nobody # nogroup
20251117-151654 DBG 3906:              --- Remote: ----r-xrwx # nobody # nogroup
20251117-151654 DBG 3920:          <-- supportsFileAttributes 0

Display More

Und updates von Major-Version auf höhere Major Version sollte man tunlichst vermeiden.

Servus !

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

**hyle** · November 17, 2025 at 8:50 PM

Moment, ich muss hier erstmal aufräumen und auslagern!

...

So, hier geht es weiter.

Lars Hennig · November 17, 2025 at 9:05 PM

Quote from hyle

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?

**hyle** · November 17, 2025 at 9:14 PM

Quote from Lars Hennig

Zurück zum Thema

Naja, das ist ein Teil des Themas und wenn Du bisher keine Probleme mit Release-Upgrades hattest, dann muss das dieses mal nicht auch der Fall sein.

Stammt das raspiBackup noch vom Bookworm oder hast Du das auf Trixie neu installiert oder ggf. upgedatet?

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

framp · November 17, 2025 at 9:29 PM

Mit ist ein Unterschied aufgefallen den ich nicht erwartet hätte:

Die Sicht auf das gemountete Backupverzeichnis von der Raspberry

Code

pi@raspberrypi-trixie64-lite:~ $ ls -la /backup/
total 8
dr-xr-xr-x  1 root root 1146 Nov 17 21:12 .
drwxr-xr-x 19 root root 4096 Nov 17 21:07 ..

und die Sicht auf das exportierte Verzeichnis auf der Synology

Code

adm@syno:/volume1/raspiBackup$ ls -la
total 4
dr-xr-xr-x+ 1 root root 1146 Nov 17 21:12 .
drwxr-xr-x  1 root root 1174 Nov 16 20:24 ..

**hyle** · November 17, 2025 at 9:40 PM

Quote from framp

Die Sicht auf das gemountete Backupverzeichnis von der Raspberry

Ist IMHO ja aber für raspiBackup relevant und nicht was ~~die~~ auf der Synology für ACLs auf das gemountete Verzeichnis, ~~welches vom RPi kommt~~ gelegt wird. Oder bin ich da auf dem falschen Dampfer?

//Edit

Ne, ich meinte das anders herum, also des gemounteten Verzeichnisses von der Synology.

framp · November 17, 2025 at 10:00 PM

Das merkwürdige ist dass alle Systembackups wieder ohne ACLs auf den NAS stehen. Das ist auch wichtig, denn ansonsten würden beim Restore wieder alle Dateien mit ACLs restored werden, was falsch ist.

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

**hyle** · November 17, 2025 at 10:12 PM

Quote from framp

Das merkwürdige ist dass alle Systembackups wieder ohne ACLs auf den NAS stehen.

Du meinst aus Sicht des RPi oder? Oder meinst Du aus Sicht des NAS?

framp · November 17, 2025 at 10:21 PM

Sowohl aus Sicht der Raspberry als auch der Sicht der NAS ist finden sich bei mir beide Male keine ACLs. Nur im exportierten Backupverzeichnis werden ACLs angezeigt.

Summary: Das exportierte Backupverzeichnis hat auf der NAS ACLs. Alle Unterverzeichnisse die die Backups der Systeme enthalten haben keine ACLs bei mir auf meiner Syno. Aus Sicht der Raspberries haben aber alle Verzeichnisse keine ACLs.

Lars Hennig Kannst Du mal checken wie die Backupverzeichnisse Deine Bookwormsysteme auf Deine QNAP aussehen für Deine Systeme sowie das exportierte Backupverzeichnis?

Lars Hennig · November 17, 2025 at 11:45 PM

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.

Code

root@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:

Code

root@raspi:/nas/Backup# ls -ld raspi4
drwxrwx--- 6 root root 4096 17. Nov 17:02 raspi4
root@raspi:/nas/Backup# getfacl raspi4
# file: raspi4
# owner: root
# group: root
user::rwx
group::rwx
other::---

Bot · Vor einem Moment

Schau mal ob du hier fündig wirst:

framp · November 18, 2025 at 12:00 AM

Bei mir auf meinem Trixie System wird nichts mit ACLs angezeigt. Die File/Directoryattribute sind allerdings anders als bei Dir. Das ist das was RTFM bemerkte.

Code

pi@raspberrypi-trixie64-lite:~ $ mount | grep backup
synolix:/volume1/raspiBackup on /backup type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.158,local_lock=none,addr=192.168.0.9)

Code

pi@raspberrypi-trixie64-lite:~ $ ls -ld /backup/
dr-xr-xr-x 1 root root 1146 Nov 17 21:12 /backup/
pi@raspberrypi-trixie64-lite:~ $ getfacl /backup/
getfacl: Removing leading '/' from absolute path names
# file: backup/
# owner: root
# group: root
user::r-x
group::r-x
other::r-x

Lars Hennig · November 18, 2025 at 8:59 AM

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.

Participate now!