[GELÖST] NFS4-Mount schlägt fehl

[Njuguna]

Hallo,

ich bekomme diese Fehlermeldung beim NFS4-Mount:

Code: Alles auswählen

mount -t nfs 192.168.1.250:/home/systembackup/Backups/MailServer/DovecotVmail /var/reoback/backups/dovecotMailBackup
mount.nfs: mounting 192.168.1.250:/home/systembackup/Backups/MailServer/DovecotVmail failed, reason given by server: No such file or directory

Code: Alles auswählen

mount -t nfs 192.168.1.250:/home/systembackup/mx-vmail_backup_hourly /mnt
mount.nfs: mounting 192.168.1.250:/home/systembackup/mx-vmail_backup_hourly failed, reason given by server: No such file or directory

Betriebssystem auf allen Servern ist Debian 12. Und die /etc/exports sieht so aus:

Code: Alles auswählen

/home/systembackup/Backups/                     192.168.1.0/24(ro,sync,insecure,no_subtree_check,no_root_squash,fsid=0)

/home/systembackup/Backups/MailServer/Postfix   192.168.1.71(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/MailServer/DovecotVmail  192.168.1.71(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/mx-vmail_backup             192.168.1.71(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/mx-vmail_backup_hourly      192.168.1.71(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/ApacheServer         192.168.1.75(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/BindServer           192.168.1.84(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/Bind-Slave-Server    192.168.1.85(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/BigBlueButtonServer  192.168.1.80(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/X2GOServer           192.168.1.79(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/Icinga2Server        192.168.1.72(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups/Rootserver-neckar1   192.168.1.250(rw,sync,no_subtree_check,async,no_root_squash)
/home/systembackup/Backups2/VM-Backups          192.168.1.250(rw,sync,no_subtree_check,async,no_root_squash)

Alle Ip-Adressen bis auf 192.168.1.71 können eine NFS4-Mount herstellen. Ich sehe auch keine Berechtigungsprobleme bei den Verzeichnisse auf dem NFS-Server und alle Verzeichnisse existieren auch auf 192.168.1.71.

Was kann diese Fehlermeldung noch bedeuten?

Grüße
Njuguna

[schwedenmann]

Hallo


Auf dem PC 192.168.1.71 würde ich folgendes macvhen
aus
/home/systembackup/mx-vmail_backup

würde ich
/home/systembackup/Backup/mx-vmail_backup

Also auf PC das Verzeichnis umbenennen und auch in der exports den Pfad anpassen


mfg
schwedenmann

[Njuguna]

Hallo schwedenmann,
vielen für den Tipp. Nur so richtig erschließt er sich mir nicht. Denn die exports auf dem NFS-Server bestimmt doch bereits welcher Host auf welche lokale Ressource des NFS-Servers mounten darf. Da steht nichts drin, an welchem Mountpoint die Freigabe explizit gebunden werden muß. Also ist es doch total unerheblich, ob auf dem nfs-Client der Mount-Point "/mnt" oder "/var/reoback/backups/postfix" heißt.
Ausserdem liegen auf allen nfs-Clients an gleicher Stelle ""/var/reoback/backups/.." die Mount-Points, damit das Backup-Tool auf allem ein nahezu einheitliches Konzept hat. Ich habe trotzdem testweise auf dem Client

Code: Alles auswählen

mkdir -p /home/systembackup/Backup/mx-vmail_backup

ausgeführt und versucht dorthin zu verbinden. Geht genauso wenig.

Ich vermisse auch bei NFS die Logfiles. Wo schaue ich da genau rein, um zu sehen, warum die Verbindung nicht klappt?

[TRex]

Fehler sollten im Kernel-Log auftauchen, denke ich. Ich weiß gerade nicht sicher, wo (=in welcher unit) systemd die aufbewahrt, aber dmesg sollte für deinen Zweck ja genügen.

@schwedenmann: das klingt etwas wirr, was du da schreibst - die Verzeichnisse existieren nicht auf dem Client, sondern auf dem Server, und die von dir angesprochene Inkonsistenz in den exports kann auch nicht die Ursache sein, da ein anderer export den gleichen Fehler hat.

[Njuguna]

Fehler sollten im Kernel-Log auftauchen, denke ich. Ich weiß gerade nicht sicher, wo (=in welcher unit) systemd die aufbewahrt, aber dmesg sollte für deinen Zweck ja genügen.

Ich bin, was das Logging betrifft, fündig geworden in https://kerneltalks.com/config/nfs-logs-in-linux/. So loggt er auf dem NFS-Server ins Syslog.
Ich sehe nur noch nichts, was mich weiterbringt. Die anderen Export hat er im Log angezeigt, dass die sich verbunden hatten.

[TRex]

Hast du die dort erwähnten debugging-Optionen mal ausprobiert (ist Neuland für mich, sieht aber vernünftig aus dort)?

Und du meintest zwar, dass auf allen Servern Debian 12 ist, aber sind die auch auf dem gleichen Patch-Stand (inkl. reboot, damit der gleiche Kernel aktiv ist)?

[Njuguna]

Hast du die dort erwähnten debugging-Optionen mal ausprobiert (ist Neuland für mich, sieht aber vernünftig aus dort)?

Das ist es für mich auch. Aber wie gesagt, er schreibt dann ins Syslog.

Und du meintest zwar, dass auf allen Servern Debian 12 ist, aber sind die auch auf dem gleichen Patch-Stand (inkl. reboot, damit der gleiche Kernel aktiv ist)?

Am Neuesten ist der Mailserver. Da müsste ich mal step-by-step die Maschinen upgraden.

[TRex]

Das ist es für mich auch. Aber wie gesagt, er schreibt dann ins Syslog.

Und taucht da was entsprechendes auf, wenn du den fehlerhaften Client verbinden willst? Und...

Am Neuesten ist der Mailserver. Da müsste ich mal step-by-step die Maschinen upgraden.

Ja okay Das könntest du tun, aber gibt es einen (exklusiven) Unterschied zwischen der fehlerhaften Maschine und den anderen? Insbesondere wenn die gerade ein Kernel-Update hatte und noch nicht rebooted wurde, wäre ein fehlerhafter NFS-mount nicht überraschend.

[Njuguna]

Ich habe zunächst den NFS-Server geupgradet. Der Kernel hier hat die Version

Code: Alles auswählen

uname -r
6.8.4-2-pve

Da läuft ein Promox-Kernel.
Alle anderen Maschinen haben Debian-Kernel zum Beispiel mx1 und monitoring beide

Code: Alles auswählen

uname -r
6.1.0-18-amd64

Während sich jetzt monitoring das bereitgestellte NFS-Share mounten kann - allerdings nicht mit "-t nfs4" sondern "-t nfs", bleibt mx1 noch störisch. mx1 verbindet sich weder mit "nfs" noch mit "nfs4".
Im Syslog vom NFS-Server steht dann

Code: Alles auswählen

2024-04-26T17:01:16.155144+02:00 neckar2 kernel: [  988.997100] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:16.155162+02:00 neckar2 kernel: [  988.997112] nfsd4_sequence: slotid 0
2024-04-26T17:01:16.155164+02:00 neckar2 kernel: [  988.997116] check_slot_seqid enter. seqid 139 slot_seqid 138
2024-04-26T17:01:16.155164+02:00 neckar2 kernel: [  988.997147] --> nfsd4_store_cache_entry slot 00000000c891b2d4
2024-04-26T17:01:16.165131+02:00 neckar2 kernel: [  989.007078] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:16.165140+02:00 neckar2 kernel: [  989.007086] nfsd4_sequence: slotid 0
2024-04-26T17:01:16.165142+02:00 neckar2 kernel: [  989.007089] check_slot_seqid enter. seqid 140 slot_seqid 139
2024-04-26T17:01:16.165143+02:00 neckar2 kernel: [  989.007109] --> nfsd4_store_cache_entry slot 00000000c891b2d4
2024-04-26T17:01:16.168130+02:00 neckar2 kernel: [  989.010155] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:16.168138+02:00 neckar2 kernel: [  989.010163] nfsd4_sequence: slotid 0
2024-04-26T17:01:16.168140+02:00 neckar2 kernel: [  989.010166] check_slot_seqid enter. seqid 141 slot_seqid 140
2024-04-26T17:01:16.168142+02:00 neckar2 kernel: [  989.010180] --> nfsd4_store_cache_entry slot 00000000c891b2d4
2024-04-26T17:01:19.077133+02:00 neckar2 kernel: [  991.918724] __find_in_sessionid_hashtbl: 1714142844:2306809138:6:0
2024-04-26T17:01:19.077142+02:00 neckar2 kernel: [  991.918733] nfsd4_sequence: slotid 0
2024-04-26T17:01:19.077144+02:00 neckar2 kernel: [  991.918735] check_slot_seqid enter. seqid 44 slot_seqid 43
2024-04-26T17:01:19.077145+02:00 neckar2 kernel: [  991.918758] --> nfsd4_store_cache_entry slot 0000000060e1b0ef
2024-04-26T17:01:22.996140+02:00 neckar2 kernel: [  995.837636] __find_in_sessionid_hashtbl: 1714142844:2306809140:8:0
2024-04-26T17:01:22.996153+02:00 neckar2 kernel: [  995.837649] nfsd4_sequence: slotid 0
2024-04-26T17:01:22.996154+02:00 neckar2 kernel: [  995.837653] check_slot_seqid enter. seqid 16 slot_seqid 15
2024-02024-04-26T17:01:16.155144+02:00 neckar2 kernel: [  988.997100] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:16.155162+02:00 neckar2 kernel: [  988.997112] nfsd4_sequence: slotid 0
2024-04-26T17:01:16.155164+02:00 neckar2 kernel: [  988.997116] check_slot_seqid enter. seqid 139 slot_seqid 138
2024-04-26T17:01:16.155164+02:00 neckar2 kernel: [  988.997147] --> nfsd4_store_cache_entry slot 00000000c891b2d4
2024-04-26T17:01:16.165131+02:00 neckar2 kernel: [  989.007078] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:16.165140+02:00 neckar2 kernel: [  989.007086] nfsd4_sequence: slotid 0
2024-04-26T17:01:16.165142+02:00 neckar2 kernel: [  989.007089] check_slot_seqid enter. seqid 140 slot_seqid 139
2024-04-26T17:01:16.165143+02:00 neckar2 kernel: [  989.007109] --> nfsd4_store_cache_entry slot 00000000c891b2d4
2024-04-26T17:01:16.168130+02:00 neckar2 kernel: [  989.010155] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:16.168138+02:00 neckar2 kernel: [  989.010163] nfsd4_sequence: slotid 0
2024-04-26T17:01:16.168140+02:00 neckar2 kernel: [  989.010166] check_slot_seqid enter. seqid 141 slot_seqid 140
2024-04-26T17:01:16.168142+02:00 neckar2 kernel: [  989.010180] --> nfsd4_store_cache_entry slot 00000000c891b2d4
2024-04-26T17:01:19.077133+02:00 neckar2 kernel: [  991.918724] __find_in_sessionid_hashtbl: 1714142844:2306809138:6:0
2024-04-26T17:01:19.077142+02:00 neckar2 kernel: [  991.918733] nfsd4_sequence: slotid 0
2024-04-26T17:01:19.077144+02:00 neckar2 kernel: [  991.918735] check_slot_seqid enter. seqid 44 slot_seqid 43
2024-04-26T17:01:19.077145+02:00 neckar2 kernel: [  991.918758] --> nfsd4_store_cache_entry slot 0000000060e1b0ef
2024-04-26T17:01:22.996140+02:00 neckar2 kernel: [  995.837636] __find_in_sessionid_hashtbl: 1714142844:2306809140:8:0
2024-04-26T17:01:22.996153+02:00 neckar2 kernel: [  995.837649] nfsd4_sequence: slotid 0
2024-04-26T17:01:22.996154+02:00 neckar2 kernel: [  995.837653] check_slot_seqid enter. seqid 16 slot_seqid 15
2024-04-26T17:01:22.996155+02:00 neckar2 kernel: [  995.837686] --> nfsd4_store_cache_entry slot 00000000aa4efc3f
2024-04-26T17:01:26.284134+02:00 neckar2 kernel: [  999.126240] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:26.284144+02:00 neckar2 kernel: [  999.126250] nfsd4_sequence: slotid 0
2024-04-26T17:01:26.284146+02:00 neckar2 kernel: [  999.126253] check_slot_seqid enter. seqid 142 slot_seqid 141
2024-04-26T17:01:26.284147+02:00 neckar2 kernel: [  999.126273] --> nfsd4_store_cache_entry slot 00000000c891b2d44-26T17:01:22.996155+02:00 neckar2 kernel: [  995.837686] --> nfsd4_store_cache_entry slot 00000000aa4efc3f
2024-04-26T17:01:26.284134+02:00 neckar2 kernel: [  999.126240] __find_in_sessionid_hashtbl: 1714142844:2306809137:5:0
2024-04-26T17:01:26.284144+02:00 neckar2 kernel: [  999.126250] nfsd4_sequence: slotid 0
2024-04-26T17:01:26.284146+02:00 neckar2 kernel: [  999.126253] check_slot_seqid enter. seqid 142 slot_seqid 141
2024-04-26T17:01:26.284147+02:00 neckar2 kernel: [  999.126273] --> nfsd4_store_cache_entry slot 00000000c891b2d4

Also am Kernel scheint es nicht unbedingt zu liegen, sonst hätten alle (u.A. ein Ubuntu 18, 4.15.0-213-generic) auch Probleme.
Nur zwei, also insgesamt drei haben das gleiche Problem.

[TRex]

Nachdem ich jetzt nochmal deinen Fehler ergooglet hab, hab ich ein neues Bild. Migrierst du gerade zu nfs4? Weil das, was fsid=0 hat, das root-dir sein sollte, von dem aus du relative Pfade angeben musst. Mich hat deine Aussage stutzig gemacht, dass es an einem Client mit nfs3 geht, aber nfs4 nicht... und jetzt ergibt das Sinn.

Für nfs4 müsstest du deine Mounts wie folgt bauen:

mount -t nfs 192.168.1.250:/MailServer/DovecotVmail /var/reoback/backups/dovecotMailBackup

weil fsid 0 in /home/systembackup/Backups/ liegt.

Und schwedenmanns Stilkorrektur wird dann zur Notwendigkeit (alles unterhalb dieses Verzeichnisses zu haben).

Allerdings sollte es mit nfs3 ohne diese Anpassung funktionieren. Dazu hätte ich nur die Vermutung, dass du in deiner /etc/fstab (nfs)vers=4 stehen hast und deswegen auch dein scheinbar manueller mount mit -t nfs nfs4 verwenden könnte... Ansonsten bin ich jetzt raus, da ich mich mit nfs4 nicht weiter beschäftigt habe und mir fürs explorative Vorgehen Infos fehlen.

[Njuguna]

Für nfs4 müsstest du deine Mounts wie folgt bauen:

mount -t nfs 192.168.1.250:/MailServer/DovecotVmail /var/reoback/backups/dovecotMailBackup

weil fsid 0 in /home/systembackup/Backups/ liegt.

Du hast Recht. Jetzt klappt es. Dann war das mein Fehler, weil ich was im entsprechenden Text, aus dem ich die Infos hatte, falsch verstanden/gelesen hatte.
Vielen Dank für Deine Hilfe.

Ein schönes Wochenende,

Njuguna