Mit NFS bekommen alle Dateien auf dem Server die Rechte "777"

[ptthomas]

Hallo,

ich verzweifle gerade an der Nutzung der NAS mit Linux-Clients:
Verzeichnisanbindung über SMB ist easy-go-lucky. Aber ich habe hier die Anforderung, dass die Dateien, die auf der NAS abgespeichert werden, die RWX-Attribute für Owner/Group/World unverändert zu verwenden hat.
Leider setzt mir die Synology DS1618+ die Dateiattribute stets auf 777 ("rwxrwxrwx").

Das passiert nicht nur mit NFS, sondern auch wenn ich alternativ sshfs mit SFTP verwende.

Funktioniert das bei irgendjemanden bereits korrekt?

Hat jemand eine Idee, wie ich der NAS beibringen kann, auch in der Linux-Welt vernünftig zu funktionieren?

 

[bfpears]

Moin,

also ich greife von meinen Linux Clients per SMB auf die DS zu.

NFS an sich kennt ja keine Benutzer Rechte,
Bei NFS werden Dateirechte eigentlich über eine Netzwerk Weite einheitliche UserID geregelt.
Da das für die meisten zu umständlich ist bekommen der Client meist über die Server Einstellungen alle Rechte.
https://wiki.ubuntuusers.de/NFS/

 

[framp]

...Hat jemand eine Idee, wie ich der NAS beibringen kann, auch in der Linux-Welt vernünftig zu funktionieren?

Ich schaufele staendig Daten von Linux Systemen per nfs auf meine Syno und habe keine Probleme mit den Rechten. Anbei das Homeverzeichnis des Benutzers Pi einer meiner Raspberries, die ich per PXE boote. Du siehst aber keinen Benutzer Pi da es die UID und GID 1000 nicht auf der Syno gibt.

sudo ls -la /volume1/pxe_nfs/87f728f5/home/pi/
total 284
drwxr-xr-x 1 1000 1000    304 Oct 22 19:14 .
drwxr-xr-x 1 root root      4 Sep 18 18:22 ..
-rw------- 1 1000 1000  27832 Oct 22 19:15 .bash_history
-rw-r--r-- 1 1000 1000    220 Jun 20 18:47 .bash_logout
-rw-r--r-- 1 1000 1000   3523 Jun 20 18:47 .bashrc
drwx------ 1 1000 1000      4 Sep 18 18:22 .cache
-rwxr-xr-x 1 1000 1000   1476 Jul 30 22:34 check_throttled.sh
drwx------ 1 1000 1000     24 Sep 18 18:22 .config
drwx------ 1 1000 1000     34 Sep 18 18:22 .gnupg
-rw------- 1 1000 1000     69 Oct 17 11:39 .lesshst
drwx------ 1 1000 1000     10 Sep 18 18:22 .local
-rw-r--r-- 1 1000 1000    807 Jun 20 18:47 .profile
-rwxr-xr-x 1 1000 1000 222373 Oct 17 19:56 raspiBackup.sh
-rwxr-xr-x 1 1000 1000   6632 Aug  9 19:37 raspiBackupWrapper.sh
drwx------ 1 1000 1000     52 Sep 18 18:22 .ssh
-rwxr-xr-x 1 1000 1000   1898 Jul 23 19:43 temp_test.sh
-rw-r--r-- 1 1000 1000    209 Jul 30 21:41 .wget-hsts

Wie mountest Du denn die Syno per nfs und wie hast Du den shared Folder freigegeben?

 

[ptthomas]

@framp: Beneidenswert, das ist genau das, was ich möchte...
Aber wie hast Du es denn geschafft dich mittels NFS mit der UID 1000 auf einen NFS-Server zu verbinden, der die UID 1000 gar nicht kennt?

Bzgl. der Fragen packe ich mal ein paar Screenshots dazu:

 

[ptthomas]

Verstehe ich Dich richtig?
Die UserID ist meines Wissens in der Tat essentiell bei NFS. Da habe ich auch sichergestellt, dass die UIDs auf Client- und Server-Seite gleich sind.
Mein Problem sind die Read-/Write-/Execute-Attribute. Beim Austausch von Daten via NFS zwischen zwei Debian-Rechnern hatte ich bislang mit den RWX-Attributen noch kein Problem - das hat NFS (allerdings NFS V4.2) - korrekt umgesetzt.
Und nun wundere ich mich, dass auf der DS1618+ die RWX-Attribute noch schlechter umgesetzt werden, als mit SMB.

 

[framp]

Ich habe keinen Benutzer Pi auf der Syno angelegt. Brauchte ich auch nicht da ich die Dateien per root kopiert habe .

Aber es geht auch als normaler Benutzer. Ich habe es eben mal nachgestellt bei mir. Ich habe auf meiner Syno einen Benutzer nfsuser angelegt und kontrolliert:

