15

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.

Anton Samsonov
  • 281
  • 1
  • 9
user99201
  • 287
  • 2
  • 8
  • 22
  • 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
  • Is there any error occurring in `/var/log/messages` or `/var/log/audit/audit.log` whilst doing the mount progress??? BTW, I recommend you give a whirl to `fsid=1`, just add it to your exports so it'll be like: `/var/nfs/home web1.example.com(rw,no_root_squash,no_all_squash,fsid=1,sync)`. If you're using vim editor, fsid will be red, don't you worry that's OK. After changing your `/etc/exports` file, restart nfs by `systemctl restart nfs`, and use `exportfs` command. Let us know if it works or if any log will be changed so we can puzzle out your problem with more ease. –  Jan 18 '17 at 05:41
  • @Dimitar Guess he's not willing to respond LOL. Server down! –  Jan 21 '17 at 08:04
  • @FarazX if rpcbind is not running he'll have the issue he's having. – 13dimitar Jan 21 '17 at 08:59
  • @Dimitar indeed mate, but unfortunately he's not responding. –  Jan 21 '17 at 09:19

4 Answers4

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.

woky
  • 245
  • 3
  • 10
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.

Aaron Mason
  • 703
  • 6
  • 20
  • 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 03 '19 at 08: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 03 '19 at 22:38
0

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

systemctl restart nfs-client.service
fg78nc
  • 136
  • 3
0

This is just a generic error message (also totally misleading), which points towards a problem in your client kerberos configuration, usually that the GSSAPI service isn't running. Try starting it, or if you have a nss-client.target, enable/start it.

Braiam
  • 642
  • 4
  • 23