You are not logged in.

#1 2015-02-18 10:03:00

kabads
Member
Registered: 2012-09-22
Posts: 271
Website

nfs file share problems

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

#2 2015-02-18 10:29:05

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,597
Website

Re: nfs file share problems

Is rpcbind running and enabled?


CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#3 2015-02-18 10:41:52

kabads
Member
Registered: 2012-09-22
Posts: 271
Website

Re: nfs file share problems

There is a thread for rpcbind:

[adam@atomic ~]$ ps -A|grep rpcbind
  376 ?        00:00:00 rpcbind

Offline

#4 2015-02-18 12:32:13

alphaniner
Member
From: Ancapistan
Registered: 2010-07-12
Posts: 2,810

Re: nfs file share problems

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

#5 2015-02-18 12:43:25

kabads
Member
Registered: 2012-09-22
Posts: 271
Website

Re: nfs file share problems

[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

#6 2015-02-18 13:05:40

alphaniner
Member
From: Ancapistan
Registered: 2010-07-12
Posts: 2,810

Re: nfs file share problems

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

#7 2015-02-18 13:12:56

kabads
Member
Registered: 2012-09-22
Posts: 271
Website

Re: nfs file share problems

[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

#8 2015-02-18 13:13:29

kabads
Member
Registered: 2012-09-22
Posts: 271
Website

Re: nfs file share problems

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

#9 2015-02-18 20:34:50

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,597
Website

Re: nfs file share problems

What is the output of:

# systemctl status rpcbind.service
# systemctl status nfs-server.service

CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#10 2015-02-18 22:28:53

kabads
Member
Registered: 2012-09-22
Posts: 271
Website

Re: nfs file share problems

[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

#11 2015-02-24 23:10:28

jeffro-tull
Member
Registered: 2008-09-25
Posts: 17

Re: nfs file share problems

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

#12 2015-02-25 17:42:27

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: nfs file share problems

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

#13 2015-02-25 22:08:00

jeffro-tull
Member
Registered: 2008-09-25
Posts: 17

Re: nfs file share problems

R00KIE wrote:

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

#14 2015-02-25 22:25:23

alphaniner
Member
From: Ancapistan
Registered: 2010-07-12
Posts: 2,810

Re: nfs file share problems

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

#15 2015-02-26 01:39:11

jeffro-tull
Member
Registered: 2008-09-25
Posts: 17

Re: nfs file share problems

alphaniner wrote:

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

#16 2015-02-26 10:22:53

R00KIE
Forum Fellow
From: Between a computer and a chair
Registered: 2008-09-14
Posts: 4,734

Re: nfs file share problems

jeffro-tull wrote:

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

#17 2015-02-26 14:09:52

jeffro-tull
Member
Registered: 2008-09-25
Posts: 17

Re: nfs file share problems

R00KIE wrote:

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

Board footer

Powered by FluxBB