staging.inyokaproject.org

NFS mount funktioniert nicht nach Update auf 20.04

Status: Ungelöst | Ubuntu-Version: Xubuntu 20.04 (Focal Fossa)
Antworten |

speiche

Anmeldungsdatum:
12. Oktober 2009

Beiträge: 60

Hallo, mein Problem paßt nicht wirklich in diese Gruppe (weil eigentlich Server-Dienste) aber ich weiß nicht, wo genau ich es anbringen soll. Nach dem Update auf 20.04 kann ich via NFS nicht mehr mounten.

sudo mount <IP des Server>:/home /mnt/temp

wird auf der Shell einfach nicht ausgeführt, bleibt stehen und es erscheint auch kein Prompt. In /var/log/syslog wird nichts angezeigt. Von einer anderen Maschine kann ich auf dem Server mounten, Fehler am Server kann ausgeschlossen werden. Ich habe nfs-common deinstalliert und nochmals installiert. Wo, in welcher Log kann ich nach Fehler suchen? Was habe ich nach dem Update übersehen?

Danke

Jörg

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9837

speiche schrieb:

[…] Nach dem Update auf 20.04

Hast Du den NFS-Server oder den NFS-Client dem Update unterzogen?

Zeige bitte auf Client und auf dem Server die Ausgabe dieser Befehle hier als Codeblock formatiert:

hostname
hostname -I
lsb_release -ds
dpkg-query --list nfs*

speiche

(Themenstarter)

Anmeldungsdatum:
12. Oktober 2009

Beiträge: 60

Hallo, und Danke für die Unterstützung. Das Update fand auf dem Client statt. Der Server ist ein Gentoo-System. Das sind die Daten zum Client:

hostname
Papa-Lappi

hostname -I
192.168.1.34 2003:e6:3f42:b21b:d90:2e04:76de:e955 2003:e6:3f42:b21b:e419:fd:47bb:9f3b 

lsb_release -ds
Ubuntu 20.04.1 LTS

dpkg-query --list nfs*
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name              Version              Architektur  Beschreibung
+++-=================-====================-============-=============================================
un  nfs-client        <keine>              <keine>      (keine Beschreibung vorhanden)
ii  nfs-common        1:1.3.4-2.5ubuntu3.3 amd64        NFS support files common to client and server
ii  nfs-kernel-server 1:1.3.4-2.5ubuntu3.3 amd64        support for NFS kernel server
un  nfs-server        <keine>              <keine>      (keine Beschreibung vorhanden)

Hier jetzt die Angaben auf dem Server:

hostname
mtpcenter

hostname -i
192.168.1.19

uname -a
Linux mtpcenter 4.9.16-gentoo #12 SMP Wed Mar 13 19:05:05 CET 2019 x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux

eix nfs
[?] net-fs/nfs-utils
     Verfügbare Versionen:   1.3.4-r1^t ~2.1.1-r1^t **2.1.2_rc3^t **2.1.2_rc5^t {caps ipv6 kerberos +libmount nfsdcld +nfsidmap +nfsv4 nfsv41 selinux tcpd +uuid}
     Installierte Versionen: 2.5.1^t(01:45:46 12.09.2020)(ipv6 libmount nfsidmap nfsv4 tcpd uuid -caps -junction -kerberos -ldap -nfsdcld -nfsv41 -selinux KERNEL="linux")
     Startseite:             http://linux-nfs.org/
     Beschreibung:           NFS client and server daemons

Sind die Angabe so okay?

Jörg

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9837

Das sieht soweit richtig aus.

Versuche die Option -v beim mount-Befehl, damit wird die Ausgabe etwas ausführlicher:

sudo mount -v 192.168.1.34:/home /mnt/temp 

/mnt/temp existiert?

Suche im Systemlog nach Meldungen:

journalctl -b -p 7 | grep mount 

speiche

(Themenstarter)

Anmeldungsdatum:
12. Oktober 2009

Beiträge: 60

/mnt/temp existiert? –> ja

Das Problem wird konkreter.

sudo mount -v 192.168.1.34:/home /mnt/temp   --> funktioniert

mount 
...
192.168.1.19:/home on /mnt/temp type nfs4 (rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.34,local_lock=none,addr=192.168.1.19)

Aber wenn ich

sudo mount -v 192.168.1.34:/ext /mnt/temp

sudo mount -v 192.168.1.34:/ext /mnt/temp
mount.nfs: timeout set for Sun Oct  4 17:22:08 2020
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.19,clientaddr=192.168.1.34'

dann bleibt er hängen.

journalctl -b -p 7|grep mount

Okt 04 16:53:23 Papa-Lappi sudo[9811]:    joerg : TTY=pts/0 ; PWD=/home/joerg ; USER=root ; COMMAND=/bin/mount -v 192.168.1.19:/ext /mnt/temp
Okt 04 17:02:16 Papa-Lappi sudo[9987]:    joerg : TTY=pts/0 ; PWD=/home/joerg ; USER=root ; COMMAND=/bin/mount -v 192.168.1.19:/ext /mnt/temp

Hier noch die /etc/exports vom NFS-Server:

# /etc/exports: NFS file systems being exported.  See exports(5).
/home 192.168.1.0/24(rw,sync)
/ext 192.168.1.0/24(rw,sync)
/backup 192.168.1.0/24(rw,sync)
/ext/tvaufnahmen 192.168.1.0/24(rw,sync)

/ext ist eine separate HD mit über 400 GB Daten (Filme + Musik)

Hier noch die Einstellungen der Rechte auf dem Server:

drwxrwxrwx  17 root   root    4096 30. Dez 2016  ext
drwxr-xr-x   4 root   root    4096 20. Dez 2016  home

VG

Jörg

BillMaier Team-Icon

Supporter

Anmeldungsdatum:
4. Dezember 2008

Beiträge: 6497

Hallo,

irgendwie erkenne ich da einen Mischmasch von verschiedenen NFS-Versionen. Version 2/3 und Version 4 sollten nicht gemischt werden.

Mit Version 4 am Server muss ein Pseudodateisystem definiert werden, siehe NFSv4 (Abschnitt „Freigaben“) . Sollte das alles NFSv3 sein, so sollte beim mounten die Version 3 vers=3 angegeben werden. Ubuntu 20.04 verwendet standardmäßig eben jetzt Version 4.2

Kleiner Gegentest: Ich gehe auch davon aus, dass im aktuellen Setup (mit dem Versionsmischmasch) jeweils eine Freigabe eingehängt werden kann. Nämlich immer die erste. Wenn du also zuerst 192.168.1.34:/ext einhängst, lässt sich danach 192.168.1.34:/home nicht mehr einhängen.

Vermute ich da richtig?

Gruß BillMaier

Antworten |