Liebe Liste,
mit den aktuellen Updates von Tumbleweed ist für mich ein Problem mit nfs-Mounts entstanden.
Ich habe einen Client, der per autofs Verzeichnisse von einem Server mounted. Schon seit Jahren. Mit tumbleweed 20200128 hat noch alles funktioniert. Nach meiner Erinnerung ist spätestens seit 20200205 das Mounten fehlgeschlagen. Auch das aktuelle 20200207 hilft nicht.
(Ich habe auf die Version 20200128 zurück downgegradet. Dann funktioniert mount.nfs wieder, aber thunderbird packt die Daten für eine neuere Version nicht mehr an :-).)
Im Nachbarbüro greift ein Leap 15.0 auf den Mount zu, ohne Probleme.
Beim Bericht über bisherige Aktivitäten zur Fehlersuche setze ich mal DIR, SERVER und CLIENT als Platzhalter ein. CLIENTNET ist fast meine IP, nur die letzte Ziffer ist eine 0. Ich nehme mal an, dass man so ein /24 Subnetz angeben kann:
showmount -e SERVER Export list for os.lsdf.kit.edu: /DIR/EXP CLIENTNET,... /DIR/work CLIENTNET,...
rpcinfo -p SERVER | egrep "service|nfs" program vers proto port service 100003 3 udp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 udp 2049 nfs 100003 4 tcp 2049 nfs
Ein einfaches
mount -vt nfs CLIENT:/DIR/EXP /mnt
liefert:
mount.nfs: timeout set for Tue Feb 11 11:26:17 2020 mount.nfs: trying text-based options 'vers=4.2,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): No such file or directory mount.nfs: trying text-based options 'addr=SERVER' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying SERVER prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying SERVER prog 100005 vers 3 prot UDP port 38013 mount.nfs: Protocol not supported
Also schaue ich mir an, welche Optionen bei einem Leap-System effektiv sind:
ro,noexec,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=SERVER,mountvers=3,mountport=38013,mountproto=udp,local_lock=all,addr=SERVER
Und wenn ich die alle mit angebe, bekomme ich ein "Failed to find 'tcp' protocol".
Das kann ich mit proto=tcp6 ebenso erreichen (wobei ich dann alle addr-Angaben auch lösche, weil ip4-Adressen dann bestimmt nicht helfen). Und ganz ohne proto= Option fehlt im UDP.
Wie gesagt: Auf Leap 15.0 tut es, mit tubleweed 20200128 hat es auch noch getan.
Wer weiß Rat?
Gruß Jan
Am 11.02.20 um 11:30 schrieb Handwerker, Jan (IMK):
Liebe Liste,
mit den aktuellen Updates von Tumbleweed ist für mich ein Problem mit nfs-Mounts entstanden.
Ich habe einen Client, der per autofs Verzeichnisse von einem Server mounted. Schon seit Jahren. Mit tumbleweed 20200128 hat noch alles funktioniert. Nach meiner Erinnerung ist spätestens seit 20200205 das Mounten fehlgeschlagen. Auch das aktuelle 20200207 hilft nicht.
(Ich habe auf die Version 20200128 zurück downgegradet. Dann funktioniert mount.nfs wieder, aber thunderbird packt die Daten für eine neuere Version nicht mehr an :-).)
Im Nachbarbüro greift ein Leap 15.0 auf den Mount zu, ohne Probleme.
Beim Bericht über bisherige Aktivitäten zur Fehlersuche setze ich mal DIR, SERVER und CLIENT als Platzhalter ein. CLIENTNET ist fast meine IP, nur die letzte Ziffer ist eine 0. Ich nehme mal an, dass man so ein /24 Subnetz angeben kann:
showmount -e SERVER Export list for os.lsdf.kit.edu: /DIR/EXP CLIENTNET,... /DIR/work CLIENTNET,...
rpcinfo -p SERVER | egrep "service|nfs" program vers proto port service 100003 3 udp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 udp 2049 nfs 100003 4 tcp 2049 nfs
Ein einfaches
mount -vt nfs CLIENT:/DIR/EXP /mnt
liefert:
mount.nfs: timeout set for Tue Feb 11 11:26:17 2020 mount.nfs: trying text-based options 'vers=4.2,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): No such file or directory mount.nfs: trying text-based options 'addr=SERVER' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying SERVER prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying SERVER prog 100005 vers 3 prot UDP port 38013 mount.nfs: Protocol not supported
Also schaue ich mir an, welche Optionen bei einem Leap-System effektiv sind:
ro,noexec,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=SERVER,mountvers=3,mountport=38013,mountproto=udp,local_lock=all,addr=SERVER
Und wenn ich die alle mit angebe, bekomme ich ein "Failed to find 'tcp' protocol".
Das kann ich mit proto=tcp6 ebenso erreichen (wobei ich dann alle addr-Angaben auch lösche, weil ip4-Adressen dann bestimmt nicht helfen). Und ganz ohne proto= Option fehlt im UDP.
Wie gesagt: Auf Leap 15.0 tut es, mit tubleweed 20200128 hat es auch noch getan.
Wer weiß Rat?
Gruß Jan
Klingt nach dem "Files wurden von /etc/ nach /usr/etc verschoben" - Problem. Das ging auf den englischen Listen rauf und runter ... TL;DR: Schau mal nach /etc/nsswitch.conf.rpmnew und merge das nach /etc/nsswitch.conf.
Gruß, Hendrik
Lieber Hendrik, liebe Liste,
Am 11.02.20 um 17:48 schrieb Hendrik Woltersdorf:
Am 11.02.20 um 11:30 schrieb Handwerker, Jan (IMK):
mit den aktuellen Updates von Tumbleweed ist für mich ein Problem mit nfs-Mounts entstanden.
Ich habe einen Client, der per autofs Verzeichnisse von einem Server mounted. Schon seit Jahren. Mit tumbleweed 20200128 hat noch alles funktioniert. Nach meiner Erinnerung ist spätestens seit 20200205 das Mounten fehlgeschlagen. Auch das aktuelle 20200207 hilft nicht.
Klingt nach dem "Files wurden von /etc/ nach /usr/etc verschoben" - Problem. Das ging auf den englischen Listen rauf und runter ... TL;DR: Schau mal nach /etc/nsswitch.conf.rpmnew und merge das nach /etc/nsswitch.conf.
ehrlich gesagt, habe ich dem keine Chance eingeräumt, denn ich habe keine Schwierigkeiten mit der Namensauflösung erkannt. Aber nachdem ich nsswitch.conf.rpmnew als Ersatz für nsswitch.conf verwendet habe (und network uns autofs neu gestartet habe, ob das nötig war, weiß ich nicht), funktioniert das Mounten wieder wie vorher.
Vielen Dank! Mein Problem ist gelöst.
Herzliche Grüße Jan
Hallo Jan, Am Dienstag, 11. Februar 2020, 11:30:04 CET schrieb Handwerker, Jan (IMK):
Liebe Liste,
mit den aktuellen Updates von Tumbleweed ist für mich ein Problem mit nfs-Mounts entstanden.
Ich habe einen Client, der per autofs Verzeichnisse von einem Server mounted. Schon seit Jahren. Mit tumbleweed 20200128 hat noch alles funktioniert. Nach meiner Erinnerung ist spätestens seit 20200205 das Mounten fehlgeschlagen. Auch das aktuelle 20200207 hilft nicht.
(Ich habe auf die Version 20200128 zurück downgegradet. Dann funktioniert mount.nfs wieder, aber thunderbird packt die Daten für eine neuere Version nicht mehr an :-).)
Im Nachbarbüro greift ein Leap 15.0 auf den Mount zu, ohne Probleme.
Beim Bericht über bisherige Aktivitäten zur Fehlersuche setze ich mal DIR, SERVER und CLIENT als Platzhalter ein. CLIENTNET ist fast meine IP, nur die letzte Ziffer ist eine 0. Ich nehme mal an, dass man so ein /24 Subnetz angeben kann:
showmount -e SERVER Export list for os.lsdf.kit.edu: /DIR/EXP CLIENTNET,... /DIR/work CLIENTNET,...
rpcinfo -p SERVER | egrep "service|nfs" program vers proto port service 100003 3 udp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 udp 2049 nfs 100003 4 tcp 2049 nfs
Ein einfaches
mount -vt nfs CLIENT:/DIR/EXP /mnt
liefert:
mount.nfs: timeout set for Tue Feb 11 11:26:17 2020 mount.nfs: trying text-based options 'vers=4.2,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,addr=SERVER,clientaddr=CLIENT' mount.nfs: mount(2): No such file or directory mount.nfs: trying text-based options 'addr=SERVER' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying SERVER prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying SERVER prog 100005 vers 3 prot UDP port 38013 mount.nfs: Protocol not supported
Also schaue ich mir an, welche Optionen bei einem Leap-System effektiv sind:
ro,noexec,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock ,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=SERVER,mountvers=3,mountpor t=38013,mountproto=udp,local_lock=all,addr=SERVER
Und wenn ich die alle mit angebe, bekomme ich ein "Failed to find 'tcp' protocol".
Das kann ich mit proto=tcp6 ebenso erreichen (wobei ich dann alle addr-Angaben auch lösche, weil ip4-Adressen dann bestimmt nicht helfen). Und ganz ohne proto= Option fehlt im UDP.
Wie gesagt: Auf Leap 15.0 tut es, mit tubleweed 20200128 hat es auch noch getan.
Wer weiß Rat?
Gruß Jan
seit dem Wochenende hatte ich auch so ein Problem (Firmware aktualisiert - mount ging nicht mehr :-((. ) Falls das hier passt: Ich habe auf dem NAS für NFS eingetragen Enable NFS v2/v3 Service UND Enable NFS v4 Service
Dann ging es. Gruss Hugo
-
Handwerker, Jan (IMK) -
Hendrik Woltersdorf -
Hugo