Lars Hennig Ich habe mal die Beta so modifiziert dass rsync keine ACLs mehr kopiert und der Check, der bislang verhindert, dass raspiBackup startet, disabled. Die Änderung ist aber in keiner Weise von mir getestet ob dadurch der Backup und Restore noch funktioniert. Du nutzt die modifizierte Beta also auf eigene Gefahr. Details zu der Modifikation findest Du im git Issue.
Die Änderung wird auch nicht mehr in die aktuelle Beta einfliessen. Es sind dazu diverse weitere Regressiontests notwendig.
Fehler RBK0266E mit dem Backup auf ein Automount Verzeichnis? Schau mal ob du hier fündig wirst!
Warum der TE das Problem hat haben wir leider nicht herausgekommen. Die für ihn erstellte modifizierte Beta Version ignoriert im Check das + Zeichen welches auf ACL hinweist und der Backup läuft durch. Der Restore muss noch getestet werden.
Da ich die Zusammenhänge nicht verstehe wird der Check auf + auch weiterhin drin bleiben. Ich erinnere mich noch gut wie das restorte Backup damals durch vererbte ACLs verhunzt und somit untauglich war.
Hallo alle hier Mitlesenden
framp Lars Hennig
RESTORE läuft durch und bootet NORMAL
Ich hatte exakt das gleiche Problem wie Lars:
- Trixie frisch installiert (Pi5 - 64bit - mit Desktop oder auch lite probiert)
- raspiBackup (rsync über nfs4) bricht beim Kontakt mit QNAP mit der Fehlermeldung RBK0266E ab ("Es fehlt die Berechtigung...")
- Workaround mittels Beta gemacht
- Backup lief problemlos durch
- Restore klappt auch!
Danke für die schnelle Hilfe!
Chris
Ok. Dann muss ich die Kuh wohl doch vom Eis holen und sie in die nächste Release einladen 
Ich dachte das wäre eine Ausnahme bei Lars Hennig . Dem ist offensichtlich nicht so.
So wie ich es gerade sehe ist das ein Problem was jetzt mit Trixie und QNAP Nutzung auftritt. Bei Bookworm gibt es das Problem nicht. Und der Fehler tritt auch auf mit der aktuellen raspiBackup Release 0.7.1.1 Lars Hennig & msol : Bitte korrigiert mich wenn ich falsch liege.
Leider kann ich nichts testen da ich keine QNAP haben sondern eine Synology. Ich bräuchte also die Hilfe von Euch um das Problem zu verstehen und letztendlich den Code der modifizierten Beta in die Beta einfliessen zu lassen. Im Wesentlichen sind das irgendwelche Befehlsausgaben von der Raspberry mit gemounteter QNAP. Welche das sind, muss ich erst rausfinden.
Der Code, der die Prüfung der Dateiattribute macht, ist schon lange drin in raspiBackup. In der modifizierten Beta wird das + Zeichen, welches auf ACLs hinweist, ignoriert. Deshalb läuft da auch raspiBackup problemlos durch. Hintergrund warum das geprüft wird ist, dass dadurch die ACLs in Unterverzeichnisse und Dateien vererbt werden und ebenso restored werden und dazu führen, dass das restorte System unbrauchbar ist. Ich suche mal nach dem Thread hier im Forum. Ich meine dass das Problem hier berichtet und diskutiert wurde.
Meine Vermutung ist, dass sich irgendwas im nfs Clientcode in Trixie geändert hat und deshalb plötzlich das + Zeichen auftaucht.
nfs4 soll/braucht man nicht verwenden, wenn die Kerberos Verschlüsselung nicht aktiviert, oder benötigt wird.
Der Filetyp "nfs4" ist nur für uralte Kernels < 2.6. Aktuell sollte im Mountbefehl "nfs" gemountet werden.
Die ACLs von NFS 4 sind Netzwerk ACLs und mit den Posix ACLs von EXT4 nicht ident
Probiere einmal Deine QNAP auf nfs3 runterzudrehen, oder den Client mit nfsvers=3 zu starten.
Servus !
Sehr guter Hinweis 
Lars Hennig | msol Könntet Ihr mal testen ob damit die nicht modifizierte Beta funktioniert? Die Synology unterstützt keine ACLs per nfs, egal ob V3 oder V4. Bei mir geht beides. Sieht so aus dass die QNAP das unterstützt und mit Trixie jetzt auch bei ls sichtbar macht. Ihr braucht keinen ganzen Backup zu erstellen. Einfach die unmodifizierte Beta anstossen und sehen ob RBK0266E kommt oder nicht. Siehe RE: Fehler RBK0266E mit dem Backup auf ein Automount Verzeichnis
Anyhow bin ich gerade dabei mich mit ACLs genauer zu befassen. Das damalige Problem entstand nur, weil Default ACLs im Backupverzeichnis gesetzt waren. Nur die vererben sich auf Neuzugänge im Verzeichnis. Normale ACLs machen kein Problem. D.h. ich muss den Test auf das + Zeichen ändern in Test ob Default ACLs gesetzt sind 
Das sollte dazu führen dass auch mit nfs4 die QNAP genutzt werden kann. Aber das Testergebnis mit nfs3 wäre für mich trotzdem interessant.
Oder noch einfacher: Downloaded dieses Script und ruft es auf. Es führt genau den Test aus den raspiBackup auch ausführt und löscht nicht das +.
Probiere einmal Deine QNAP auf nfs3 runterzudrehen, oder den Client mit nfsvers=3 zu starten.
RTFM framp
Das hatte ich bis vor einigen Wochen so in meiner QNAP und auch in der fstab drin und raspiBackup funktionierte NICHT unter Trixie wohl aber unter bookworm
Danach habe ich es erst mit der Änderung in der QNAP probiert, dann auch in der fstab - beides ergab kein positives Ergebnis
Oder noch einfacher: Downloaded dieses Script und ruft es auf. Es führt genau den Test aus den raspiBackup auch ausführt und löscht nicht das +.
root@Pi5-Trixie:~# ./supportsFileAttributes.sh /mnt/mounted_my_disk_2/
Fileattributes of local file:
Attributes: ----r-xrwx
Owner: nobody
Group: nogroup
Fileattributes of remote file:
Attributes: ----r-xrwx+
Owner: nobody
Group: nogroup
Error: Filesystem on /mnt/mounted_my_disk_2/ does NOT supports Linux fileattributesIch denke so langsam sehe ich Licht am Ende des Tunnels. Ich habe mich mal genauer mit ACLs und deault ACLs befasst und dann ein kleines Script geschrieben welches ein Directory auf ACLs untersucht. Ausserdem habe ich einen nfs Server aufgesetzt auf einer Raspberry mit Bookworm lite. Damit konnte ich mit nfs Version 4 genau das berichtete Verhalten nachvollziehen: Mit Bookworm wird kein + bei ls angezeigt während das bei Trixie der Fall ist. Ausserdem konnte ich damit verifizieren, was mit der Synologysupport schon damals bestätigt hat - die Synology unterstützt keine ACLs - weder bei v3 noch v4. Bei dem Raspberry nfs Server allerdings werden ACLs bei v3 unterstützt. Bei v4 aber nicht. Deshalb tritt bei mir bei meinen Tests mit der Synology der Fehler nicht auf.
Die Scriptausgaben bei Bookworm und Trixie auf die Raspberry nfs Partition sind für interessierte Leser hier zu finden.
Jetzt habe ich an msol und/oder Lars Hennig oder jeden, der eine QNAP sein Eigen nett, noch die Bitte mein Ergebnis noch einmal mit einer QNAP zu verfizieren.
Dazu bitte folgende Schritte auf Trixie ausführen und die Ausgaben zeigen:
1) Dieses Script auf Trixie runterladen (wget https://raw.githubusercontent.com/framps/raspiBackup/refs/heads/master/scripts/checkACLs.sh; chmod +x checkACLs.sh)
2) Folgenden Befehl ausführen: sudo umount /mnt; sudo mount -o nfsvers=4 <remoteNfsDirectory> /mnt; ./checkACLs.sh /mnt/ und dabei <remoteNfsDirectory> mit dem korrekten nfs Verzeichnis aufrufen. Also z.b. habe ich asterix://disks/silver/nfs genutzt für das exportierte nfs Verzeichnis
3) Denselben Befehl noch einmal ausführen. Dieses mal aber nfsvers=3 nutzen
Bei 2 erwarte ich ebenso dass bei Bookworm kein + entdeckt wird aber bei Trixie. Wenn das so ist dann stimmt meine Analyse und ich kann einen Fix für Trixie erstellen.
Interessant ist was bei 3 angezeigt wird. Wie geschrieben, werden bei der Raspberry ACLs entdeckt nachdem ich im nfs Verzeichnis ACLs erstellt hatte.
framp gleiches Problem hier Debian Trixie und QNAP NAS und anbei der Output:
nfs3:
./checkACLs.sh /mnt/nas2/backup-vm/raspibackup/
@@@ mount | grep -m 1 /mnt/nas2/backup-vm/raspibackup
<ip>:/backup-vm/raspibackup on /mnt/nas2/backup-vm/raspibackup type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=<ip>,mountvers=3,mountport=56875,mountproto=udp,local_lock=none,addr=<ip>,_netdev)
@@@ ls -lad /mnt/nas2/backup-vm/raspibackup
drwxrwxrwx+ 4 setupuser users 4 Nov 21 20:54 /mnt/nas2/backup-vm/raspibackup
+++ /mnt/nas2/backup-vm/raspibackup has ACLs according ls
+++ /mnt/nas2/backup-vm/raspibackup has ACLs
+++ /mnt/nas2/backup-vm/raspibackup has default ACLs
@@@ getfacl -p /mnt/nas2/backup-vm/raspibackup
# file: /mnt/nas2/backup-vm/raspibackup
# owner: setupuser
# group: users
user::rwx
user:setupuser:rwx
user:nobody:---
group::rwx
group:root:rwx
mask::rwx
other::rwx
default:user::---
default:user:setupuser:rwx
default:user:nobody:---
default:group::---
default:group:root:rwx
default:mask::rwx
default:other::rwx
nfs 4:
./checkACLs.sh /mnt/nas2/backup-vm/raspibackup/
@@@ mount | grep -m 1 /mnt/nas2/backup-vm/raspibackup
<ip>:/backup-vm/raspibackup on /mnt/nas2/backup-vm/raspibackup type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<client_ip>,local_lock=none,addr=<ip>,_netdev)
@@@ ls -lad /mnt/nas2/backup-vm/raspibackup
drwxrwxrwx+ 4 setupuser users 4 Nov 21 20:38 /mnt/nas2/backup-vm/raspibackup
+++ /mnt/nas2/backup-vm/raspibackup has ACLs according ls
--- /mnt/nas2/backup-vm/raspibackup has NO ACLs
--- /mnt/nas2/backup-vm/raspibackup has NO default ACLs
@@@ getfacl -p /mnt/nas2/backup-vm/raspibackup
# file: /mnt/nas2/backup-vm/raspibackup
# owner: setupuser
# group: users
user::rwx
group::rwx
other::rwx
Ich hoffe das hilft beim Debuggen
Ich hoffe das hilft beim Debuggen
Natürlich. Vielen Dank für die Ausgabe 
.
Es bestätigt meine Analyseergebnisse soweit.
Interessant ist, dass die QNAP offensichtlich default ACLs an dem Verzeichnis hat. Dieses ist genau das, was der bisherige Test eigentlich abfangen soll. Ich vermute deshalb, dass Du nfs v4 nutzt und nicht v3, denn dann sollte der RBK0266E von raspiBackup berechtigterweise gemeldet werden. Stimmt das?
PS: Sehe gerade - willkommen im Forum
Ich hoffe das hilft beim Debuggen
Natürlich. Vielen Dank für die Ausgabe
Es bestätigt meine Analyseergebnisse soweit.
Interessant ist, dass die QNAP offensichtlich default ACLs an dem Verzeichnis hat. Dieses ist genau das, was der bisherige Test eigentlich abfangen soll. Ich vermute deshalb, dass Du nfs v4 nutzt und nicht v3, denn dann sollte der RBK0266E von raspiBackup berechtigterweise gemeldet werden. Stimmt das?
PS: Sehe gerade - willkommen im Forum
Hallo Framp, danke für die nette Begrüssung 
Also die Meldung kommt bei beiden Mount Varianten, egal ob ich via V4 oder V3 mounte:
raspiBackup
--- RBK0009I: rocrailpi: raspiBackup.sh V0.7.1.1 - 2025-11-18 (5b75436) started at Fri 21 Nov 21:40:18 CET 2025
??? RBK0266E: Access rights missing to create fileattributes on /mnt/nas2/backup-vm/raspibackup (Filesystem: nfs)
--- RBK0033I: Please wait until cleanup has finished
--- RBK0320I: Removing incomplete backup. This may take some time. Please be patient
??? RBK0005E: Backup failed. Check previous error messages for details
--- RBK0010I: rocrailpi: raspiBackup.sh V0.7.1.1 - 2025-11-18 (5b75436) stopped at Fri 21 Nov 21:40:33 CET 2025 with rc 102
--- RBK0026I: Debug logfile saved in /home/ansible/raspiBackup.logBei V4 das gleiche.
Danke für die schnelle Antwort
Gruss
Stefan
Also die Meldung kommt bei beiden Mount Varianten, egal ob ich via V4 oder V3 mounte:
Ja, unter Trixie wegen
/mnt/nas2/backup-vm/raspibackup has ACLs according ls
Meine Frage bezog sich auf Bookworm. Da ist das Problem ja noch nicht vorhanden und da hast Du raspiBackup erfolgreich nutzen können. Nach meiner Theorie nutzt Du v4 unter Bookworm und v3 sollte von raspiBackup abgewiesen werden.
framp sorry, hatte das falsch verstanden ;-).
Bookworm auf dem PI habe ich nicht, aber noch eine Version älter:
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
Und von dem sichert es mit den gleichen Mount Einstellungen einwandfrei. ( Auf QNAP + NFSv4 )
Gruss
Stefan
PS: Danke für das tolle Backupscript.
Ob Bookworm oder Bullseye - das Problem kommt ja mit Trixie hoch.
Und von dem sichert es mit den gleichen Mount Einstellungen einwandfrei.
Welche nfs Version wird denn da genutzt? Ich habe ja explizit bei meinem Test angegeben dass v3 und v4 genutzt werden soll. Mit mount | grep nfs siehst Du welche Version Du nutzt.
PS: Danke für das tolle Backupscript.
Ich danke für Deine Hilfe bei dem Problem.
framp Hier der Output von Debian 11 mit NFSv4 Mount und deinem Script:
./checkACLs.sh /mnt/nas2/backup-vm/raspibackup/
@@@ mount | grep -m 1 /mnt/nas2/backup-vm/raspibackup
<ip>:/backup-vm/raspibackup on /mnt/nas2/backup-vm/raspibackup type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=<client_ip>,local_lock=none,addr=<ip>,_netdev)
@@@ ls -lad /mnt/nas2/backup-vm/raspibackup
drwxrwxrwx 4 setupuser users 4 Nov 21 21:40 /mnt/nas2/backup-vm/raspibackup
--- /mnt/nas2/backup-vm/raspibackup has NO ACLs according ls
--- /mnt/nas2/backup-vm/raspibackup has NO ACLs
--- /mnt/nas2/backup-vm/raspibackup has NO default ACLs
@@@ getfacl -p /mnt/nas2/backup-vm/raspibackup
# file: /mnt/nas2/backup-vm/raspibackup
# owner: setupuser
# group: users
user::rwx
group::rwx
other::rwxPerfekt Danke.
Genau das habe ich erwartet. Wenn Du noch mal die NAS per v3 mounten könntest (nfsvers=3 als Option, s.o.) und das Script aufrufen würdest kann ich auch verifizieren dass meine Vermutung, dass dann raspiBackup abbricht, stimmt.
Gerne ;-), also noch mal der Output von Debian 11 mit NFS v3
./checkACLs.sh /mnt/nas2/backup-vm/raspibackup/
@@@ mount | grep -m 1 /mnt/nas2/backup-vm/raspibackup
<ip>:/backup-vm/raspibackup on /mnt/nas2/backup-vm/raspibackup type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=<ip>,mountvers=3,mountport=56875,mountproto=udp,local_lock=none,addr=<ip>,_netdev)
@@@ ls -lad /mnt/nas2/backup-vm/raspibackup
drwxrwxrwx+ 4 setupuser users 4 Nov 21 21:40 /mnt/nas2/backup-vm/raspibackup
+++ /mnt/nas2/backup-vm/raspibackup has ACLs according ls
+++ /mnt/nas2/backup-vm/raspibackup has ACLs
+++ /mnt/nas2/backup-vm/raspibackup has default ACLs
@@@ getfacl -p /mnt/nas2/backup-vm/raspibackup
# file: /mnt/nas2/backup-vm/raspibackup
# owner: setupuser
# group: users
user::rwx
user:setupuser:rwx
user:nobody:---
group::rwx
group:root:rwx
mask::rwx
other::rwx
default:user::---
default:user:setupuser:rwx
default:user:nobody:---
default:group::---
default:group:root:rwx
default:mask::rwx
default:other::rwxDon’t have an account yet? Register yourself now and be a part of our community!