id
uid=1030(nfsuser) gid=100(users) groups=100(users)

und denselben Benutzer auf meinem Linux Laptop angelegt. Allerdings musste ich da die UID und GID erst aendern auf 1030 und 100.

sudo usermod -u 1030 nfsuser
sudo usermod -g users nfsuser

Geprueft ob alles stimmt:

id
uid=1030(nfsuser) gid=100(users) groups=100(users)

Danach habe ich einen SharedFolder nfsuser angelegt als normalen User, kein Admin, dem User nfsuser rw Rechte gegeben und bei nfs Einstellungen dem Client rw und no squash. In der /etc/exports auf der Syno steht dann (.107 ist mein Laptop)

/volume1/nfsuser	192.168.0.107(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

mount auf meinem Laptop gibt mir dann (.9 ist meine Syno)

synolix:/volume1/nfsuser on /remote/synolix type nfs (rw,nosuid,nodev,noexec,relatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,timeo=14,retrans=2,sec=sys,mountaddr=192.168.0.9,mountvers=3,mountport=892,mountproto=udp,local_lock=none,addr=192.168.0.9,user=nfsuser)

Dann kann ich beliebig Daten kopieren und die Rechte bleiben erhalten.

Die UserID ist meines Wissens in der Tat essentiell bei NFS. Da habe ich auch sichergestellt, dass die UIDs auf Client- und Server-Seite gleich sind.

Das ist richtig. Wie hast Du das verifiziert?

Mein Problem sind die Read-/Write-/Execute-Attribute. Beim Austausch von Daten via NFS zwischen zwei Debian-Rechnern hatte ich bislang mit den RWX-Attributen noch kein Problem - das hat NFS (allerdings NFS V4.2) - korrekt umgesetzt.
Und nun wundere ich mich, dass auf der DS1618+ die RWX-Attribute noch schlechter umgesetzt werden, als mit SMB.

Keine Ahnung wie das passieren kann. Wie kopierst Du denn die Daten? Ich benutze immer rsync -a.

 

[ptthomas]

Die UIDs habe ich mittels Kommando 'id' sowie über /etc/passwd verifiziert. NFS-Anbindung funktioniert ja grundsätzlich, und zwar erst, nachdem die UIDs stimmig sind.

Nun zum entscheidenden Unterschied:
Ich möchte das NAS-Verzeichnis nicht zur Datensicherung sondern als Betriebs-Verzeichnis verwenden. Und da beginnt es schon beim einfach 'cp'-Befehl, dass ich erwarte, dass auch die Attribute korrekt umkopiert werden.
Und Überraschung für mich: Mit rsync habe ich auch bei mir auch die korrekten Berechtigungen. Grundsätzlich kann der Synology-NAS also mit den Attributen auch unter NFS korrekt umgehen. Aber rsync ist leider nicht mein Einsatzbereich.

 

[Puppetmaster]

cp interessieren keine Benutzer oder Berechtigungen. Wenn diese erhalten bleiben sollen, dann sollte auf rsync zurückgegriffen werden.

edit: Korrektur. Mit Option -a sollten auch bei cp die Rechte und Benutzer erhalten bleiben. Aber das habe ich selbst nicht getestet/genutzt bisher.

 

[framp]

... edit: Korrektur. Mit Option -a sollten auch bei cp die Rechte und Benutzer erhalten bleiben. Aber das habe ich selbst nicht getestet/genutzt bisher.

--preserve=all ist die Zauberoption die alle Rechte bei cp beibehalten laesst . -a ist die Kurzform von -dR --preserve=all und funktioniert deshalb auch.

 

[ptthomas]

Hallo,
besten Dank - "cp -a" führt tatsächlich dazu, dass die Attribute korrekt übernommen werden.
Nur leider ist das ja eigentlich nur ein sehr spezieller Workaround, der nun einmal nur für das "cp"-Kommando gilt.
Auf jeden Fall folgere ich daraus, dass der NAS mittels NFS grundsätzlich mit den Attributen umgehen kann.
Nun brauche es es so, dass es für egal für welche Fileoperation sich das per NFS angebundene Verzeichnis genauso verhält, wie eine lokale Platte mit z.B. einem ext-Filesystem.
Konkrete Anwendung:
Ich möchte einen Git-Server betreiben, die Daten sollen auf dem NAS liegen, der Git-Server selbst soll aber auf einem anderen Rechner betrieben werden.

Nun ist die Frage:
Wenn die NAS grundsätzlich mit den Attributen korrekt umgehen kann, wo muss man was - vermutlich in der NFS-Server-Konfiguration - anpassen, damit der NFS-Server hier kein Eigenleben entwickelt?