FHEM und ACLs in Bezug auf raspiBackup [gelöst]

Quote from Bracew

Möchtest Du hier alle 110.911 gelistet haben? Ich glaube nicht, aber für den Anfang hier ein Auszug der ersten und letzten:

Nee. Das reicht schon . Irgendwas ist da auf Deinem System passiert dass alle Dateien ACLs bekommen haben

So wie es aussieht hat bei Dir jede Datei ACLs Die Frage ist wie das passiert ist. Du hast doch ein RaspbianOS oder? Zeige mal bitte

cat /etc/os-release

Quote from Bracew

Ich denke, dass ich mir die Suppe mit dem Restore eingebrockt habe, den bis dahin liefen die Backups wie geschmiert!

Das ist mir auch schon in den Sinn gekommen

Allerdings verstehe ich nicht wie denn in Deinem Backup auf der Syno gibt es keine ACLs und somit koennen auch keine beim Restore entstehen. Die Syno unterstuetzt keine Posix ACLs die von rsync genutzt werden

Quote from Bracew

Eine Synology(?)-NAS ist eine falsche Vermutung

Sorry - ich kann mir nicht die Konfiguration aller meiner raspiBackup Nutzer merken . Viele nutzen eine Syno oder QNAP.

Aber gut zu wissen. D.h. Du exportierst eine USB HDD von einer anderen Raspi und sicherst darauf. Man braucht nicht unbedingt eine NAS. Ich habe lange Zeit auch meine Backups auf einer Raspberry abgelegt.

Kannst Du mal folgende Befehle auf Deiner Raspi eingeben und die Ausgabe zeigen?

mount
ls -la <nfsMountPoint>

Du hast am Verzeichnis /backup und am übergeorfneten Verzeichnis (root) ein ACL gesetzt, wie an dem + Zeichen hinter den Dateirechten ersichtlich ist.

Alle in diesen Verzeichnissen neu erstellte Dateien und Verzeichnisse könnten mit demselben ACL beerbt werden..

Mit < getfacl /backup > kannst Du Dir die Access Controll List des /backup Verzeichnisses ansehen.

Siehe < getfacl -h >, < setfacl -h >, < man acl > samt SEE ALSO

Für das Einrichten eines NFS Clients und Servers siehe https://www.raspberrypi.com/documentation/…file-system-nfs

Servus !

Quote from Bracew

Die NFS-Verbindung wird erst zur Backup-Zeit vom raspiBackupNfsWrapper.sh aufgebaut.

Das hatte ich vergessen. Mountest Du noch mal /backup und zeigst Dann die Ausgabe von mount und sudo ls -la /backup?

Ich denke RTFM hat den entscheidenen Hinweis gegeben. Wenn ich das momentan richtig ueberblicke koennen wir wohl die ACLs auf Deinem System wieder loswerden. Aber dazu brauche ich noch die vorhergehende Ausgabe und muss bei mir lokal auch noch mal was nachstellen.

Nachdem RTFM mich angeschubst hat (Noch mal vielen Dank!) habe ich das Problem reproduzieren koennen und somit verstanden

Was habe ich gemacht?

Ich habe auf einer Raspi per nfs4 ein Verzeichnis exportiert und bei diesem Verzeichnis /disks/silver/raspiBackup Default ACLs definiert:

root@asterix:/disks/silver/raspiBackup# getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:root:rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:user:root:rwx
default:group::rwx
default:mask::rwx
default:other::rwx

Dann habe ich dieses Backupverzeichnis an einer anderen Raspi per nfs4 gemounted und raspiBackup gestartet. Das Ergebnis auf der Backupserverseite:

