Arch Linux

NFS mit mountpoint

DocMAX

Auf meinem NFS-Server wird ein NACHTRÄGLICH gemountetes Verzeichnis auf dem exportierten Pfad nicht auf dem Client angezeigt. Ich muss auf dem Server exportfs -ar ausführen und auf dem Client ein umount und mount durchführen, um den gemounteten Inhalt zu sehen. Ist es möglich, dieses manuelle Eingreifen zu vermeiden?
Bei SMB sieht man es unter Windows z.b. sofort.

server:
/mnt/pve/4bay 192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)
client:
pve.lan:/mnt/pve/4bay on /mnt/pve/4bay type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=60,retrans=2,sec=sys,clientaddr=192.168.1.211,local_lock=none,addr=192.168.1.10)

tuxnix

Habe zwei Links gefunden, die das Problem ganz gut umreißen.

Beispiel mit mount https://wiki.ubuntuusers.de/NFSv4/
Beispiel mit symbolischer Verlinkung https://www.bergercity.de/linux/nfs-symlinks/ (v3 ?)
Beide male sollten die Ordner auf dem Server mit --bind gemountet werden.
Danach müsste der Client das auch ohne erneutes mounten schaffen.

DocMAX

danke, hmm ist auch nicht das gelbe vom ei. überlege ganz von nfs auf sshfs oder so zu wechseln. aber ich glaube nfs hat die beste performance oder?

GerBra

Ist auf deinem NFS-Server der mountd gestartet?
systemctl status nfs-mountd.service

Ich verstehe dich richtig: Du willst ein zusätzliches Dateisystem in den bereits exportierten NFSv4-Pfad(fsid=0) einhängen und dieser Pfad ist (ohne weitere Aktionen) dann nicht sofort für die Clients verfügbar?

Hier funktioniert das problemlos. Ich erzeuge testweise auf dem Server ein neues Dateisystem (ext4, Zugriff über loop-Devices von einer Datei /clocal).

# dd if=/dev/zero of=/clocal bs=1M count=100
# losetup -vf /clocal
# mkfs.ext4 /dev/loop0

Über /dev/loop0 habe ich nun ein rund 100MB großes ext4-Dateisystem. Das mounte ich testweise nach /mnt und kopiere irgendwelche Daten hinein, hier das /boot/grub-Verzeichnis. Dann hänge ich das wieder aus.

# mount /dev/loop0 /mnt/
# cp --recursive /boot/grub/ /mnt/
# umount /mnt

Jetzt hänge ich dieses Dateisystem zusätzlich in meinen NFSv4-exports-Pfad, der Inhalt wird angezeigt:

# mount --mkdir /dev/loop0 /srv/nfs/clocal
# ls /srv/nfs/clocal/
grub  lost+found

Der NFS-Client sieht den neuen Inhalt sofort:

$ ls /mnt/s01/clocal/
grub  lost+found

Allerdings ist mein exportierter Pfad auf dem Server auch kein gemountetes Dateisystem, sondern wird als fsid=0 für NFSv4 eben als NFS-Root exportiert:
/srv/nfs 192.168.166.0/24(rw,sync,crossmnt,fsid=0)
Darin sind dann meine Dateisysteme die ich exportieren möchte eingehängt.

//Edit:
Ich kann dein Problem nachstellen, wenn ich das /dev/loop0-Dateisystem direkt in ein gemountetes Dateisystem einhänge:
# mount --mkdir /dev/loop0 /data/tmp/clocal
Mein NFS-Server exportiert /srv/nfs/tmp als bind-Mount von /data/tmp.
Auf dem Server selbst sehe ich im exportierten /srv/nfs/tmp/clocal alle Daten des ext4-FS.
Auf dem Client erhalte ich aber:

ls /mnt/s01/tmp/clocal 
ls: Öffnen von Verzeichnis '/mnt/s01/tmp/clocal' nicht möglich: Veraltete Dateizugriffsnummer (file handle)

Selbst ein remount des per bind-Mount eingehängten /srv/nfs/tmp genügt nicht. Lediglich ein exportfs -ar (so wie bei dir).

Deshalb würde ich dir raten, für NFSv4 kein eingehängtes Dateisystem direkt zu exportieren wenn du darin zusätzliche Dateisysteme einhängen willst. Sondern löse das per bind-mounts, wie es wohl @tuxnix auch in seinen Links anführte.

Das wäre für dich z.B. ein abändern des NFS-Servers auf z.B. /srv/nfs:
/etc/exports:

/srv/nfs        192.168.1.0/24(rw,async,crossmnt,fsid=0)
/srv/nfs/4bay  192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)

Bind-Mounten deines pve/4bay in den NFSv4-Export-Tree
/etc/fstab:
...
/mnt/pve/4bay /srv/nfs/4bay none bind 0 0
...

Die Clients mounten nun lediglich das NFVv4 Root-Export-Verzeichnis:
/etc/fstab (<nfs_mount_options> NFS-Optionen: entweder deine oder defaults):
pve.lan:/ /mnt/pve nfs4 <nfs_mount_options> 0 0

Jetzt ist es dir möglich:

entweder ein weiteres Dateisystem direkt nach /srv/nfs/foobar zu mounten, es wird direkt von den Clients gesehen
oder dieses ebenfalls erst z.B. unterhalb von /mnt auf dem Server einzuhängen(/mnt/foobar und für NFS dieses ebenfalls per bind-mount in /srv/nfs einzu"binden". Auch das wird von den Clients sofort gesehen.

Alle verwendeten Verzeichnisse müssen natürlich existieren.
Siehe auch:
https://wiki.archlinux.org/title/NFS

//Edit2
Eine weitere Möglichkeit habe ich gerade nochmal getestet, funktioniert hier zumindest mit meinem NFSv4-Setup.
Im obigen //Edit war es mir ja nicht möglich, ein weiteres Dateisystem in einen existierenden Mount einzuhängen welcher per NFS (bei mir als bind-mount) exportiert wird.
Der Client bekam beim Zugriff ja:
Veraltete Dateizugriffsnummer (file handle)
Starte ich auf dem NFS-Server allerdings den Dienst nfsv4-exportd.service, dann klappt das. Der exportd sorgt wohl für eine Aktualisierung der Exporte (analog zu: exportfs -ar)

# systemctl start nfsv4-exportd.service
# mount --mkdir /dev/loop0 /data/tmp/clocal

Ich hänge also /dev/loop0 wieder in einen schon existierenden Mountpoint /data/tmp
Ein Zugriff per NFS-Client ergibt nun keine Fehlermeldung mehr, sondern:

$ ls /mnt/s01/tmp/clocal/
grub  lost+found

Auf dem Server ist im Journal oder per systemctl die Arbeit des nfsv4-exportd zu sehen, z.B.:

Apr 06 11:57:18 s01 systemd[1]: Starting NFSv4 Mount Daemon...
Apr 06 11:57:18 s01 systemd[1]: Started NFSv4 Mount Daemon.
Apr 06 11:57:57 s01 nfsv4.exportd[3701071]: v4.2 client attached: 0x6a2a8a856611100d from "192.168.1.10:947"
Apr 06 12:06:18 s01 nfsv4.exportd[3701071]: v4.2 client detached: 0x6a2a8a856611100d from "192.168.1.10:947"

Siehe auch:
https://man.archlinux.org/man/exportd.8.en
Trotzdem gilt IMHO der Warhinweis in der manpage hierbei:
https://man.archlinux.org/man/exports.5#Subdirectory_Exports