Ergebnis 1 bis 10 von 10
  1. #1
    Anwender
    Registriert seit
    14.10.2019
    Beiträge
    7

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

    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?

  2. #2
    Anwender
    Registriert seit
    09.02.2009
    Beiträge
    370

    Standard

    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/

  3. #3

    Standard

    Zitat Zitat von ptthomas Beitrag anzeigen
    ...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.
    Code:
    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?

  4. #4
    Anwender
    Registriert seit
    14.10.2019
    Beiträge
    7

    Standard

    @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:
    nfs777_benutzer_applikationen.jpg
    nfs777_benutzer_benutzergruppen.jpg
    nfs777_benutzer_berechtigungen.jpg
    nfs777_benutzer_info.jpg
    nfs777_freigegebener-ordner_allgemein.jpg
    nfs777_freigegebener-ordner_berechtigungen.jpg
    nfs777_freigegebener-ordner_erweiterte-berechtigungen.jpg
    nfs777_freigegebener-ordner_nfs-berechtigungen.jpg
    nfs777_systemsteuerung.jpg

  5. #5
    Anwender
    Registriert seit
    14.10.2019
    Beiträge
    7

    Standard

    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.

  6. #6

    Standard

    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:
    Code:
    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.
    Code:
    sudo usermod -u 1030 nfsuser
    sudo usermod -g users nfsuser
    Geprueft ob alles stimmt:
    Code:
    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)
    Code:
    /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)
    Code:
    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.

    Zitat Zitat von ptthomas Beitrag anzeigen
    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.

  7. #7
    Anwender
    Registriert seit
    14.10.2019
    Beiträge
    7

    Standard

    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.

  8. #8
    Anwender Avatar von Puppetmaster
    Registriert seit
    03.02.2012
    Beiträge
    16.948

    Standard

    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.
    Geändert von Puppetmaster (24.10.2019 um 07:19 Uhr)
    DS415+ DSM 6.2.1-23824 U1 | 2x2TB BTRFS RAID1 + 8TB EXT4 (Basis) WD Red 24/7
    DS214+ DSM 6.2.1-23824 U1 | 3TB WD Red (Basis) + 6TB Seagate Archive (Basis)
    Media Logitech Media-Server 7.7.2 | Squeezebox Classic | Squeezebox Transporter | VU+ Uno | Raspberry Pi - OpenELEC 6.0.1 Kodi v15
    USV APC Back-UPS RS550GI


    Reset einer DiskStation | Migration zwischen DiskStations | Festplattenzugriff mittels Knoppix-DVD

  9. #9

    Standard

    Zitat Zitat von Puppetmaster Beitrag anzeigen
    ... 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.

  10. #10
    Anwender
    Registriert seit
    14.10.2019
    Beiträge
    7

    Standard

    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?

Ähnliche Themen

  1. Antworten: 2
    Letzter Beitrag: 20.04.2017, 12:35
  2. NFS "keine Berechtigung" auf dem Client
    Von agent4788 im Forum NFS-Server
    Antworten: 1
    Letzter Beitrag: 30.12.2016, 23:17
  3. Antworten: 3
    Letzter Beitrag: 13.04.2015, 14:15
  4. Antworten: 2
    Letzter Beitrag: 23.02.2013, 19:29
  5. Antworten: 2
    Letzter Beitrag: 31.08.2012, 09:46

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •