Dieses Problem macht mich im Moment im Grunde wahnsinnig. Ich habe einen Ubuntu 16.04 NFS-Server, der mit dieser Konfiguration einwandfrei funktionierte:
/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98 /data2 xfs rw,relatime 0 0
/data2 /srv/nfs/cryodata none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
Und
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Dies hat bisher auf dem einen NFS-Client mit dieser Konfiguration monatelang problemlos funktioniert und die folgenden /etc/fstab-Einträge auf der Clientseite verwendet:
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
Da es sich jedoch um einen sehr großen Speicherserver handelt, wurde entschieden, dass er mehrere Labore aufnehmen muss. Also habe ich alle Sachen, die über die /data2-Partition verstreut waren, in ein /data2/cryodata-Unterverzeichnis verschoben und /etc/fstab auf dem Server und /etc/exports wie folgt aktualisiert:
/etc/fstab:
...
/data2/cryodata /srv/nfs/cryodata none defaults,bind 0 0
/data2/xray /srv/nfs/xray none defaults,bind 0 0
/data2/EM /srv/nfs/EM none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
Und
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Das funktioniert einfach nicht! Wenn ich versuche, das neue Mount auf dem Client mit demselben Client-/etc/fstab-Eintrag zu mounten:
{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
.
# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...
/usr/local wird weiterhin ohne Probleme gemountet. Als ich das das erste Mal versuchte, vergaß ich, die verwendeten Dateisysteme exportfs -varvor dem Vornehmen von Änderungen zu de-exportieren/exportieren, aber seitdem wechsele ich hin und her und achte darauf, alles zu de-exportieren und zu de-mounten, mit mehreren Serverneustarts dazwischen. Das ursprüngliche Mounten eines Bind-Mounts der gesamten Partition funktioniert immer, und das Bind-Mounten eines Unterverzeichnisses schlägt jedes Mal mit der Meldung „Veralteter NFS-Handle“ fehl. Ich habe versucht, andere NFS-Clients zu aktivieren, die diese Partitionen nie gemountet haben, und bekomme genau dieselbe Fehlermeldung: In diesem Fall handelt es sich definitiv um ein Serverproblem. Ich habe /var/lib/nfs/etab überprüft, um sicherzustellen, dass es zwischen Mount-Versuchen usw. gelöscht wird.
Ich dachte, die Technik des Bind-Mountens in ein NFS-Server-Stammverzeichnis würde all diese Probleme lösen, aber anscheinend nicht? Das Seltsame ist, dass /usr/local ein Unterverzeichnis einer anderen Partition ist und immer problemlos gemountet wird. Es befindet sich auf einem ext3 MD RAID 1, obwohl ich mir nicht vorstellen kann, dass das eine Rolle spielt.
Ich habe Stunden damit verbracht und Google beinahe kaputt gemacht, als ich vergeblich nach einer Lösung gesucht habe.
Antwort1
Beachten Sie, dass ich nur bindgemountete Dateisysteme exportiere. Dieser Abschnitt aus demExporteManpage ist relevant:
fsid=Nummer|Stamm|UUID
NFS muss in der Lage sein, jedes Dateisystem zu identifizieren, das es exportiert. Normalerweise wird eine UUID für das Dateisystem verwendet (falls das Dateisystem eine solche hat) oder die Gerätenummer des Geräts, auf dem sich das Dateisystem befindet (falls das Dateisystem auf dem Gerät gespeichert ist).
Meine falsche Annahme war, dass bind-gemountete Dateisysteme eine Art UUID haben, die NFS automatisch verwenden kann. Diese Annahme wurde durch die Tatsache bekräftigt, dass diese beiden bind-gemounteten Exporte ohne eine FUID einwandfrei funktionierten:
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Dies führt jedoch zu inkonsistentem Verhalten. Ich habe ein Bind-Mounted /opt hinzugefügt:
/etc/fstab:
/data1/opt /srv/nfs/opt none defaults,bind 0 0
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,no_subtree_check)
führte zu inkonsistentem Verhalten; d. h. ich konnte die Export-IP ändern und auf einem Rechner mounten, aber auf einem anderen Rechner wurde die Berechtigung verweigert. Die Lösung bestand darin, eine Fsid hinzuzufügen:
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,fsid=20,no_subtree_check)
Die Lösung besteht also darin, zum Exportieren von Bind-gemounteten Dateisystemen immer eine FID hinzuzufügen.