Benutzer-ID-Zuordnung mit NFS auf Synology NAS

Ich habe eine Synology NAS-Box (mit DSM 5.1) und habe ein Verzeichnis über NFS exportiert. Ich versuche es auf meiner Ubuntu-Box zu mounten.

Meistens funktioniert es einwandfrei, aber ich habe Probleme mit Benutzer- und Gruppenzuordnungen. Auf der Ubuntu-Box bin ich UID 1000 (Roger), GID 1000 (Roger). Auf der Synology habe ich UID 1026 (Roger), Gruppe 100 (Benutzer).

Wenn ich NFSv3 verwende, werden numerische uid / gid-Werte verwendet, was bedeutet, dass der Besitz der Synology durcheinander gebracht wird.

Wenn ich jemals von derselben Ubuntu-Box mit demselben Benutzer auf den NFS-Mount zugreifen würde, wäre dies in Ordnung, aber ich greife auch von einer Windows-Box mit CIFS (SMB) auf das Verzeichnis zu, was bedeutet, dass die Berechtigungen vorliegen falsch.

Wenn ich NFSv4 ( mount -o nfsvers=4) mit den Standardeinstellungen für die Synology verwende, werden Dateien, die Eigentum roger.usersder Synology sind, im roger.usersUbuntu- Fenster als Eigentum der angezeigt. Das ist gut.

Wenn ich jedoch toucheine Datei:

roger@ubuntu$ touch /mounts/diskstation/music/foo

Es wird 1000.1000in der Synology als Eigentum von nobody.4294967294und in der Ubuntu-Box als Eigentum von angezeigt.

Alles, was ich in den Synology-Foren zu diesem Thema finden kann, stammt entweder aus dem Jahr 2011, als NFSv4 nicht unterstützt wurde, oder besteht aus Personen, die die gleiche Frage stellen und dann aufgeben.

Der Vollständigkeit halber /etc/exportshat:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

... und ich montiere es auf der Ubuntu-Box mit:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

Ich habe einige Hinweise gefunden, dass sec=sysdies ein Problem sein könnte: Warum funktioniert die NFSv4-UID / GID-Zuordnung nicht mit AUTH_UNIX (AUTH_SYS) , aber das hat keine Lösung.

Gibt es einen einfachen Weg, um dieses Problem zu umgehen? Gibt es einen komplexeren Weg ( Husten, Kerberos- Husten ), um dies zu lösen?

Im Ernst, wenn Kerberos ist die Antwort, werde ich diesen Schlag nehmen, aber ich würde gerne wissen, bevor auf sie eine Menge Zeit zu verschwenden.

Update : Während die Synology-Dokumentation verschiedene Kerberos-Optionen behandelt, kann ich sie in der Benutzeroberfläche nicht finden. In den Versionshinweisen heißt es: "Wenn die Kerberos-Sicherheitsversion implementiert ist ...". Ich habe eine Seite gefunden (kann sie aber nicht mehr finden), was bedeutet, dass sie bei bestimmten Modellen möglicherweise nicht vorhanden ist. Ich habe einen DS211 gemäß der Systeminformationsseite. Vielleicht habe ich Pech?

Damit die NFSv4-ID-Zuordnung ordnungsgemäß funktioniert, müssen sowohl der Client als auch der Server den idmapdID Mapper-Dämon ausführen und denselben in Domainkonfiguriert haben /etc/idmapd.conf.

Auf diese Weise sendet Ihr NFS-Client seine ID-Anmeldeinformationen wie [email protected]in den NFS-Befehlen auf der Leitung, und Ihr NFS-Server-ID-Mapper ordnet dies einem Benutzer zu, der rogerauf dem NFS-Server angerufen wurde . Die UID und die GID spielen keine Rolle, sie werden vom idmapper auf jedem System zugeordnet.

Auf meiner Synology kümmere ich mich jedoch nicht darum. Mein freigegebener Ordner hat die folgenden Berechtigungen:

• Berechtigungen
  • Lokale Benutzer
    • Admin = Lesen / Schreiben
• NFS-Berechtigungen
  • Quetschen
    • Ordnen Sie alle Benutzer dem Administrator zu

Dies führt dazu, dass anonuid=1024,anongid=100(der adminBenutzer und die usersGruppe) dem Export /etc/exportsauf dem NAS hinzugefügt werden .

