nfs und Linux ACL Support moeglich auf der Syno ?

[framp]

Immer wieder bekomme ich Problemberichte von Benutzern von raspiBackup welches ich eigentlich nur fuer mich geschrieben habe um meine Raspberries zu sichern. Irgendwann dachte ich dann dass es vielleicht auch ganz nuetzlich fuer andere Raspberrynutzer sein koennte. Jedenfalls habe ich nie Probleme mit ACLs aber mittlerweile ist die Nutzerzahl doch schon groesser und es kommen immer weitere Nutzer dazu. Deshalb kommt immer wieder ein Benutzer um die Ecke und hat ACL Probleme mit nfs und meist ist der nfs Server eine Syno. Mein bisheriger Ratschlag ist die ACLs beim rsync auszunehmen - was aber eigentlich eine Kruecke ist.

Ich muss gestehen dass ich ziemlich verwirrt bin ob und wie Linux ACLs per nfs unterstuetzt werden. In diesem Thread steht dass es gehen soll mit nfs4. Ich bekomme es aber nicht hin

Folgendes habe ich auf meinem Client getan um das zu testen:

setfacl -m u:framp:rw aclFile
sudo rsync -aAv . /remote/raspiBackup
sending incremental file list
rsync: set_acl: sys_acl_set_file(aclFile, ACL_TYPE_ACCESS): Operation not supported (95)

sent 96 bytes received 108 bytes 408.00 bytes/sec
total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]

Der Mount sie wie folgt aus:

192.168.0.9:/volume1/raspiBackup on /remote/raspiBackup type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.6,local_lock=none,addr=192.168.0.9,_netdev)

D.h. es wird 4.1 genutzt.

Auf der Syno steht in /etc/exports

