First, please show us your firewall rules.
NFSv3 on TCP probably fails because it needs more than port 2049 (and 111) to be open.
NFSv3 on UDP is trying to connect on port 56021, and succeeds, so it looks like UDP is completely open.
IMO neither of these explain the NFSv4 problems - but perhaps seeing your firewall rules will help.
In fact both vero and nas are currently on the same network, so no firewall. I need to make NFSv4 to work first, so that I only have to open port 2049 on firewall. While this does not work, it makes no sense to try the firewall.
Agreed. Ensure that there are no iptables rules on the Ubuntu server.
Thanks, no iptables on my NAS:
$ sudo iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destinationIs there anywhere a nfsmount.conf configured on the Vero?
no such file on my vero
Hi,
mount.nfs4 -V
mount.nfs4: (linux nfs-utils 1.3.3)
osmc@osmc4k:~$ cksum /sbin/mount.nfs4
761036281 72292 /sbin/mount.nfs4
osmc@osmc4k:~$ cksum /sbin/mount.nfs
761036281 72292 /sbin/mount.nfs
osmc@osmc4k:~$ mount -V
mount from util-linux 2.29.2 (libmount 2.29.2: selinux, btrfs, assert, debug)
osmc@osmc4k:~$ cksum /bin/mount
4171541951 30832 /bin/mount
Linux osmc4k 3.14.29-117-osmc #1 SMP Mon Sep 3 00:16:47 UTC 2018 aarch64 GNU/Linux
Thanks Tom.
Hi,
Could you please also check this on the vero4k+ ?
Thanks Tom.
I can reproduce the problem. Will investigate further and report back.
No iptables rules on vero.
I’ve not found the root cause yet but I dusted off an Ubuntu 18.04 server image and ran this on my V4K:
osmc@osmc-4k:~$ sudo mount -v -t nfs -o nvsvers=4 192.168.8.9:/tmp /mnt/test
mount.nfs: timeout set for Tue Oct 16 19:36:12 2018
mount.nfs: trying text-based options 'nvsvers=4,vers=4.2,addr=192.168.8.9,clientaddr=192.168.8.32'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'nvsvers=4,vers=4.1,addr=192.168.8.9,clientaddr=192.168.8.32'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'nvsvers=4,vers=4.0,addr=192.168.8.9,clientaddr=192.168.8.32'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'nvsvers=4,addr=192.168.8.9'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.8.9 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.8.9 prog 100005 vers 3 prot UDP port 41116
mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified
so far, the same as you. Then I removed the -o nfsvers=4 bit:
osmc@osmc-4k:~$ sudo mount -v -t nfs 192.168.8.9:/tmp /mnt/test
mount.nfs: timeout set for Tue Oct 16 19:37:16 2018
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.8.9,clientaddr=192.168.8.32'
osmc@osmc-4k:~$ mount|grep test
192.168.8.9:/tmp on /mnt/test type nfs4 (rw,relatime,vers=4.2,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.8.32,local_lock=none,addr=192.168.8.9)
It picks up version 4.2!
Can you tell me if it also works with you?
OK, I need to 'fess up. @Tom_Doyle has pointed out a typo in my command, nvsvers=4 that caused the errors in my case.
Does not work for me
osmc@osmc:~$ sudo mount -v -t nfs 10.0.0.3:/export/video1 /mnt/video1
mount.nfs: timeout set for Tue Oct 16 21:04:31 2018
mount.nfs: trying text-based options 'vers=4.2,addr=10.0.0.3,clientaddr=10.0.0.240'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.1,addr=10.0.0.3,clientaddr=10.0.0.240'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'vers=4.0,addr=10.0.0.3,clientaddr=10.0.0.240'
mount.nfs: mount(2): Invalid argument
mount.nfs: trying text-based options 'addr=10.0.0.3'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.3 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.0.0.3 prog 100005 vers 3 prot UDP port 56021Yeah, sorry about that. Digital interference and dodgy eyesight, I’m afraid.
You could always see if reinstalling the nfs client software will fix things, since it’s under the impression that it’s getting an invalid argument:
sudo apt-get install --reinstall nfs-common
If that doesn’t work, you can also look here and enable NFS server debugging (under Troubleshooting). Just editing /etc/default/nfs-kernel-server should do for now. Try to connect from the Vero4K and then provide the NFS-related messages from the Ubuntu system journal.
Hi,
I’ve managed to reproduce your issue with 18.04, but I’ve been unable to find a fix. From googling I found a number of similar reports, and some reporting it used to work with no issue on 16.04. So I’ve tested this as well:
osmc@osmc4k:~$ sudo mount -v -t nfs4 192.168.1.161:/mnt/test /mnt/test
mount.nfs4: timeout set for Tue Oct 16 22:13:48 2018
mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.1.161,clientaddr=192.168.1.9'
osmc@osmc4k:~$ mount|grep test
192.168.1.161:/mnt/test on /mnt/test type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.9,local_lock=none,addr=192.168.1.161)
So it seems to work as expected with 16.04 but not 18.04, which would suggest a bug or at least something missing on 18.04. As for why it works with ubuntu clients, I can only guess that ubuntu are aware of the issue; and issued the clients with a work a round. I’m out of time for today, but I will try and find some time to work out what the issue with 18.04 is. In mean time I would suggest raising a bug report with Ubuntu, or at least checking the tracker for similar issues:
@dillthedog being as you’ve had some success with nsf4 on 18.04, could you please lets us know your server side setup?
Thanks Tom.
Ubuntu 18.04 will have a newer kernel version. Something might have changed there.
I’m not quite sure what you need. It’s an Ubuntu 18.04 server VM:
Linux zm130 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
that’s fully up to date. The /etc/exports file contains one line:
/tmp 192.168.8.0/24(ro,sync,no_subtree_check)
With NFS server debug enabled, I see these lines in the Ubuntu sys journal when connecting:
Oct 16 22:06:51 zm130 rpc.mountd[3358]: auth_unix_ip: inbuf 'nfsd 192.168.8.32'
Oct 16 22:06:51 zm130 rpc.mountd[3358]: auth_unix_ip: client 0x562585474cc0 '192.168.8.0/24'
Oct 16 22:06:51 zm130 rpc.mountd[3358]: nfsd_export: inbuf '192.168.8.0/24 /'
Oct 16 22:06:51 zm130 rpc.mountd[3358]: nfsd_export: found 0x562585454dc0 path /
Oct 16 22:06:51 zm130 rpc.mountd[3358]: nfsd_export: inbuf '192.168.8.0/24 /tmp'
Oct 16 22:06:51 zm130 rpc.mountd[3358]: nfsd_export: found 0x56258546cd40 path /tmp
Hi,
pretty much the same setup, other than I used an rw export, same kernel.
did you just setup with:
apt-get install apt-get install nfs-kernel-server
Or did you specify any other packages?
Thanks Tom.
The VM was upgraded from 16.04 to 18.04 a few months ago but, other than that, it should be pretty vanilla. And yes, I did install (just) the nfs-kernel-server package for this testing; it wasn’t there before.
So if I understand well we have 3 people with following results (vero4k + Ubuntu Server 18.04):
glypto and Tom: nfsv4 does NOT work
dillthedog: nfs4 does work
I wonder whether the fact that dillthedog has upgraded Ubuntu Server from 16.04 to 18.04 while in my case it was new 18.04 install has to do something with the results. Also dillthedog seems to be using VM while I have bare metal install…
I’ll try to do nfs server debug in the evening.
Hi,
I used a new install of 18.04 for my testing. My current thinking is that under 16.04 an additional package is installed when installing nfs-kernel-server, which is there and updated when upgrading to 18.04; but is not present with a fresh install of 18.04. I’m going to compare the apt history this evening.
Thanks Tom.