You are not logged in.
I'm having a recent problem with an nfs server - it used to serve files fine, and still does with another machine. However, now a different client won't pick up the share.
On the client, I've got
[adam@atomic ~]$ showmount -e 192.168.1.156
Export list for 192.168.1.156:
/srv/nfs4/video 192.168.1.0/24
but when I try and mount with fstab
[adam@atomic ~]$ sudo mount -a
[adam@atomic ~]$
I get nothing but an empty directory.
If I try and do it by hand, I get:
[adam@atomic ~]$ sudo mount -t nfs 192.168.1.156:/srv/nfs4/video /home/adam/disk3
mount.nfs: an incorrect mount option was specified
The kernel module is loaded:
[adam@atomic ~]$ lsmod |grep nfs
nfsd 235253 1
I'm running out of ideas and have seem to hit a wall. Any ideas for what I can look at next?
Offline
Is rpcbind running and enabled?
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
There is a thread for rpcbind:
[adam@atomic ~]$ ps -A|grep rpcbind
376 ? 00:00:00 rpcbind
Offline
What happens if you 'mount -t nfs4' instead of 'mount -t nfs'?
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
[adam@atomic ~]$ sudo mount -t nfs4 192.168.1.156:/srv/nfs4/video /home/adam/disk3
mount.nfs4: an incorrect mount option was specified
Offline
Ok, see if adding some verbosity helps. The '-v' flag can be used multiple times to increase verbosity. I don't know if it's a hard rule, but I think I've never seen anything more than is provided by '-vvv'.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
[adam@atomic ~]$ sudo mount -vvv -t nfs 192.168.1.156:/srv/nfs4/video /home/adam/disk3
[sudo] password for adam:
mount.nfs: timeout set for Wed Feb 18 13:14:22 2015
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.156,clientaddr=192.168.1.99'
mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified
Offline
I have checked the time on each system and they are the same (and it looks like they are controlled by some kind of ntp).
Offline
What is the output of:
# systemctl status rpcbind.service
# systemctl status nfs-server.service
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
[root@alarmpi ~]# systemctl status rpcbind.service
* rpcbind.service - RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: disabled)
Active: active (running) since Wed 2015-02-18 09:50:03 UTC; 12h ago
Process: 7777 ExecStart=/usr/bin/rpcbind -w ${RPCBIND_ARGS} (code=exited, status=0/SUCCESS)
Main PID: 7778 (rpcbind)
CGroup: /system.slice/rpcbind.service
`-7778 /usr/bin/rpcbind -w
Feb 18 09:50:03 alarmpi systemd[1]: Started RPC bind service.
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
[root@alarmpi ~]# systemctl status nfs-server.service
* nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; disabled; vendor preset: disabled)
Active: active (exited) since Tue 2015-02-17 22:55:45 UTC; 23h ago
Process: 1160 ExecStopPost=/usr/sbin/exportfs -f (code=exited, status=0/SUCCESS)
Process: 1155 ExecStopPost=/usr/sbin/exportfs -au (code=exited, status=0/SUCCESS)
Process: 1152 ExecStop=/usr/sbin/rpc.nfsd 0 (code=exited, status=0/SUCCESS)
Process: 1168 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS)
Process: 1166 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
Main PID: 1168 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/nfs-server.service
Feb 17 22:55:45 alarmpi systemd[1]: Started NFS server and services.
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
Offline
I'm having the same issue. Trying to mount my current server (serverbox) with its replacement (alarm) to move things over. My laptops (jeffro-e420 and jeffro-one) can successfully mount the server, but alarm can't.
Here's some output from the server:
[root@serverbox jeffro]# systemctl status rpcbind.service
* rpcbind.service - RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: disabled)
Active: active (running) since Mon 2015-02-23 19:44:51 EST; 22h ago
Process: 264 ExecStart=/usr/bin/rpcbind -w ${RPCBIND_ARGS} (code=exited, status=0/SUCCESS)
Main PID: 265 (rpcbind)
CGroup: /system.slice/rpcbind.service
`-265 /usr/bin/rpcbind -w
[root@serverbox jeffro]# systemctl status nfs-server.service
* nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; vendor preset: disabled)
Active: active (exited) since Mon 2015-02-23 19:44:53 EST; 22h ago
Process: 289 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS)
Process: 277 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
Main PID: 289 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/nfs-server.service
And some output from (what I hoped would be) the client:
[jeffro@alarm ~]$ showmount -e serverbox
Export list for serverbox:
/srv/nfs4/seagate 192.168.1.0/24
/srv/nfs4 192.168.1.0/24
[root@alarm jeffro]# mount -vvv -t nfs serverbox:/seagate /mnt/sb/
mount.nfs: timeout set for Tue Feb 24 18:10:33 2015
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.107,clientaddr=192.168.1.123'
mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified
[root@alarm jeffro]# mount -vvv -t nfs serverbox:/srv/nfs4/seagate /mnt/sb/
mount.nfs: timeout set for Tue Feb 24 18:11:16 2015
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.107,clientaddr=192.168.1.123'
mount.nfs: mount(2): Invalid argument
mount.nfs: an incorrect mount option was specified
[root@alarm jeffro]# mount -vvv -t nfs4 serverbox:/seagate /mnt/sb/
mount.nfs4: timeout set for Tue Feb 24 18:08:12 2015
mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.1.107,clientaddr=192.168.1.123'
mount.nfs4: mount(2): Invalid argument
mount.nfs4: an incorrect mount option was specified
[root@alarm jeffro]# mount -vvv -t nfs4 serverbox:/srv/nfs4/seagate /mnt/sb/
mount.nfs4: timeout set for Tue Feb 24 18:09:28 2015
mount.nfs4: trying text-based options 'vers=4.2,addr=192.168.1.107,clientaddr=192.168.1.123'
mount.nfs4: mount(2): Invalid argument
mount.nfs4: an incorrect mount option was specified
[root@alarm jeffro]# systemctl status rpcbind.service
* rpcbind.service - RPC bind service
Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; indirect; vendor preset: disabled)
Active: active (running) since Mon 2015-02-23 20:37:24 EST; 21h ago
Main PID: 317 (rpcbind)
CGroup: /system.slice/rpcbind.service
`-317 /usr/bin/rpcbind -w
Feb 23 20:37:24 alarm systemd[1]: Starting RPC bind service...
Feb 23 20:37:24 alarm systemd[1]: Started RPC bind service.
[root@alarm jeffro]# systemctl status nfs-server.service
* nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; disabled; vendor preset: disabled)
Active: active (exited) since Tue 2015-02-24 17:31:57 EST; 30min ago
Main PID: 454 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/nfs-server.service
Feb 24 17:31:57 alarm systemd[1]: Started NFS server and services
For what I'm trying to do, I can work around this, but I'd definitely like to know what's going on. Thanks.
Offline
Try with 'mount -t nfs4 -o vers=4.1' or 'mount -t nfs4 -o vers=4' is the first one doesn't work.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Try with 'mount -t nfs4 -o vers=4.1' or 'mount -t nfs4 -o vers=4' is the first one doesn't work.
That did the trick! It took about five seconds, but it worked.
[root@alarm jeffro]# mount -vvv -t nfs4 -o vers=4 serverbox:/seagate /mnt/sb/
mount.nfs4: timeout set for Wed Feb 25 17:03:25 2015
mount.nfs4: trying text-based options 'addr=192.168.1.107,clientaddr=192.168.1.123'
[root@alarm jeffro]# mount
....
serverbox:/seagate on /mnt/sb type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.123,local_lock=none,addr=192.168.1.107)
vers=4.1 also worked. A bug in NFS 4.2, perhaps? Hmm....
Offline
Maybe relevant to the slowness issue.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Maybe relevant to the slowness issue.
Hit the nail on the head. Thanks!
Regarding the original issue, I noticed that the OP's server looks to be a Raspberry Pi. My client is an ODROID-C1. I guess I'm just curious if this is an Arch Linux Arm issue, an Arch Linux proper issue, or an NFS issue. *shrugs*
Offline
Regarding the original issue, I noticed that the OP's server looks to be a Raspberry Pi. My client is an ODROID-C1. I guess I'm just curious if this is an Arch Linux Arm issue, an Arch Linux proper issue, or an NFS issue. *shrugs*
Not sure how you got to that conclusion but you are probably right. I have an rpi as server with archarm and use a x86_64 arch as client and I don't see this problem, however if I use a cubieboard2 (cb2) with arch as client I see this.
I have no idea why on the cb2 the nfsclient tries to use version 4.2 while on x86 it is using 4.1. The rpi supports only version 4.1, if I had to file a bug report it would be with archarm not arch. On the other hand this came in handy to be able to connect to a nfs server on a centos5 machine I use, which supports only version 4.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Not sure how you got to that conclusion but you are probably right
I noticed the host names of his machines, one of which was "alarmpi". Arch Linux Arm seems to like using the acronym "alarm" (or some permutation thereof) as a default hostname.
I could be way off base there, but it just seemed to me like the common denominator between the OP and I.
Offline