/volume1/raspiBackup 192.168.0.0/24(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

D.h. nach meinem Verstaendnis sollten eigentlich auch ACLs per nfs auf der Syno landen koennen. Tun sie aber nicht Hat jemand fuer mich einen Tipp was ich falsch mache damit ich den Nutzern sagen kann wie sie ihre ACLs auch auf eine Syno sichern koennen?

 

[Benares]

Bisher habe ich gelesen, dass man für ACL-Unterstützung clientseitig einfach vers=3 oder vers=4 bei den Mount-Optionen mit aufnehmen muss.
Ob auch die Option "Standard-UNIX-Berechtigungen anwenden" (normalerweise gesetzt) in den erweiterten NFS-Einstellungen eine Rolle spielt, weiß ich nicht. Laut Hilfe betrifft das aber eher die Rechte für die Dinge, die der Client auf dem Server erstellt.

 

[framp]

Vielen Dank fuer Deine Antwort. Ich nutze ja nfs 4.1. Aber trotzdem werden keine ACLs gesichert

 

[Benares]

Was du mit "ACLs gesichert". Wichtig ist doch erstmal, dass man auf Verzeichnisse mit z.B. d---------+ bei den Rechten, die neuere DSM-Versionen so gerne verwenden, über NFS überhaupt zugreifen kann.

 

[framp]

Wenn man ein Backup restored sollte wieder alles wie vorher sein - incl ACLs. Ansonsten ist das kein konsistentes Backup.

 

[Benares]

Achso, um Backups geht's
Da würde ich mich nicht auf das Ziel-Filesystem verlassen, sondern eher in ein Archiv sichern, selbst wenn's das alte tar ist. Das kann dann überall liegen.

Ich bin ja schon froh, wenn der NFS-Zugriff auf Ordner, die ACLs verwenden, klappt.

 

[framp]

raspiBackup kann auch ein tar erstellen. Aber rsync hat den Vorteil dass nicht immer alle Daten gesichert werden muessen sondern nur Aenderungen und neue Dateien. Das geht viel schneller und belegt wenn Du BackupVersionen aufhebst viel weniger Speicherplatz.

 

[Benares]

Kann man rsync nicht auch als Client-/Server-Prozess betreiben? Dann wär's doch ganz unabhängig von cifs/nfs & Co.

Ich hab mal vor vielen Jahren mit rsync rumgespielt. Da konnte man serverseitig in der /etc/rsync.conf sowas wie Shares definieren und clientseitig mit z.B.

rsync -aP /volume1/photo/*  root@ds212::photo

ansprechen

 

[framp]

Du reibst Salz in meine Wunde. Leider unterstuetzt raspiBackup bislang keinen rsync Server. Es ist geplant - aber es fehlt an der Zeit das anzugehen. Momentan gibt es wichtigere Dinge zu tun

 

[framp]

Gibt es wirklich niemanden der ACLs per nfs nutzt?

 

[mcm57]

Da ich nun auch über das acl Problem geflogen bin habe ich im Netz gestöbert - und auch einen offiziellen Issue bei Synology aufgemacht.

a) Der Synology Call hat leider (bisher) nichts wirklich brauchbares gebracht. Antwort siehe unten. Auf meine Frage ob NFS ACLs unterstützt werden wurde nicht wirklich eingegangen.

b) Was ich aber hier
https://serverfault.com/questions/539568/no-acl-on-nfs-mount-in-linux
entdeckt habe ist interessant. Offensichtlich scheint es acls und nfsv4_acls zu geben die absolut nicht identisch sind. Scheinbar gibt es posix acls nur bis nfs v3. So wie sich das liest verwendet rsync aber (zumidnest dem Namen nach) posix acls.

Irgendwie bin ich nun total verwirrt. Faklls sich hier irgendwer mit NFS ACLs und insbesondere mit der Umsetzung auf der Synology auskennt, bitte um ein wenig Lichts ins Dunkel.

Danke
McM

----- Synology Antwort auf die Frage ob NFS ACLs unterstützt werden ---

Sehr geehrter ....

vielen Dank, dass Sie den Technischen Support von Synology kontaktieren.

Bitte überprüfen Sie Ihre Einstellungen unter dem folgenden Pfad. Die Standardberechtigung im DSM ist ACL für alle Protokolle.

1. - Systemsteuerung -> Dateidienste -> SMB -> Erweiterte Einstellungen -> Allgemein und setzen Sie SMB min. auf SMB2 und max. auf SMB3.

2. Prüfen Sie in den Ordnereinstellungen, ob die NFS-Berechtigungen gesetzt sind.

3. NFSv4.1 und die damit verbundenen erweiterten Funktionen (Multipathing) werden auf Synology NAS-Modellen mit den folgenden Paketarchitekturen nicht mehr unterstützt: Alpine, Alpine4k, armada38x, Avoton, Braswell, Bromolow, Cedarview, Grantley, Monaco. Wenn Sie zuvor NFSv4 und NFSv4.1 aktiviert hatten, wird das maximale NFS-Protokoll nach dem Update standardmäßig auf NFSv4 gesetzt. Weitere Informationen über die Paketarchitektur Ihres Modells finden Sie hier.

Wenn Sie noch Fragen haben, stehe ich Ihnen jederzeit gerne weiter zur Verfügung.

Mit freundlichen Grüßen,

 

[framp]

Noch schlimmer wird es weil es auch nfs Implementierungen gibt die irgendwelche pre oder Draft Standards implementiert haben. Keine Ahnung welche nfs Implementierung Syno nutzt: Aus meinen Eruierungen zu dem Thema habe ich nur entnommen das es ein nfs und ACL Tohuwabou gibt

 

[mcm57]

Hallo framp

Ich seh das mittlerweile auch so. Und ich weiß nicht mal welche acl Implementierung rsync versucht zu verwenden :-(
Ich gehe davon aus, dass es Posix acls sind - aber nur weil in der Fehlermeldung setfacl steht ...

Ich werd noch mal bei Synology nachbohren, fürchte aber dass ich keine klare Aussage bekommen werde.

Am Raspi hab ich das Problem so gelöst, dass ich die ACLs bei der zuletzt störenden Applikation (ioBroker) samt und sonders gelöscht habe und nur die Linux Protection aktiviert habe. Der Raspi ist sowieso kein Multiusersystem wo Zugriffsrechte ein echter Bedarf sind.

McM

 

[framp]

Ich gehe davon aus, dass es Posix acls sind - aber nur weil in der Fehlermeldung setfacl steht ...

Sehe ich auch so.

Ich werd noch mal bei Synology nachbohren, fürchte aber dass ich keine klare Aussage bekommen werde.

Bis Du da eine kompetente Antwort erhaelst musst Du aber tief bohren

Am Raspi hab ich das Problem so gelöst, dass ich die ACLs bei der zuletzt störenden Applikation (ioBroker) samt und sonders gelöscht habe und nur die Linux Protection aktiviert habe. Der Raspi ist sowieso kein Multiusersystem wo Zugriffsrechte ein echter Bedarf sind.

Ist eine moegliche Loesung. Weisst Du warum der IOBroker ACLs nutzt? Oder vielleicht ist das auch ein Erbe vom OS wie das Persistent Journaling im neuesten Debian Bullseye?

Bloed ist dass wohl jeder Nutzer von IOBroker mit dem Problem zu kaempfen hat. Ich habe ja hier Alternativen beschrieben. U.A. steht da auch die ACLs zu loeschen. Waere gut wenn man fuer den IOBroker eine moeglichst einfache Loesung findet fuer raspiBackup und ACLs.

Ein weiterer Weg ist den rsync daemon zu nutzen. Ich bin gerade dran und probiere den in raspiBackup zu integrieren. Ist aber in bash wirklich nicht gerade einfach da das Design von raspiBackup davon ausgeht dass die Kontrolle der Backups lokale vorgenommen wird. Wenn der rsync daemon genutzt wird muss der Backup Cleanup per ss remote ausgefuehrt werden und dann kommt ziemlich viel zusaetzlicher Kram dazu (Fehlerbehandlung, Recovery bei Kommunikationsabbruch ...).

fsc830 hat im Raspberryforum noch einen anderen Weg eingeschlagen: Er nutzt ein grosses Image auf dem Backupspace per nfs welches als Loopdevice gemountet ist. Siehe dazu auch das raspibackup Wrapperscript wo sich entsprechender Code dazu findet. Vielleicht ist das auch noch eine Alternative fuer Dich

 

[mcm57]

Danke für deine Mühe.

Warum ioBroker acls benutzt weiß ich nicht. Aber ich gehe davon aus, dass die Entwickler hier beste Sicherheit implementieren wollen. In einem Multiuser System wär es ja durchaus sinnvoll Rechte fein zu vergeben. Am Raspi wo (zumindest ich) immer mit einem User einlogge under hat sudo Rechte ist das kaum ein Sicherheitsgewinn.

Die Lösung mit fsc830 / image ist mir zu unsicher. Ich befürchte dass das Image bei einem unsauberen Abbruch schnall mal zerstört würde. Und ich kann nicht sicher ausschließen, dass das NAS nicht z.B. während eines Backups runter fährt. Bei rsync nativ passiert da wenig - außer das das wip Backup selbst unvollständig wäre. (Dabei fällt mir ein - hast du schon mal drüber nachgedacht das Backupverzeichnis z.b. mit xxx-tmp anzulegen und erst nach vollständigem erfolgreichem Backup in den finalen Namen umzubenennen? Werder an den Dateien im Verzeichnis noch an den hardlinks sollte das was ändern. Aber unvollständige Backups wären da leicht identifizierbar. Soll aber nicht als Arbeitsauftrag gelten - fad ist wahrscheinlich niemand. Nur do eine Idee beim Schreiben).

Was die ioBroker acls betrifft - ich konnte bisher keine negativen Nebenwirkungen durch das Entfernen der acls feststellen. Bin aber noch ganz am Anfang.

Übrigends die Installationen von grafan, telegram und influxdb haben keine acls angelegt. Ist also m.E. kein Feature con Raspian das bei Neuinstllationen immer acls anlegen will oder so.

McM

 

[mcm57]

So jetzt hab ich eine eigentlich klare Antwort bekommen. Posix ACLs unter NFS v3 sollten gehen. NFS ACLs sollten nicht gehen.
Wo da die Firwall mitspielt ist mir im Moment noch unklar.

Jetzt muss ich / müssen wir nur mehr rausbekommen warum es nicht geht

Ich finde es toll, dass Synology hier rasch und detailliert antwortet. Das möchte ich auch festhalten.

McM


---------------------------------------------------
Offizielle Antwort vom Synology Support:

Sehr geehrter Herr ...

vielen Dank für Ihre Nachricht.

1. Posix NFS ACLs unter NFSv3: Ja, "Wenn NFSv3-Dienste verwendet werden sollen, gehen Sie zu Systemsteuerung > Sicherheit > Firewall und erstellen Sie eine Firewall-Regel, die "Mac/Linux-Dateiserver" aus der Liste der integrierten Anwendungen aktiviert".

2. NFS ACLs unter NFSv4 : Nein. NFSv4.1 wurde für die meisten Systeme entfernt, aber NFSv4 kann weiterhin verwendet werden. ACLs werden aber bei Version 4 generell nicht unterstützt, egal ob es sich um 4.0 oder 4.1 handelt.
Weitere Details finden Sie in dem unten verlinkten Dokument.

https://kb.synology.com/de-de/DSM/help/DSM/AdminCenter/file_winmacnfs_nfs?version=6
https://kb.synology.com/de-de/DSM/t..._on_Synology_NAS_within_the_local_network_NFS

Ich hoffe, die Informationen beantworten Ihre Fragen. Wenn Sie noch Fragen haben, stehe ich Ihnen jederzeit gerne weiter zur Verfügung.

Mit freundlichen Grüßen,

 

[framp]

Die Lösung mit fsc830 / image ist mir zu unsicher.

Ich denke fas Filesystem im Iamge wird keine Probelem machen. Aber man sollte das Image wenigstens auf einem RAID1 liegen haben. Denn wenn an dem Image irgendwas durch Plattenfehler kaputtgeht sind alle Backups weg.

(Dabei fällt mir ein - hast du schon mal drüber nachgedacht das Backupverzeichnis z.b. mit xxx-tmp anzulegen und erst nach vollständigem erfolgreichem Backup in den finalen Namen umzubenennen?

Nein. Ist aber keine schlechte Idee die ich mal im Hinterkopf behalte.

Übrigends die Installationen von grafan, telegram und influxdb haben keine acls angelegt. Ist also m.E. kein Feature con Raspian das bei Neuinstllationen immer acls anlegen will oder so.

ACLs werden auch nur in speziellen Situationen genutzt wo die normale Linux Dateisicherheit nicht ausreicht. Deshalb tauchen sie nur relativ selten auf. Warum Debian jetzt beim Persistent Journaling ACLs genommen hat verstehe ich nicht.

 

[framp]

ich habe noch mal etwas rumprobiert und dabei einen Raspberry nfs Server genommen. Mit nfs version 3 funktioniert das kopieren von ACLs mit rsync.

Nur bei der Syno nicht obwohl nfsvers3 genutzt wird und die ominoese FW Rule aktiv ist

pi@rsyncServer:~ $ cat /etc/fstab | grep "/back"
192.168.0.9:/volume1/raspiBackup /backupSyno nfs4 rw,acl,noauto,nfsvers=3 0 0
localhost:/srv/nfs /backup nfs4 rw,acl,noauto,nfsvers=3 0 0

pi@rsyncServer:~ $ mount | grep "back"
localhost:/srv/nfs on /backup type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,mountaddr=::1,mountvers=3,mountproto=tcp6,local_lock=none,addr=::1)
192.168.0.9:/volume1/raspiBackup on /backupSyno type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.9,mountvers=3,mountproto=tcp,local_lock=none,addr=192.168.0.9)

pi@rsyncServer:~ $ sudo rsync -AXxv * /backupSyno/
acl.txt
rsync: [receiver] set_acl: sys_acl_set_file(.acl.txt.ttQScZ, ACL_TYPE_ACCESS): Operation not supported (95)
sent 107 bytes received 35 bytes 284.00 bytes/sec
total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1333) [sender=3.2.3]

pi@rsyncServer:~ $ sudo rsync -AXxv * /backup
acl.txt
sent 107 bytes received 35 bytes 284.00 bytes/sec
total size is 0 speedup is 0.00

 

[framp]

Gestern habe ich noch mal ein Supportticket ber Synology zu dem Thema erstellt denn es ist wirklich zu Huehnermelken mit dem Thema und bekam jetzt endlich auch eine eindeutige Antwort:

Zitat


Unfortunately, I have to inform you that both Linux ACL and setfacl are not supported by DSM.
I would be pass this on as feedback to our development department as a function request.