root@asterix:/disks/silver/raspiBackup/raspberrypi-bullseye-desktop# find . -maxdepth 1 -exec ls -l {} \;
total 4
drwxr-xr-x+ 18 root root 4096 Oct 10 22:53 raspberrypi-bullseye-desktop-rsync-backup-20221107-175852
total 262220
lrwxrwxrwx    1 root root         7 Sep 22 02:02 bin -> usr/bin
drwxr-xr-x+   2 root root      4096 Jan  1  1970 boot
drwxr-xr-x+   2 root root      4096 Nov  5 22:10 dev
drwxr-xr-x+ 123 root root      4096 Nov  7 17:49 etc
drwxr-xr-x+   3 root root      4096 Oct 10 22:46 home
lrwxrwxrwx    1 root root         7 Sep 22 02:02 lib -> usr/lib
drwx------+   2 root root      4096 Sep 22 02:32 lost+found
drwxr-xr-x+   2 root root      4096 Oct 24 11:23 media
drwxr-xr-x+   2 root root      4096 Sep 22 02:02 mnt
drwxr-xr-x+   4 root root      4096 Sep 22 02:12 opt
dr-xr-xr-x+   2 root root      4096 Jan  1  1970 proc
-rw-r--r--+   1 root root 268435456 Nov  7 17:59 raspberrypi-bullseye-desktop-backup.img
-rw-r--r--+   1 root root       512 Nov  7 17:59 raspberrypi-bullseye-desktop-backup.mbr
-rw-r--r--+   1 root root       212 Nov  7 17:59 raspberrypi-bullseye-desktop-backup.sfdisk
drwx------+   6 root root      4096 Nov  7 17:49 root
drwxr-xr-x+   2 root root      4096 Nov  7 17:32 run
lrwxrwxrwx    1 root root         8 Sep 22 02:02 sbin -> usr/sbin
drwxr-xr-x+   2 root root      4096 Sep 22 02:02 srv
dr-xr-xr-x+   2 root root      4096 Jan  1  1970 sys
drwxrwxrwt+   2 root root      4096 Nov  7 17:58 tmp
drwxr-xr-x+  11 root root      4096 Sep 22 02:02 usr
drwx------+   2 root root      4096 Nov  7 17:59 var

Wie man sieht haben alle Verzeichnisse und Dateien ACLs bekommen (das + Zeichen) da das Backupwurzelverzeichnis ACLs hat und diese an alles was darunter erstellt wird weitervererbt

D.h. wenn man nun dieses Backup direkt - also ohne nfs - zurueckspielt bekommt das restorte System auch ACLs da rsync ACLs kopieren kann wenn kein nfs genutzt wird

Jetzt ist die Frage ob und wie Bracew s HuhnPi seine ACLs wieder los wird und ob es sein muss.

1) Genaugenommen sind die ACLs kein Problem. Das System laeuft auch mit ihnen ohne Probleme. D.h. man koennte es jetzt so lassen. Da die Option A bei rsync entfernt wurde werden zukueftig keine ACLs mehr beim Backup kopiert und sollte mal wieder ein Backup restored werden muessen sind die ACLs weg. Natuerlich sollte auch die Quelle allen Uebels - die ACL vom Backupverzeichnis - geloescht werden.

Wenn Bracew aber sein HuhnPi schnell wieder ACL frei haben moechte muss

2) entweder das naechste Backup was ohne die Option A erstellt wurde einfach zurueckgespielt werden. Am besten auf eine andere SD Karte um falls doch noch irgendwas nicht OK sein sollte wieder zurueckgehen zu koennen.

3) Alternativ kann auch das Backup was damals mit ACLs zurueckgespielt wurde noch einmal restored werden. Da jetzt die Option A bei rsync fehlt werden auch keine ACLs mehr zurueckgespielt.

Welchen der drei Wege Du Bracew einschlaegst musst Du entscheiden

Wie Du es geschafft hast im Backupverzeichnis ACLs zu setzen weisst nur Du

Quote from Bracew

Mit Verweis auf https://github.com/framps/raspiBa…ment-1218038375

nutze ich auf dem HuhnPi raspiBackup.sh 0.6.6.1.

