NFS mounten: Besitzer sind nobody:nogroup

Question 1

Nach lokalem Support oder Dokumentation zu fragen, klingt nach einer sehr guten Idee :).

In Form einer Checkliste, denke ich, brauchen Sie

1) die erforderlichen Benutzer, die auf dem Clientsystem erstellt wurden. Dies kann manuell erfolgen, Sie sollten jedoch davon ausgehen, dass es einen automatischen „Verzeichnisdienst“ gibt, den Sie konfigurieren können. Dies könnte LDAP sein.

2) Benutzerzuordnung zwischen Client und Server. In NFS4~~(impliziert durch TCP-Option)~~Dies wird von idmapd gehandhabt, wie von Gareth erwähnt. Sie müssen die Domäne nur so einstellen, dass sie mit dem übereinstimmt, was der Server denkt. Domänenübergreifend funktioniert nicht, ich denke, das ist eine Linux-Einschränkung.

3) Kerberos zur Authentifizierung gegenüber dem Server (verfügbar in NFS4). Wenn Sie als jemand anderes als „niemand“ auf Dateien zugreifen möchten, ist dies unbedingt erforderlich. Ich schlage vor, Kerberos zunächst zu konfigurieren und zu testen. Zur Konfiguration gehört das Festlegen einer Domäne – Sie legen dieselbe Domäne in idmapd.conf fest.

oder bei der Authentifizierung im NFS3-Stil wird 3) übersprungen und statt 2) stellen Sie einfach sicher, dass die numerische UID des Benutzers mit der des Servers übereinstimmt. Dies wird nur verwendet, wenn der Server dem Client vertraut :).

Answer

Nach lokalem Support oder Dokumentation zu fragen, klingt nach einer sehr guten Idee :).

In Form einer Checkliste, denke ich, brauchen Sie

1) die erforderlichen Benutzer, die auf dem Clientsystem erstellt wurden. Dies kann manuell erfolgen, Sie sollten jedoch davon ausgehen, dass es einen automatischen „Verzeichnisdienst“ gibt, den Sie konfigurieren können. Dies könnte LDAP sein.

2) Benutzerzuordnung zwischen Client und Server. In NFS4~~(impliziert durch TCP-Option)~~Dies wird von idmapd gehandhabt, wie von Gareth erwähnt. Sie müssen die Domäne nur so einstellen, dass sie mit dem übereinstimmt, was der Server denkt. Domänenübergreifend funktioniert nicht, ich denke, das ist eine Linux-Einschränkung.

3) Kerberos zur Authentifizierung gegenüber dem Server (verfügbar in NFS4). Wenn Sie als jemand anderes als „niemand“ auf Dateien zugreifen möchten, ist dies unbedingt erforderlich. Ich schlage vor, Kerberos zunächst zu konfigurieren und zu testen. Zur Konfiguration gehört das Festlegen einer Domäne – Sie legen dieselbe Domäne in idmapd.conf fest.

oder bei der Authentifizierung im NFS3-Stil wird 3) übersprungen und statt 2) stellen Sie einfach sicher, dass die numerische UID des Benutzers mit der des Servers übereinstimmt. Dies wird nur verwendet, wenn der Server dem Client vertraut :).

Question 2

Ich bin einem ähnlichen Problem auf die Spur gekommen. Durch die Einstellung von /etc/idmapd.conf Verbosity=3 konnte ich einige der Probleme unter Ubuntu erkennen, aber nicht alle. Hier ist eine Zusammenfassung meiner Ergebnisse:

Es besteht immer noch die Möglichkeit, dass Ihre /etc/passwd- und Gruppendateien nicht dieselben Benutzer/Gruppen verwenden wie die Maschine, die die Freigabe anbietet. Hier ein Hinweis: Ihre lokale Maschine muss eine ähnliche Benutzer-/Gruppennamenzuordnung über /etc/nsswitch.conf haben, sonst schlägt die Zuordnungsoperation von idmapd fehl. Beachten Sie, dass Sie bei Ausführung von Verbosity=3 einen Eintrag in /var/log/syslog sehen werden, wie:

idmapd[25193]: Client 64: (Gruppen-)Name "DerErwarteteGruppenname" -> ID "65534

Wenn Sie /etc/nsswitch.conf ändern, um etwas anderes als Dateien (wie ldap oder nis) zuzuordnen, müssen Sie auch sicherstellen, dass ldap oder nis tatsächlich einen Eintrag irgendeiner Art für den Benutzernamen oder Gruppennamen haben, für den Sie eine ID-Übersetzung wünschen. Wenn ein Eintrag nicht vorhanden ist, kann idmapd Benutzer/Gruppen nicht erfolgreich zuordnen.

In verwandten Problemen, die ich für RHEL v7 gefunden habe, muss der Dienst idmapd.conf für NFS-Clients nicht mehr aktiviert werden:

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

Im obigen Thread gibt es jedoch ein laufendes Problem, da die Dienste, die die automatische ID-Benutzernamen-Zuordnung durchführen, standardmäßig nur eine sehr geringe Anzahl von IDs haben, die im Speicher zugeordnet bleiben. Anstatt einen Fehler zu protokollieren, weigert sich idmapd einfach, mehr als 200 Benutzer zu übersetzen. Sie können dies anhand Ihrer aktuellen Kerneleinstellungen überprüfen:

cat /proc/sys/kernel/keys/root_maxkeys

Höchstwahrscheinlich ist 200 die Standardeinstellung. Damit die NFS-Einhängepunkte alle verfügbaren Benutzer richtig zuordnen können, müssen Sie diese Datei ändern:

/etc/sysctl.conf

und fügen Sie diese Zeilen wie folgt hinzu oder ändern Sie sie:

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

Ihr System benötigt möglicherweise nicht so viele Benutzer-/ID-Schlüsselzuordnungen, passen Sie sie also nach Bedarf an. Dadurch können alle ID-Name-Schlüssel bei Verwendung der NFS-Einbindung zugeordnet bleiben. Hier ist ein weiterer verwandter Beitrag, der die aktuellen Kerneleinstellungen zeigt:

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

für diese Werte:

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

Höchstwahrscheinlich müssen maxbytes und root_maxbytes groß genug sein, um alle Schlüssel zu speichern:

https://www.kernel.org/doc/Documentation/security/keys.txt

Answer