Mein NFS-Client (auf dem der ID-Mapper nicht ausgeführt wird) sendet meine NFS-Befehle als mein Benutzer ( 1000:1000). Da UID und GID auf dem NAS nicht vorhanden sind, werden meine UID und GID in übersetzt, 1024:100sodass ich als Benutzer behandelt werde Admin-Benutzer, der über die volle Berechtigung verfügt.

Dies ist eine furchtbar unprofessionelle und unsichere Verwendung von NFS in einer Geschäftsumgebung, aber nur für mich ist der Zugriff auf meine Dateien zu Hause ein Missbrauch von NFS-Verhalten, der für mich akzeptabel ist.

Eine andere Möglichkeit besteht darin, rogerUID und GID auf dem NFS-Client und dem NAS identisch zu machen. Anschließend können Sie NFSv4 ohne ID-Zuordnung verwenden oder NFSv3, das nur auf UID und GID basiert.

Ich habe wirklich mit genau dem gleichen Problem zu kämpfen. Ich hatte große Mühe, einen Kerberos-Server mit Docker in der Synology einzurichten, die ID-Zuordnung einzurichten, und das Verhalten gefiel mir immer noch nicht. Kerberos ist viel zu überarbeitet und es ist schwierig, weiterhin an Neustarts und der automatischen Bereitstellung zu arbeiten. Außerdem war die Standard-Umask für neu erstellte Dateien 0000, und jede neue Datei wurde im Modus 777 erstellt, unabhängig von meiner lokalen Umask.

Meine Lösung ähnelte der von suprjami, aber ich ging noch ein bisschen weiter:

• Erstellen Sie einen neuen Benutzer mit der Synology-Web-Benutzeroberfläche und nennen Sie ihn so roger.remote. Machen Sie dasselbe für eine Benutzergruppe und benennen Sie sie genauso wie den Benutzernamen.
• Bearbeiten Sie in der Synology als root / etc / passwd und ändern Sie roger.remotedie UID in 1000 und die GID in 1000
• Bearbeiten Sie / etc / group und ändern Sie die Gruppe ebenfalls roger.remoteauf 1000
• Stellen Sie in der Synology-Web-Benutzeroberfläche squash auf "Alle Benutzer zu verwalten" und speichern Sie
• Bearbeiten Sie als Root erneut / etc / exports und ändern Sie die UID / GID in anonuid=1000,anongid=1000
• Starten Sie NFS neu mit /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• Das ist auch ein bisschen hacky - aber chmod 777 /volume1. Ich hatte viele seltsame Probleme mit meinem gemounteten Homeverzeichnis. KDE konnte nicht gestartet werden, da die glibc- access()Funktion den Zugriff auf das gemountete NFS-Verzeichnis zurückgab. (Aber alle Unterverzeichnisse würden funktionieren) Firefox hatte auch ein ähnliches Problem, bei dem es sich weigerte, Dateien im gemounteten Verzeichnis zu speichern, weil der Zugriff überprüft wurde. Obwohl die Berechtigungen korrekt waren und ich Dateien im bereitgestellten Verzeichnis berühren / erstellen / schreiben konnte. Das Ändern des übergeordneten Verzeichnisses / volume1 in das Verzeichnis world writable hat dieses dumme Problem behoben und die Client-Apps zum Schreiben verleitet.
• Entfernen Sie alle Dateisystem-ACLs von der Freigabe. Durch viele zufällige Experimente habe ich festgestellt, dass diese ACLs Probleme mit der Modusmaske der erstellten Dateien verursachen. Ich bin kein ACL-Master, also gibt es vielleicht eine elegantere Lösung. Tun Sie dies als root auf der Synology synoacltool -del /volume1/myshare. Das +Symbol sollte von der Ausgabe von ls -l entfernt sein.
• Ändern Sie den Besitz der Freigabe in Ihren neuen Benutzer: chown roger.remote:roger.remote /volume1/myshare
• Ändern Sie den Modus auf 755: chmod 755 /volume1/myshare
• Mounten Sie das Volume auf dem Client, testen Sie die Berechtigungen, es sollte funktionieren! Stellen Sie sicher, dass Sie auch eine Datei berühren, und überprüfen Sie, ob Ihre Bash-Umask korrekt angewendet wurde.

$ umask 
0002
$ cd / mnt / myshare
$ touch test
$ ls -l test
-rw-rw-r-- 1 roger roger 0 Okt 21 18:15 test

Auf der Synology sollten Sie sehen:

# ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 Okt 21 18:15 test

Genießen!