Stimmt. Aus irgendeinem Grunde nutzt Du noch das alte 0.6.6.1. Dann musst Du beim Restore immer dran denken noch den Backupverzeichnismountpunkt nach dem Restore anzulegen. Oder Du upgradest auf die aktuelle 0.6.7. Genaugenommen solltest Du auch mal sehen dass Du vom Stretch wegkommst. Stretch ist out of support.

Quote from Bracew

Ich würde mich für 1) entscheiden.

In die Richtung hattest Du Dich ja schon im FHEM Forum geaeussert

Quote from Bracew

Wie erstelle ich ein neues korrektes /backup Verzeichnis?

Du brauchst kein neues Verzeichnis zu erstellen. Du musst nur das Verzeichnis finden welches die ACLs hat und diese loeschen. Dazu musst Du auf Deine NFS Server gehen. Lt der obigen Ausgabe

192.168.0.20:/media/USBHDD1/public/Backup on /backup type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.50,local_lock=none,addr=192.168.0.20)

muss das Dein .20 sein. Dort gehe in das Verzeichnis

/media/USBHDD1/public/Backup

und fuehre folgenden Befehl aus:

find . -type d -maxdepth 1 -exec getfacl -s {} \;

Damit wird in einer Verzeichnistiefe von 1 nach Verzeichnissen mit ACLs gesucht. Falls Du nichts ausgegeben bekommst musst Du statt . /media/USBHDD1/public angeben. Falls da immer noch nichts kommt /media/USBHDD1/. Falls immer noch ncihts kommt /media. Ich glaube Du fast wirst ACLs erst finden bei /media

Quote from Bracew

sudo mkdir /backup

sudo chown root:root /backup

Ist das so Ok?

sudo mkdir /backup

reicht vollkommen.

Quote from Bracew

Ich fürchte, dass die beiden letzten Sätze hier einen Aufschrei auslösen werden. Der Diskussion werde ich mich aber nicht stellen.

Ich hoffe nicht denn das hat mit dem eigentlichen Thema nichts zu tun

Es ist Deine Entscheidung den Weg des Never touch a running System zu gehen und wenn die Systeme nicht am Internet haengen sehe ich da auch keine Probleme - auch wenn ich diese Strategie nicht gutheisse

Nur muss Dir klar sein dass es umso schwieriger wird Systeme auf neue Staende zu bringen je aelter sie sind. FHEM, RaspbianOS werden weiterentwickelt ... Auch raspiBackup wird sich weiterentwickeln und ich rolle keine Fixes mehr in alte Releases rein - wie z.B. das Problem bei Dir in 0.6.6.1 mit dem fehlenden BackupMountpoint

Quote from Bracew

dachte ich es liegt an den ACLs des temporär gemounteten /backup Verzeichnis.

Wie Du das geschafft hast weiss ich nicht. Ich habe das versucht aber nicht geschafft bei mir. Finde jetzt erst mal das ACL Verzeichnis auf Deinem NFS Server wie oben beschrieben.

Quote from Bracew

Wo sehe ich denn, welches ACLs hat?

Alles was der Befehl ausspuckt.

Loeschen der ACLs geht mit sudo setfacl -b <verzeichnisname>

Quote from framp

Loeschen der ACLs geht mit sudo setfacl -b <verzeichnisname>

Geht das nicht mit -R recursiv?

z.B. sudo setfacl -b -R /backup

Laut man setfacl gibt es auch dort die Option -R

Quote

-R, --recursive

Apply operations to all files and directories recursively. This option cannot be mixed

with `--restore'.

Ja - da hast Du Recht . Ich will eigentlich nur den Uebeltaeter, der dafuer sorgt dass alle Backups ACLs durch Vererbung bekommen, entfernen. D.h. dann entstehen bei zukuenftigen Backups keine ACLs mehr. Die alten Backups haben die ACLs natuerlich noch. Da aber Bracew die Option A bei rsync in raspiBackup entfernt hat werden beim Restore dieser mit ACLs behafteten Backups die ACLs zukuenftig nicht mehr restored und somit ist es nicht notwendig alle ACLs aus den Backups zu entfernen. Aber man koennte es natuerlich tun