14

I'm trying to mount an NFS volume on a centos 7.2 server:

When I try to mount the NFS share point, this is the response I get back:

[root@web1:~] #mount -t nfs nfs1.example.com:/var/nfs/home /home
mount.nfs: an incorrect mount option was specified

I checked and I have nfs-utils-1.3.0-0.21.el7.x86_64 installed on both machines. Both the nfs client and the nfs server OSes are Centos 7.2

To troubleshoot this, I reduced the listings in the /etc/exports file on the NFS server to just the following:

/var/nfs/home web1.example.com(rw,sync,no_root_squash,no_all_squash)

If I do a showmount from the server I'm trying to mount the nfs share on, this is what I see:

[root@web1:~] #showmount -e nfs1.example.com
Export list for nfs1.example.com:
/var/nfs/home web1.example.com

If I do a mount -v this is what I get:

[root@web1:~] #mount -v -t nfs nfs1.example.com:/var/nfs/home /home
mount.nfs: timeout set for Fri Jan 13 11:04:19 2017 mount.nfs: trying text-based options 'vers=4,addr=162.xxx.xxx..94,clientaddr=162.xxx.xxx.6'
mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified

In dmesg I find:

[44428.405419] nfsd: last server has exited, flushing export cache

And I'm seeing this in dmesg:

[ 7.373186] FS-Cache: Netfs 'nfs' registered for caching
[ 7.422181] Key type dns_resolver registered
[ 7.456581] NFS: Registering the id_resolver key type
[ 7.462309] Key type id_resolver registered
[ 7.462386] Key type id_legacy registered
[ 7.514441] SELinux: initialized (dev 0:40, type nfs4), uses genfs_contexts
[ 8.474503] NFSD: starting 90-second grace period (net ffffffff819a29c0) –
[ 16.952180] perf samples too long (2623 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[ 24.429251] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 38.368207] perf samples too long (5162 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[ 38.427323]

Not specifying -t nfs in the command gives the same result:

[root@nfs1:~] #mount nfs1.example.com:/var/nfs/home /home
mount.nfs: an incorrect mount option was specified

These are the nfs file systems I have:

[root@nfs1:~] #grep nfs /proc/filesystems
nodev   nfsd
nodev   nfs
nodev   nfs4

Here are the modules loaded for nfs:

[root@nfs1:~] #lsmod | grep ^nfs
nfsv4                 474203  0
nfs                   241266  1 nfsv4
nfsd                  284378  13
nfs_acl                12837  1 nfsd

It's not a firewall issue because I get the same exact failure when I run the mount command from the NFS server itself. It gets the same error that it's clients do.

I should stress that this did at one time work fine. But now it's broken to the point where it can't be used.

Can someone please help me troubleshoot this? I'm really stuck at this point.

  • It occurred to me your problem might be related to firewall rules. Can you post the output of firewall-cmd --query-service=nfs --query-service=mountd --query-service=rpc-bind from the NFS server? – virtex Jan 16 '17 at 18:19
  • 1
    Strictly speaking 'Permissive' is not disabled, and will still generate SELinux messages - but SELinux will not deny anything in Permissive. In that mode you can ignore any denied's in the logs. – Jason Martin Jan 16 '17 at 19:24
  • Jason Martin got it! Thanks for the clue in on SELinux. – user99201 Jan 16 '17 at 19:50
  • 3
    Please run rpcdebug -m nfs -s mount remount again then print whatever comes out of dmesg. Then run rpcdebug -m nfs -c mount. This sounds like a parsing error, possibly due to bad overrides in nfsmount.conf - it should show up though if you do that in the kernel dmesg. – Matthew Ife Jan 16 '17 at 21:36
  • Do you have rpcbind installed on the machine which provides the share? – 13dimitar Jan 17 '17 at 10:14
5

Hit the same issue today. I stumbled upon option nfsvers when searching for an explanation. Mounting worked with nfsvers=3 and nfsvers=4. I'd be glad for more detailed explanation though.

root@localhost:~# uname -rm
4.1.15 armv7l
root@localhost:~# mount -t nfs 10.0.0.5:/srv/nfs tmp
mount.nfs: an incorrect mount option was specified
root@localhost:~# mount -t nfs -o nfsvers=1 10.0.0.5:/srv/nfs tmp
mount.nfs: mount system call failed
root@localhost:~# mount -t nfs -o nfsvers=2 10.0.0.5:/srv/nfs tmp
mount.nfs: requested NFS version or transport protocol is not supported
root@localhost:~# mount -t nfs -o nfsvers=3 10.0.0.5:/srv/nfs tmp
root@localhost:~# mount -t nfs -o nfsvers=4 10.0.0.5:/srv/nfs tmp
root@localhost:~#

Last two commands succeeded.

| improve this answer | |
1

I found this issue today on Tiny Core Linux, turned out to be the fact that the nfs client service hadn't been started. Once I started that service (/usr/local/etc/init.d/nfs-client start) the NFS export mounted without issue.

| improve this answer | |
  • 1
    /usr/local/etc looks like incorrect installation of nfs-client as the file should be in /etc/init.d and linked to appropriate /etc/rc?.d to start automatically. – Jan Hudec Sep 3 '19 at 8:25
  • @JanHudec yes, on a normal distro, but the architecture of Tiny Core doesn't allow for this. We could argue standards until the cows come home, but JeOS flies in the face of standards as it is. – Aaron Mason Sep 3 '19 at 22:38
0

On Centos 7 restarting nfs-client systemd service unit resolved this problem for me:

systemctl restart nfs-client.service
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.