[opensuse] Problem mounting nfs partition on 12.3
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Situation: Some machines can mount a share, others can not. For example, I can mount the share on a 12.3 host with a 12.3, acting as nfsserver, with a 12.3 guest in vmplayer, acting as nfs client. However, the same host machine can not mount it localy to itself (nfs client); neither can my laptop (network is fine: I can ping and ssh). Server exports entry (one single line, wrapped here for clarity): /data/storage_c/repositorios_zypp/ \ 192.168.1.0/24(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure) \ 172.16.108.0/24(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure) \ 192.168.74.0/24(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure) \ 127.0.0.1(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure) Server import entry: localhost:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmp nfs defaults 0 0 vmplayer guest; fstab entry: telcontar.valinor:/data/storage_c/repositorios_zypp /var/cache/zypp/nfs_packages nfs4 defaults 0 0 Output in terminal using vmplayer guest: eleanor3:~ # mount | grep nfs rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.74.127,local_lock=none,addr=192.168.1.14) eleanor3:~ # eleanor3:~ # ls /var/cache/zypp/nfs_packages 11_2 Karlos Arguiñano en tu cocina (20110617) - Q9.480*384.xvid.avi 11_3 NO_BORRAR__son_cruciales 11_4 not_mounted 12_1 notas 12_2 notas~ 12_3 se_montan_en_var_cache_zypp_packages eleanor3:~ # eleanor3:~ # umount /var/cache/zypp/nfs_packages eleanor3:~ # time mount /var/cache/zypp/nfs_packages real 0m0.085s user 0m0.004s sys 0m0.013s eleanor3:~ # (it was mounted on boot) However, if I try on the server, local nfs mount, all I get is a long timeout, or nothing. Same thing froom the laptop, but this time I get an entry on the server firewall log that the package was accepted. Telcontar:~ # time mount /mnt/nfs/tmp ^C real 99m3.772s user 0m0.002s sys 0m0.000s Telcontar:~ #date Thu Jul 11 12:33:50 CEST 2013 Telcontar:~ # Telcontar:~ # l /mnt/nfs/tmp total 8 drwx------ 2 root root 4096 Aug 11 2012 ./ drwxrwx--- 4 root root 4096 Aug 11 2012 ../ - -rw-r--r-- 1 root root 0 Nov 11 2010 not_mounted Telcontar:~ # Log: <0.5> 2013-07-11 11:20:04 Telcontar kernel - - - [507374.048098] nfs: server localhost not responding, timed out <0.5> 2013-07-11 11:24:05 Telcontar kernel - - - [507614.688025] nfs: server localhost not responding, timed out <0.5> 2013-07-11 11:28:05 Telcontar kernel - - - [507855.328205] nfs: server localhost not responding, timed out <0.5> 2013-07-11 11:32:06 Telcontar kernel - - - [508095.968022] nfs: server localhost not responding, timed out ... several more, one every 4 minutes. ... <0.5> 2013-07-11 12:31:22 Telcontar kernel - - - [511652.320029] nfs: server localhost not responding, timed out Being on localhost, there can not be firewal issues. This setup worked fine on 12.1 (sysstemv), but fails now on 12.3 (systemd), I have not changed the config. - -- Cheers Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHejRAACgkQtTMYHG2NR9W+bACdFhdiWFpHpE1Xc6EkcJzQ0RlO 0JgAoIWphHnONiOZehDvedlGd47q5AD3 =R2gw -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/f0ad86a443e23d8412160985c73d3b1b.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-07-11 at 12:46 +0200, I wrote:
several more, one every 4 minutes. ... <0.5> 2013-07-11 12:31:22 Telcontar kernel - - - [511652.320029] nfs: server localhost not responding, timed out
Being on localhost, there can not be firewal issues. This setup worked fine on 12.1 (sysstemv), but fails now on 12.3 (systemd), I have not changed the config.
Mounting manually, I get this output: Telcontar:~ # mount -v localhost:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmpmount.nfs: timeout set for Thu Jul 11 13:06:06 2013 mount.nfs: trying text-based options 'vers=4,addr=::1,clientaddr=::1' ^C Telcontar:~ # Telcontar:~ # mount -v 127.0.0.1:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmp mount.nfs: timeout set for Thu Jul 11 13:06:54 2013 mount.nfs: trying text-based options 'vers=4,addr=127.0.0.1,clientaddr=127.0.0.1' ^C Telcontar:~ # date Thu Jul 11 13:11:05 CEST 2013 Telcontar:~ # it does not timeout, despite the message. However, specifying nfs instead of defaults (which is nfs4), it succeeds: Telcontar:~ # date --rfc-3339=seconds ; mount -t nfs -v 127.0.0.1:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmp ; date --rfc-3339=seconds 2013-07-11 13:15:47+02:00 mount.nfs: timeout set for Thu Jul 11 13:17:47 2013 mount.nfs: trying text-based options 'vers=4,addr=127.0.0.1,clientaddr=127.0.0.1' 2013-07-11 13:15:47+02:00 Telcontar:~ # ls /mnt/nfs/tmp 11_2 Karlos Arguiñano en tu cocina (20110617) - Q9.480*384.xvid.avi 11_3 NO_BORRAR__son_cruciales 11_4 notas 12_1 notas~ 12_2 se_montan_en_var_cache_zypp_packages 12_3 Telcontar:~ # However, the fstab entry does not list nfs4, but nfs: Telcontar:~ # grep nfs /etc/fstab localhost:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmp nfs defaults 0 0 Telcontar:~ # So obviously, nfs4 fails. Why is the system attempting to use nfs4, then, if the fstab entry does not say "nfs4"? Can I somehow specify nfs3? I tried to write "nfs3" in fstab, got an error that said nfs3 was invalid or something. Another problem when umounting - huh?: Telcontar:~ # umount /mnt/nfs/tmp umount.nfs4: /mnt/nfs/tmp: device is busy Telcontar:~ # umount /mnt/nfs/tmp umount.nfs4: /mnt/nfs/tmp: device is busy Telcontar:~ # lsof /mnt/nfs/tmp ... COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME famd 8764 cer 9r DIR 0,41 4096 30986370 /mnt/nfs/tmp famd 8764 cer 11r DIR 0,41 21 294273060 /mnt/nfs/tmp/11_2 famd 8764 cer 12r DIR 0,41 128 806202862 /mnt/nfs/tmp/11_3 famd 8764 cer 13r DIR 0,41 4096 542959478 /mnt/nfs/tmp/11_4 famd 8764 cer 14r DIR 0,41 4096 13615562 /mnt/nfs/tmp/12_1 famd 8764 cer 15r DIR 0,41 84 13851750 /mnt/nfs/tmp/12_2 famd 8764 cer 16r DIR 0,41 4096 23853594 /mnt/nfs/tmp/12_3 Telcontar:~ # rcfam restart redirecting to systemctl restart fam Telcontar:~ # umount /mnt/nfs/tmp Telcontar:~ # If I change fstab: localhost:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmp nfs defaults,vers=3 0 0 I get another error: Telcontar:~ # mount -v /mnt/nfs/tmp mount.nfs: timeout set for Thu Jul 11 13:26:13 2013 mount.nfs: trying text-based options 'vers=3,addr=::1' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying ::1 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying ::1 prog 100005 vers 3 prot UDP port 58991 mount.nfs: mount(2): Permission denied mount.nfs: access denied by server while mounting localhost:/data/storage_c/repositorios_zypp/ Telcontar:~ # If I change fstab to vers=4, it does not work, timeout: Telcontar:~ # mount -v /mnt/nfs/tmp mount.nfs: timeout set for Thu Jul 11 13:27:51 2013 mount.nfs: trying text-based options 'vers=4,addr=::1,clientaddr=::1' ^C Telcontar:~ # But if I comment the IPv6 entry for localhost in /etc/hosts it succeeds! #::1 localhost ipv6-localhost ipv6-loopback Telcontar:~ # mount -v /mnt/nfs/tmp mount.nfs: timeout set for Thu Jul 11 13:29:20 2013 mount.nfs: trying text-based options 'vers=4,addr=127.0.0.1,clientaddr=127.0.0.1' Telcontar:~ # So, the trick seems to be specifying IPv4 and vers=4 in fstab. How do I force nfs not to even try IPv6, or how do I get it working with IPv6? [...] Found it! I need and specific entry in "exports" with "::1(...)" for IPv6 to work... Telcontar:~ # umount -v /mnt/nfs/tmp umount.nfs4: /mnt/nfs/tmp: device is busy Telcontar:~ # rcfam restart redirecting to systemctl restart fam Telcontar:~ # umount -v /mnt/nfs/tmp Telcontar:~ # mount -v /mnt/nfs/tmp mount.nfs: timeout set for Thu Jul 11 13:41:22 2013 mount.nfs: trying text-based options 'vers=4,addr=::1,clientaddr=::1' Telcontar:~ # - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHeqyQACgkQtTMYHG2NR9VwkACfYkiyJI+sS1FnVIAImQPKvSoA 3IUAn2cHchxcNO3/NSAP/YVlYJTinjKn =SWNt -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-07-11 at 14:54 +0200, I wrote:
[...]
Found it! I need and specific entry in "exports" with "::1(...)" for IPv6 to work...
Now I need it to work from the laptop, and it fails. minas-tirith:~ # date --rfc-3339=seconds ; time mount -v /var/cache/zypp/nfs_packages/ ; date --rfc-3339=seconds ; ls /var/cache/zypp/nfs_packages/ 2013-07-11 14:52:44+02:00 mount.nfs: timeout set for Thu Jul 11 14:54:44 2013 mount.nfs: trying text-based options 'nfsvers=4,addr=192.168.1.14,clientaddr=192.168.1.129' mount.nfs: mount(2): Connection timed out mount.nfs: Connection timed out real 3m0.556s user 0m0.001s sys 0m0.002s 2013-07-11 14:55:45+02:00 11_4 not_mounted minas-tirith:~ # So it is using IPv4 and vers=4, but fails. I see in the server firewall the packet is accepted: <0.4> 2013-07-11 14:53:46 Telcontar kernel - - - [520195.627684] SFW2-INext-ACC-TRUST IN=eth0 OUT= MAC=00:21:85:16:2d:0b:0c:ee:e6:d7:bb:5f:08:00 SRC=192.168.1.129 DST=192.168.1.14 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21451 DF PROTO=TCP SPT=1004 DPT=2049 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A02B94CC60000000001030306) And in the client I see the package going out from port 1004 to 2049, but no answer from the server. Why no answer? Is there some other configuration file for NFSserver where one can specify which interfaces to listen on? Because in the exports file, the entire LAN (192.168.1.0/24) is allowed... - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHerP8ACgkQtTMYHG2NR9W6AgCfbfxDYPhttVlgvy4Yi7qEsVvy ifgAnRUznZkbmcIZUhRBhzNRPVRrU/1n =xa7O -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Thu, 11 Jul 2013 15:02:55 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-07-11 at 14:54 +0200, I wrote:
[...]
Found it! I need and specific entry in "exports" with "::1(...)" for IPv6 to work...
Now I need it to work from the laptop, and it fails.
So what exactly did you change? You say it was working before so you changed something, right? [...]
And in the client I see the package going out from port 1004 to 2049, but no answer from the server. Why no answer?
Did package reach the server at all? Use tcpdump/tshark to verify.
Is there some other configuration file for NFSserver where one can specify which interfaces to listen on?
man 8 nfsd -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHhBhQACgkQR6LMutpd94xTVQCggT5NZXj/CtnWaJ5UNc4LgF7+ ZRIAnRs2cJyh4auSbpoKIGvVlMzX0uJU =PClQ -----END PGP SIGNATURE----- N▀╖╡ФЛr╦⌡yИ ┼Z)z{.╠О╝·к⌡╠йБmЙ)z{.╠Й+│:╒{Zrшaz▄'z╥╕j)h╔ИЛ╨г╬ё ч╝┼^·к╛z┼Ю
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1307140008050.16893@Telcontar.valinor> On Saturday, 2013-07-13 at 11:47 +0400, Andrey Borzenkov wrote:
В Thu, 11 Jul 2013 15:02:55 +0200 (CEST) "Carlos E. R." <> пишет:
Now I need it to work from the laptop, and it fails.
So what exactly did you change? You say it was working before so you changed something, right?
Me, nothing. I upgraded the server system from 12.1 to 12.3, an offline upgrade procedure. The exports file was not touched. The client system, the laptop, is still 11.4.
[...]
And in the client I see the package going out from port 1004 to 2049, but no answer from the server. Why no answer?
Did package reach the server at all? Use tcpdump/tshark to verify.
The server firewall logs the package as being allowed, so yes, it does reach the server.
Is there some other configuration file for NFSserver where one can specify which interfaces to listen on?
man 8 nfsd
I see nothing there about a configuration file, or related to my problem. The word "interface" does not exist. For the record, I solved the problem by forcing the client in the laptop to use NFS 3 (nfsvers=3). I changed the fstab like this: 192.168.1.14:/data/storage_c/repositorios_zypp/ /var/cache/zypp/nfs_packages nfs defaults,noauto,_netdev,nfsvers=3 0 0 And it works, which is a regression, because previously it worked with nfsvers=4. And it is weird, because two clients using 12.3 can connect with nfs 4. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHh0z8ACgkQtTMYHG2NR9VeTACdHClzwa+PlL81IaB5LiaikZCC 4UsAn1SJywWoJZcFbTowqlKjC8Y+NugD =9Pb9 -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Sun, 14 Jul 2013 00:22:48 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LNX.2.00.1307140008050.16893@Telcontar.valinor>
On Saturday, 2013-07-13 at 11:47 +0400, Andrey Borzenkov wrote:
В Thu, 11 Jul 2013 15:02:55 +0200 (CEST) "Carlos E. R." <> пишет:
Now I need it to work from the laptop, and it fails.
So what exactly did you change? You say it was working before so you changed something, right?
Me, nothing.
I upgraded the server system from 12.1 to 12.3, an offline upgrade procedure. The exports file was not touched.
The client system, the laptop, is still 11.4.
Ah, OK, this is another system, sorry I was confused. [...]
Did package reach the server at all? Use tcpdump/tshark to verify.
The server firewall logs the package as being allowed, so yes, it does reach the server.
Did you try to disable firewall on both client and server to be sure it does not influence it?
Is there some other configuration file for NFSserver where one can specify which interfaces to listen on?
man 8 nfsd
I see nothing there about a configuration file, or related to my problem. The word "interface" does not exist.
-H or --host hostname specify a particular hostname (or address) that NFS requests will be accepted on. By default, rpc.nfsd will accept NFS requests on all known network addresses. Note that lockd (which performs file locking services for NFS) may still accept request on all known network addresses. This may change in future releases of the Linux Kernel.
For the record, I solved the problem by forcing the client in the laptop to use NFS 3 (nfsvers=3).
I was about to suggest it ... :)
I changed the fstab like this:
192.168.1.14:/data/storage_c/repositorios_zypp/ /var/cache/zypp/nfs_packages nfs defaults,noauto,_netdev,nfsvers=3 0 0
And it works, which is a regression, because previously it worked with nfsvers=4. And it is weird, because two clients using 12.3 can connect with nfs 4.
It is quite possible that in the past it silently used NFS V3 without you be aware of it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHiWrEACgkQR6LMutpd94zKXwCgiDg8Xgnz1USb9KCIUhAlKMZD 5SsAn1yvb4fv7ACA5eYrNWULVsoZQkKy =EH1/ -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-07-14 at 12:00 +0400, Andrey Borzenkov wrote:
В Sun, 14 Jul 2013 00:22:48 +0200 (CEST) "Carlos E. R." <> пишет:
[...]
Did package reach the server at all? Use tcpdump/tshark to verify.
The server firewall logs the package as being allowed, so yes, it does reach the server.
Did you try to disable firewall on both client and server to be sure it does not influence it?
No... but I will, just in case. [...] No, failure: minas-tirith:~ # SuSEfirewall2 stop SuSEfirewall2: Firewall rules unloaded. minas-tirith:~ # date --rfc-3339=seconds ; time mount -v /var/cache/zypp/nfs_packages/ ; date --rfc-3339=seconds 2013-07-14 15:10:35+02:00 mount.nfs: timeout set for Sun Jul 14 15:12:35 2013 mount.nfs: trying text-based options 'nfsvers=4,addr=192.168.1.14,clientaddr=192.168.1.129' mount.nfs: mount(2): Connection timed out mount.nfs: Connection timed out real 3m0.542s user 0m0.001s sys 0m0.003s 2013-07-14 15:13:35+02:00 minas-tirith:~ # SuSEfirewall2 start SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ... SuSEfirewall2: Firewall rules successfully set minas-tirith:~ # Notice that the test says that it will time out at 15:12:35, but it does timeout at 15:13:35, ie, one minute more.
It is quite possible that in the past it silently used NFS V3 without you be aware of it.
Maybe. But IIRC, I think that when the server was upgraded to 12.1, I had to specify version 4 for it to work. The previous fstab line on the laptop was this: #192.168.1.14:/data/storage_c/repositorios_zypp/ /var/cache/zypp/nfs_packages nfs defaults,noauto,_netdev,nfsvers=4 0 0 which you see, specifies version 4, it can not try version 3, I believe. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHipRcACgkQtTMYHG2NR9XTOACffIW+QFKjeuKnUp+AOevz2pTk zdUAn2m01EvxVm2xK1tiMwii/N2Z0mfW =+b9W -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Thu, 11 Jul 2013 14:54:52 +0200 (CEST) "Carlos E. R." <carlos.e.r@opensuse.org> пишет:
Mounting manually, I get this output:
Telcontar:~ # mount -v localhost:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmpmount.nfs: timeout set for Thu Jul 11 13:06:06 2013 mount.nfs: trying text-based options 'vers=4,addr=::1,clientaddr=::1' ^C Telcontar:~ # Telcontar:~ # mount -v 127.0.0.1:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmp mount.nfs: timeout set for Thu Jul 11 13:06:54 2013 mount.nfs: trying text-based options 'vers=4,addr=127.0.0.1,clientaddr=127.0.0.1' [...]
How do I force nfs not to even try IPv6
How is it related to NFS? You requested to mount localhost and localhost resolves to IPv6 address ::1, so it is trying IPv6. When you explicitly give IPv4 address it is trying IPv4. To force NFS to not even try IPv6 use server name that resolves to IPv4 address. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHhBLIACgkQR6LMutpd94wJkgCfeqEPyoXOhDtyAgnhNFat3AZe YwEAn1l2b4e3HGbUbdN0JsC+ILyTMDSL =I9Xz -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2013-07-13 at 11:41 +0400, Andrey Borzenkov wrote:
How is it related to NFS? You requested to mount localhost and localhost resolves to IPv6 address ::1, so it is trying IPv6. When you explicitly give IPv4 address it is trying IPv4.
To force NFS to not even try IPv6 use server name that resolves to IPv4 address.
The localhost entries in the hosts file, I did not write them. openSUSE wrote them, first ::1, and later 127.0.0.1. Nor did I write the exports file, it was initially written by YaST, with no IPv6 entries. The other entries I added them. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEUEARECAAYFAlHh1B4ACgkQtTMYHG2NR9UJGACeKFHlEfeE27kZoS1+SqKDtMiN qFQAmPM1Fu4zp42O/ZcMNt6AmAPUEoU= =0jG/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Thu, 11 Jul 2013 14:54:52 +0200 (CEST) "Carlos E. R." <carlos.e.r@opensuse.org> пишет:
So obviously, nfs4 fails. Why is the system attempting to use nfs4, then, if the fstab entry does not say "nfs4"?
There is no "nfs4" filesystem. There is only one nfs client implementation that supports NFS V2, V3, V4. mount.nfs and mount.nfs4 are exactly the same programs: bor@opensuse:~> LC_ALL=C ll /sbin/mount.nfs* - -rwsr-xr-x 1 root root 110888 Jun 18 16:49 /sbin/mount.nfs lrwxrwxrwx 1 root root 9 Jun 21 06:12 /sbin/mount.nfs4 -> mount.nfs with only difference (at least, in the past) being NFS protocol version used.
Can I somehow specify nfs3?
Of course. mount -o nfsvers=3 ... It is always good practice to specify required NFS version explicitly. It is not the first time version and defaults change (NFS V2 => NFS V3).
I tried to write "nfs3" in fstab, got an error that said nfs3 was invalid or something.
Right, see above. By default client should negotiate NFS version, depending on which one is supported by server. So leaving explicit version will result in different behavior depending on what client/server combination support. As NFS V3 and NFS V4 have completely different models for sharing and user mappings you usually cannot simply drop in NFS V4 in place of NFS V3 and expect it to work. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHiXK4ACgkQR6LMutpd94xqtgCfU6fUfzswJHGMZy68y9oy3gpD kyAAoIRQX7u7cs2WGe29j9W4NpqUT6LI =sK/0 -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-07-14 at 12:09 +0400, Andrey Borzenkov wrote:
В Thu, 11 Jul 2013 14:54:52 +0200 (CEST) "Carlos E. R." <> пишет:
Right, see above.
By default client should negotiate NFS version, depending on which one is supported by server. So leaving explicit version will result in different behavior depending on what client/server combination support. As NFS V3 and NFS V4 have completely different models for sharing and user mappings you usually cannot simply drop in NFS V4 in place of NFS V3 and expect it to work.
Look: eleanor3:~ # mount | grep nfs rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.74.127,local_lock=none,addr=192.168.1.14) eleanor3:~ # minas-tirith:~ # mount | grep nfs 192.168.1.14:/data/storage_c/repositorios_zypp/ on /var/cache/zypp/nfs_packages type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.14,mountvers=3,mountport=35298,mountproto=udp,local_lock=none,addr=192.168.1.14) minas-tirith:~ # You see, the same server is working with versions 4 and 3, simultaneously. Eleanor3 is a virtual machine running 12.3, hosted on the server, and minas-tirith is a laptop running 11.4, connected via wifi. And there is no negotiation; when I use this line in fstab on the laptop: 192.168.1.14:/data/storage_c/repositorios_zypp/ /var/cache/zypp/nfs_packages nfs defaults,noauto 0 0 I get: minas-tirith:~ # date --rfc-3339=seconds ; time mount -v /var/cache/zypp/nfs_packages/ ; date --rfc-3339=seconds 2013-07-14 15:24:51+02:00 mount.nfs: timeout set for Sun Jul 14 15:26:51 2013 mount.nfs: trying text-based options 'vers=4,addr=192.168.1.14,clientaddr=192.168.1.129' mount.nfs: mount(2): Connection timed out mount.nfs: Connection timed out real 3m0.192s user 0m0.000s sys 0m0.005s 2013-07-14 15:27:51+02:00 minas-tirith:~ # It does not attempt to try nfs3 when nfs4 fails, probably because the connection attempt itself fails. The client can not determine if the server is version 2 or 3 or 4, because the server does not even answer! A packet capture, edited to reduce size: No. Time Source Destination Protocol Length Info 249 15:35:33.385373000 192.168.1.129 192.168.1.14 TCP 74 telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26851809 TSecr=0 WS=64 Transmission Control Protocol, Src Port: telnets (992), Dst Port: nfs (2049), Seq: 0, Len: 0 No. Time Source Destination Protocol Length Info 250 15:35:33.385445000 192.168.1.14 192.168.1.129 TCP 74 nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647243754 TSecr=26851809 WS=128 279 15:35:34.586491000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647244956 TSecr=26851809 WS=128 322 15:35:36.391733000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26854816 TSecr=0 WS=64 323 15:35:36.391771000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647246761 TSecr=26851809 WS=128 326 15:35:36.586499000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647246956 TSecr=26851809 WS=128 428 15:35:40.586502000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647250956 TSecr=26851809 WS=128 502 15:35:42.408036000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26860832 TSecr=0 WS=64 503 15:35:42.408057000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647252777 TSecr=26851809 WS=128 641 15:35:48.786494000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647259156 TSecr=26851809 WS=128 758 15:35:54.440401000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26872864 TSecr=0 WS=64 759 15:35:54.440425000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647264809 TSecr=26851809 WS=128 1029 15:36:04.786501000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647275156 TSecr=26851809 WS=128 1422 15:36:18.473352000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26896896 TSecr=0 WS=64 1423 15:36:18.473388000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647288842 TSecr=26851809 WS=128 2628 15:37:06.603229000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26945024 TSecr=0 WS=64 2629 15:37:06.603258000 192.168.1.14 192.168.1.129 TCP 74 [TCP Previous segment not captured] nfs > telnets [SYN, ACK] Seq=1456528306 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647336972 TSecr=26945024 WS=128 2656 15:37:07.804495000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=1456528306 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647338174 TSecr=26945024 WS=128 2733 15:37:10.004501000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=1456528306 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647340374 TSecr=26945024 WS=128 2876 15:37:14.004491000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=1456528306 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647344374 TSecr=26945024 WS=128 3081 15:37:22.204498000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=1456528306 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647352574 TSecr=26945024 WS=128 3502 15:37:38.604487000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=1456528306 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647368974 TSecr=26945024 WS=128 Retransmission? From both sides? A sucesful connection (version 3) goes like this: No. Time Source Destination Protocol Length Info 90 15:59:58.752892000 192.168.1.129 192.168.1.14 TCP 74 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=28317123 TSecr= 91 15:59:58.752967000 192.168.1.14 192.168.1.129 TCP 74 sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=6487 98 15:59:59.133783000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) request id=0x2636, seq=2424/30729, ttl=64 99 15:59:59.133811000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) reply id=0x2636, seq=2424/30729, ttl=64 116 15:59:59.754500000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 160 16:00:01.754498000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 161 16:00:01.757790000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 162 16:00:01.757808000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 173 16:00:02.341905000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) request id=0x70f4, seq=8814/28194, ttl=64 174 16:00:02.343809000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) reply id=0x70f4, seq=8814/28194, ttl=64 259 16:00:05.754505000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 302 16:00:07.774018000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 303 16:00:07.774053000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 329 16:00:08.763987000 192.168.1.129 192.168.1.14 Portmap 98 V2 GETPORT Call (Reply In 332) NFS(100003) V:3 UDP 332 16:00:08.764193000 192.168.1.14 192.168.1.129 Portmap 70 V2 GETPORT Reply (Call In 329) Port:2049 334 16:00:08.767059000 192.168.1.129 192.168.1.14 NFS 82 V3 NULL Call (Reply In 337) 337 16:00:08.767147000 192.168.1.14 192.168.1.129 NFS 66 V3 NULL Reply (Call In 334) 340 16:00:08.770315000 192.168.1.129 192.168.1.14 Portmap 98 V2 GETPORT Call (Reply In 341) MOUNT(100005) V:3 UDP 341 16:00:08.770520000 192.168.1.14 192.168.1.129 Portmap 70 V2 GETPORT Reply (Call In 340) Port:35298 342 16:00:08.773204000 192.168.1.129 192.168.1.14 MOUNT 82 V3 NULL Call (Reply In 345) 345 16:00:08.773289000 192.168.1.14 192.168.1.129 MOUNT 66 V3 NULL Reply (Call In 342) 346 16:00:08.776029000 192.168.1.129 192.168.1.14 MOUNT 82 V3 NULL Call (Reply In 347) 347 16:00:08.776080000 192.168.1.14 192.168.1.129 MOUNT 66 V3 NULL Reply (Call In 346) 348 16:00:08.778077000 192.168.1.129 192.168.1.14 MOUNT 162 V3 MNT Call (Reply In 349) /data/storage_c/repositorios_zypp/ 349 16:00:08.778432000 192.168.1.14 192.168.1.129 MOUNT 90 V3 MNT Reply (Call In 348) 350 16:00:08.780371000 192.168.1.129 192.168.1.14 Portmap 130 V2 GETPORT Call (Reply In 351) NFS(100003) V:3 UDP 351 16:00:08.780543000 192.168.1.14 192.168.1.129 Portmap 70 V2 GETPORT Reply (Call In 350) Port:2049 352 16:00:08.783074000 192.168.1.129 192.168.1.14 NFS 82 V3 NULL Call (Reply In 353) 353 16:00:08.783122000 192.168.1.14 192.168.1.129 NFS 66 V3 NULL Reply (Call In 352) 354 16:00:08.786104000 192.168.1.129 192.168.1.14 NFSACL 82 V3 NULL Call (Reply In 355) 355 16:00:08.786135000 192.168.1.14 192.168.1.129 NFSACL 66 V3 NULL Reply (Call In 354) 356 16:00:08.787866000 192.168.1.129 192.168.1.14 NFS 134 V3 FSINFO Call (Reply In 357), FH:0xe980d59c 357 16:00:08.787906000 192.168.1.14 192.168.1.129 NFS 122 V3 FSINFO Reply (Call In 356) 358 16:00:08.789627000 192.168.1.129 192.168.1.14 NFS 134 V3 PATHCONF Call (Reply In 359), FH:0xe980d59c 359 16:00:08.789657000 192.168.1.14 192.168.1.129 NFS 98 V3 PATHCONF Reply (Call In 358) 360 16:00:08.791389000 192.168.1.129 192.168.1.14 NFS 134 V3 GETATTR Call (Reply In 361), FH:0xe980d59c 361 16:00:08.791422000 192.168.1.14 192.168.1.129 NFS 154 V3 GETATTR Reply (Call In 360) Directory mode:0755 uid:0 gid:0 362 16:00:08.793232000 192.168.1.129 192.168.1.14 NFS 134 V3 FSINFO Call (Reply In 363), FH:0xe980d59c 363 16:00:08.793264000 192.168.1.14 192.168.1.129 NFS 122 V3 FSINFO Reply (Call In 362) 364 16:00:08.795382000 192.168.1.129 192.168.1.14 NFS 134 V3 GETATTR Call (Reply In 365), FH:0xe980d59c 365 16:00:08.795418000 192.168.1.14 192.168.1.129 NFS 154 V3 GETATTR Reply (Call In 364) Directory mode:0755 uid:0 gid:0 386 16:00:09.134108000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) request id=0x2636, seq=2425/30985, ttl=64 387 16:00:09.134138000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) reply id=0x2636, seq=2425/30985, ttl=64 453 16:00:12.346160000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) request id=0x70f4, seq=8815/28450, ttl=64 454 16:00:12.348064000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) reply id=0x70f4, seq=8815/28450, ttl=64 Strange... the first thing is "sunrpc". On the failed connection there is no rpc. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHiw9oACgkQtTMYHG2NR9XiJACfdAI9HVxP3Zd625XDM0Nd7HeE Gk4AoIoQMXOFoa4UkaHPGK/LifmnucP4 =kXng -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Sun, 14 Jul 2013 17:29:21 +0200 (CEST) "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2013-07-14 at 12:09 +0400, Andrey Borzenkov wrote:
В Thu, 11 Jul 2013 14:54:52 +0200 (CEST) "Carlos E. R." <> пишет:
Right, see above.
By default client should negotiate NFS version, depending on which one is supported by server. So leaving explicit version will result in different behavior depending on what client/server combination support. As NFS V3 and NFS V4 have completely different models for sharing and user mappings you usually cannot simply drop in NFS V4 in place of NFS V3 and expect it to work.
Look:
eleanor3:~ # mount | grep nfs rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) telcontar.valinor:/data/storage_c/repositorios_zypp on /var/cache/zypp/nfs_packages type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.74.127,local_lock=none,addr=192.168.1.14) eleanor3:~ #
minas-tirith:~ # mount | grep nfs 192.168.1.14:/data/storage_c/repositorios_zypp/ on /var/cache/zypp/nfs_packages type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.1.14,mountvers=3,mountport=35298,mountproto=udp,local_lock=none,addr=192.168.1.14) minas-tirith:~ #
You see, the same server is working with versions 4 and 3, simultaneously.
Ehh ... minas-tirith mounts also using UDP and not TCP, which confirms that there is some connectivity issue.
A packet capture, edited to reduce size:
No. Time Source Destination Protocol Length Info 249 15:35:33.385373000 192.168.1.129 192.168.1.14 TCP 74 telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26851809 TSecr=0 WS=64 Transmission Control Protocol, Src Port: telnets (992), Dst Port: nfs (2049), Seq: 0, Len: 0
No. Time Source Destination Protocol Length Info 250 15:35:33.385445000 192.168.1.14 192.168.1.129 TCP 74 nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647243754 TSecr=26851809 WS=128 279 15:35:34.586491000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647244956 TSecr=26851809 WS=128
So SYN request comes to NFS server and NFS server answers to this. But your client apparently ignores it. So issues are with your client, not your server. [...]
428 15:35:40.586502000 192.168.1.14
192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647250956 TSecr=26851809 WS=128 Server tries to retransmit SYN ACK packet.
502 15:35:42.408036000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26860832 TSecr=0 WS=64
Client times out and sends SYN again
503 15:35:42.408057000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647252777 TSecr=26851809 WS=128
Server gets it just fine and answers.
641 15:35:48.786494000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647259156 TSecr=26851809 WS=128
But never gets response from client as it looks like.
Retransmission? From both sides?
Yes. Which part surprises you?
A sucesful connection (version 3) goes like this:
No. Time Source Destination Protocol Length Info 90 15:59:58.752892000 192.168.1.129 192.168.1.14 TCP 74 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=28317123 TSecr= 91 15:59:58.752967000 192.168.1.14 192.168.1.129 TCP 74 sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=6487 98 15:59:59.133783000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) request id=0x2636, seq=2424/30729, ttl=64 99 15:59:59.133811000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) reply id=0x2636, seq=2424/30729, ttl=64 116 15:59:59.754500000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 160 16:00:01.754498000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 161 16:00:01.757790000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 162 16:00:01.757808000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 173 16:00:02.341905000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) request id=0x70f4, seq=8814/28194, ttl=64 174 16:00:02.343809000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) reply id=0x70f4, seq=8814/28194, ttl=64 259 16:00:05.754505000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 302 16:00:07.774018000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 303 16:00:07.774053000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S
You get *EXACTLY* the same problem. Client never replies to SYN ACK from server so connection is never established.
329 16:00:08.763987000 192.168.1.129 192.168.1.14 Portmap 98 V2 GETPORT Call (Reply In 332) NFS(100003) V:3 UDP
And client falls back to UDP. Which of course cannot work with NFS V4 which dropped support for UDP entirely. So from information you provided it is either client or network issue. If trace was captured on client, it is most likely client. For a start check firewall on client ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHi81EACgkQR6LMutpd94wftACdHlDtjXYX7uZEyzIWWaYkTG02 aJQAoMqHw18Zz8y5by4p7OWuphfWBQz+ =5ro4 -----END PGP SIGNATURE----- N▀╖╡ФЛr╦⌡yИ ┼Z)z{.╠О╝·к⌡╠йБmЙ)z{.╠Й+│:╒{Zrшaz▄'z╥╕j)h╔ИЛ╨г╬ё ч╝┼^·к╛z┼Ю
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LNX.2.00.1307142139130.16893@Telcontar.valinor> On Sunday, 2013-07-14 at 22:51 +0400, Andrey Borzenkov wrote:
В Sun, 14 Jul 2013 17:29:21 +0200 (CEST) "Carlos E. R." <> пишет:
You see, the same server is working with versions 4 and 3, simultaneously.
Ehh ... minas-tirith mounts also using UDP and not TCP, which confirms that there is some connectivity issue.
A packet capture, edited to reduce size:
No. Time Source Destination Protocol Length Info 249 15:35:33.385373000 192.168.1.129 192.168.1.14 TCP 74 telnets > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=26851809 TSecr=0 WS=64 Transmission Control Protocol, Src Port: telnets (992), Dst Port: nfs (2049), Seq: 0, Len: 0
No. Time Source Destination Protocol Length Info 250 15:35:33.385445000 192.168.1.14 192.168.1.129 TCP 74 nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647243754 TSecr=26851809 WS=128 279 15:35:34.586491000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > telnets [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=647244956 TSecr=26851809 WS=128
So SYN request comes to NFS server and NFS server answers to this. But your client apparently ignores it. So issues are with your client, not your server.
The laptop does not receive that package. Iptraf showed it was not received, and I'm running wireshark on both computers and I do not see the response.
Retransmission? From both sides?
Yes. Which part surprises you?
Both. It has to be the router in the midle, it has changed recently. But it is very strange: pings gets trhough, I'm connected to the laptop via "ssh -Y", running wireshark over that ssh connection, thunderbird is connected via imap on the server... no problems, it works. Why not nfs? All those use tcp.
A sucesful connection (version 3) goes like this:
No. Time Source Destination Protocol Length Info 90 15:59:58.752892000 192.168.1.129 192.168.1.14 TCP 74 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=28317123 TSecr= 91 15:59:58.752967000 192.168.1.14 192.168.1.129 TCP 74 sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=6487 98 15:59:59.133783000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) request id=0x2636, seq=2424/30729, ttl=64 99 15:59:59.133811000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) reply id=0x2636, seq=2424/30729, ttl=64 116 15:59:59.754500000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 160 16:00:01.754498000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 161 16:00:01.757790000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 162 16:00:01.757808000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 173 16:00:02.341905000 192.168.1.14 192.168.1.129 ICMP 98 Echo (ping) request id=0x70f4, seq=8814/28194, ttl=64 174 16:00:02.343809000 192.168.1.129 192.168.1.14 ICMP 98 Echo (ping) reply id=0x70f4, seq=8814/28194, ttl=64 259 16:00:05.754505000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S 302 16:00:07.774018000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 57233 > sunrpc [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 303 16:00:07.774053000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] sunrpc > 57233 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 S
You get *EXACTLY* the same problem. Client never replies to SYN ACK from server so connection is never established.
329 16:00:08.763987000 192.168.1.129 192.168.1.14 Portmap 98 V2 GETPORT Call (Reply In 332) NFS(100003) V:3 UDP
And client falls back to UDP. Which of course cannot work with NFS V4 which dropped support for UDP entirely.
So from information you provided it is either client or network issue. If trace was captured on client, it is most likely client. For a start check firewall on client ...
I tried also with firewal down on both sides, no difference. I restarted the test that was running with ipraf with both firewalls down. I see no difference, but I have to wait the 3 minutes timeout. If the router is capturing those packages, it must be because it thinks they are for him, because it has fileserver capabilities (which I do not use). But it makes no sense, the IP destination are not for it! Ok, capture on laptop: No. Time Source Destination Protocol Length Info 563 15.005465000 192.168.1.129 192.168.1.14 TCP 74 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36864829 TSecr=0 WS=64 606 18.015577000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36867840 TSecr=0 WS=64 688 24.031598000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36873856 TSecr=0 WS=64 917 36.063562000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36885888 TSecr=0 WS=64 1321 60.127563000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36909952 TSecr=0 WS=64 3704 108.255585000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36958080 TSecr=0 WS=64 And on the server: No. Time Source Destination Protocol Length Info 580 21:47:15.918490000 192.168.1.129 192.168.1.14 TCP 74 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36864829 TSecr=0 WS=64 582 21:47:15.918508000 192.168.1.14 192.168.1.129 TCP 74 nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669546288 TSecr=36864829 WS=128 642 21:47:17.120493000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669547490 TSecr=36864829 WS=128 690 21:47:18.928453000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36867840 TSecr=0 WS=64 691 21:47:18.928477000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669549297 TSecr=36864829 WS=128 704 21:47:19.320497000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669549690 TSecr=36864829 WS=128 816 21:47:23.320494000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669553690 TSecr=36864829 WS=128 904 21:47:24.944675000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36873856 TSecr=0 WS=64 905 21:47:24.944691000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669555314 TSecr=36864829 WS=128 1171 21:47:31.520497000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669561890 TSecr=36864829 WS=128 1368 21:47:36.977082000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36885888 TSecr=0 WS=64 1369 21:47:36.977120000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669567346 TSecr=36864829 WS=128 1823 21:47:47.920502000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669578290 TSecr=36864829 WS=128 2262 21:48:01.041897000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36909952 TSecr=0 WS=64 2263 21:48:01.041918000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669591411 TSecr=36864829 WS=128 5861 21:48:49.171584000 192.168.1.129 192.168.1.14 TCP 74 [TCP Retransmission] 870 > nfs [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=36958080 TSecr=0 WS=64 5862 21:48:49.171609000 192.168.1.14 192.168.1.129 TCP 74 [TCP Previous segment not captured] nfs > 870 [SYN, ACK] Seq=1457079676 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669639541 TSecr=36958080 WS=128 6225 21:48:50.574490000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=1457079676 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669640944 TSecr=36958080 WS=128 6527 21:48:52.574490000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=1457079676 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669642944 TSecr=36958080 WS=128 7470 21:48:56.574493000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=1457079676 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669646944 TSecr=36958080 WS=128 8263 21:49:04.774494000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=1457079676 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669655144 TSecr=36958080 WS=128 9049 21:49:20.774494000 192.168.1.14 192.168.1.129 TCP 74 [TCP Retransmission] nfs > 870 [SYN, ACK] Seq=1457079676 Ack=1 Win=14480 Len=0 MSS=1460 SACK_PERM=1 TSval=669671144 TSecr=36958080 WS=128 See? The laptop, with both firewalls down, does not see those packages. And I'm working all the time remotely from the deskop on the laptop, no network problems detected. I have pings running all the time from both sides, no losses. Those packages are removed intentionally by something. Quick test. The router has no disk plugged in, so it should be disabled. It does not support nfs. I disable "storage sharing" (samba). I disable FTP and media server. And print server. All off. Try nfs connect from the laptop... failure. Ok, so the nfs tcp packages from the laptop fails. If it was a generalized failure, nfs udp packages would be lost, too, and I have sendt and received many megabytes over it yesterday, over nfs 3. Or tcp packages from other services. It makes no sense :-/ - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHjBhYACgkQtTMYHG2NR9U8WgCgicG08CcU8Tn8g7IT495SIhQC doUAoIPcvY2XP5a3GOP7rruZb8Ifz9x3 =ZA3M -----END PGP SIGNATURE-----
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-07-14 at 22:11 +0200, Carlos E. R. wrote: ...
I restarted the test that was running with ipraf with both firewalls down. I see no difference, but I have to wait the 3 minutes timeout.
...
Ok, capture on laptop:
...
And on the server:
...
See? The laptop, with both firewalls down, does not see those packages. And I'm working all the time remotely from the deskop on the laptop, no network problems detected. I have pings running all the time from both sides, no losses.
Those packages are removed intentionally by something.
...
Ok, so the nfs tcp packages from the laptop fails. If it was a generalized failure, nfs udp packages would be lost, too, and I have sendt and received many megabytes over it yesterday, over nfs 3. Or tcp packages from other services. It makes no sense :-/
The laptop was connected via wifi, the server on cable; the wifi packages go through the router cpu part, the cable only over the switch part of the box. Now, I have connected the laptop on cable, firewalls up, and tried: instant connection, nfs version 4: minas-tirith:~ # date --rfc-3339=seconds ; time mount -v /var/cache/zypp/nfs_packages/ ; date --rfc-3339=seconds 2013-07-17 20:18:31+02:00 mount.nfs: timeout set for Wed Jul 17 20:20:31 2013 mount.nfs: trying text-based options 'vers=4,addr=192.168.1.14,clientaddr=192.168.1.130' 192.168.1.14:/data/storage_c/repositorios_zypp/ on /var/cache/zypp/nfs_packages type nfs (rw,noauto) real 0m0.566s user 0m0.001s sys 0m0.006s 2013-07-17 20:18:31+02:00 minas-tirith:~ # Thus, it is the router fault. The router wifi eats SYN ACK 870 :-( [...] Well, now it works on wifi too. :-O I did two things. One, I rebooted this morning, to Windows (twice), and to openSUSE 11.4 again. Then, I removed two routing entries: In the desktop, a rule pointing to the laptop: minas-tirith.va router 255.255.255.255 UGH 0 0 0 eth0 In the laptop, the reverse one: Tecontar.valin router.valinor 255.255.255.255 UGH 0 0 0 wlan0 These were absolutely necesary with my previous router, there was no connection without it. But the new router, contrary to my thoughts, doesn't, and in fact, breaks. Why it breaks eating some packages, I can not imagine. So, now, nfs4 works, with tcp, instantly! minas-tirith:~ # date --rfc-3339=seconds ; time mount -v /var/cache/zypp/nfs_packages/ ; date --rfc-3339=seconds 2013-07-17 21:05:58+02:00 mount.nfs: timeout set for Wed Jul 17 21:07:58 2013 mount.nfs: trying text-based options 'vers=4,addr=192.168.1.14,clientaddr=192.168.1.129' 192.168.1.14:/data/storage_c/repositorios_zypp/ on /var/cache/zypp/nfs_packages type nfs (rw,noauto) real 0m0.091s user 0m0.003s sys 0m0.007s 2013-07-17 21:05:58+02:00 minas-tirith:~ # - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHm7B8ACgkQtTMYHG2NR9WfPACcDJjdxMHkmhRIpfQW8G+LBHlI RmYAn25kGzj3f6ghCP+niEi0/6Rzue4U =jX5F -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/247f3737bfdd07c80a5411399e9a504c.jpg?s=120&d=mm&r=g)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Situation:
Some machines can mount a share, others can not.
For example, I can mount the share on a 12.3 host with a 12.3, acting as nfsserver, with a 12.3 guest in vmplayer, acting as nfs client.
However, the same host machine can not mount it localy to itself (nfs client); neither can my laptop (network is fine: I can ping and ssh).
Server exports entry (one single line, wrapped here for clarity):
/data/storage_c/repositorios_zypp/ \
192.168.1.0/24(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure) \
172.16.108.0/24(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure) \
192.168.74.0/24(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure) \
127.0.0.1(fsid=1234,rw,no_root_squash,nohide,no_subtree_check,insecure)
I stopped reading here. IIRC, fsid numbers have to be different for each filesystem. I'm no expert on it but I remember it from a previous forum discussion. If that doesn't fix it, I also note
telcontar.valinor:/data/storage_c/repositorios_zypp /var/cache/zypp/nfs_packages nfs4 defaults 0 0
I would make sure that nfs4 is not used and nfs3 is explicitly used everywhere. If that fixes it, you could try using nfs4 everywhere or just somewhere and play around until you understand what breaks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-07-11 at 13:59 +0100, Dave Howorth wrote:
I stopped reading here. IIRC, fsid numbers have to be different for each filesystem. I'm no expert on it but I remember it from a previous forum discussion.
But it is the same filesystem, and as proved later, that is not the problem.
If that doesn't fix it, I also note
telcontar.valinor:/data/storage_c/repositorios_zypp /var/cache/zypp/nfs_packages nfs4 defaults 0 0
I would make sure that nfs4 is not used and nfs3 is explicitly used everywhere. If that fixes it, you could try using nfs4 everywhere or just somewhere and play around until you understand what breaks.
nfs3 is not accepted as valid syntax when I tried. Notice that: Server import entry - was not working: localhost:/data/storage_c/repositorios_zypp/ /mnt/nfs/tmp nfs defaults 0 0 vmplayer guest; fstab entry - was working: telcontar.valinor:/data/storage_c/repositorios_zypp /var/cache/zypp/nfs_packages nfs4 defaults 0 0 Notice that the machine that was not working, localhost, was not working because it wanted to use IPv6, and ::1 was not listed in the exports file - - so version 4 versus version 3 is not the problem, so far. The machine that now is not working, my laptop (details on another post) fails because the server does not even listen to the conection attempt, there is no network response packet. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlHfoZ4ACgkQtTMYHG2NR9UKQwCeIcAFPWZrn6dY2faANxCCnZXi gWQAn0Cw0PmZsiVMKHbKrwYIVhEhRJgi =fhtp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrey Borzenkov
-
Carlos E. R.
-
Carlos E. R.
-
Dave Howorth