NFS problems

[djjeffington]

Hi All,

I'd like to share files between two Fedora 14 systems, but I'm having difficulty with making a share accessible via NFS. Here's what I've tried so far:

NFS Server

cat /etc/exports shows
/data * (rw,sync)

Verified that /etc/hosts.deny is empty

Verified that nfs and rpcbind services are on in chkconfig

restarted nfs and rpcbind services

verified connectivity to client

NFS client

verified connectivity to server

Tried following mount commands:

[root@djjeff /]# mount -t nfs -o rw 192.168.1.115:/data /mnt/home
mount: wrong fs type, bad option, bad superblock on 192.168.1.115:/data,
missing codepage or helper program, or other error
(for several filesystems (e.g. nfs, cifs) you might
need a /sbin/mount.<type> helper program)
In some cases useful info is found in syslog - try
dmesg | tail or so

[root@djjeff /]# mount //192.168.1.115/data /mnt/home
Password:
Unable to find suitable address.
Used both the user and root password with this second mount command.

I feel like I'm missing something simple with this setup, but I'm stumped. Any ideas would be greatly appreciated. Thanks!

Jeff

[glennzo]

I believe that it should be mount -t nfs4 .....

Or maybe not. Works with just plain old nfs here. Do you need to run exportfs after making changes but before attempting to mount the share?

[gthill]

mount 192.168.1.115:/data /mnt/home

Note that you had incorrect syntax in your mount command.

If it still does not work, on the client
showmount -e 192.168.1.115
Will show you what mounts are available on the server

[SiliconSlick]

1) maybe a firewall issue... try disabling temporarily to see if that helps
2) be sure to reboot or run 'exportfs -rv' as glennzo suggested
3) check /var/log/messages on the server for possible error messags
and
4) just FYI for future reference: There is a _BIG_ difference between:

/data hostX(rw,sync)

and

/data hostX (rw,sync)

The former limits access to hostX with rw,sync options. However, the latter provides default options to hostX and rw,sync to EVERYONE ELSE ON THE NET. Note that that is not the cause of your connection issue here since your are restricting access to '*' (everyone) anyway, but be aware, that if the default mount mode is async (which it is), then what you have is granting async (not sync) connectivity. That one little space can make a big difference (as I have can attest to). If you really want it to be sync you need to get rid of the space between "*" and "(rw,sync)".

SS

[jpollard]

You can also test the server from both client and server with

rpcinfo -p <server>

It is not necessary to put the server name/IP number if you are on the server.

The results should be close to:

$ rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  47771  status
    100024    1   tcp  35372  status
    100011    1   udp    875  rquotad
    100011    2   udp    875  rquotad
    100011    1   tcp    875  rquotad
    100011    2   tcp    875  rquotad
    100021    1   udp  54156  nlockmgr
    100021    3   udp  54156  nlockmgr
    100021    4   udp  54156  nlockmgr
    100021    1   tcp  59673  nlockmgr
    100021    3   tcp  59673  nlockmgr
    100021    4   tcp  59673  nlockmgr
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049  nfs_acl
    100227    3   tcp   2049  nfs_acl
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049  nfs_acl
    100227    3   udp   2049  nfs_acl
    100005    1   udp  32987  mountd
    100005    1   tcp  44763  mountd
    100005    2   udp  32987  mountd
    100005    2   tcp  44763  mountd
    100005    3   udp  32987  mountd
    100005    3   tcp  44763  mountd

[djjeffington]

Hey Guys,

Thanks for all of the advice, but I still haven't had any luck so far. I rebooted the server, then disabled the Firewall and SELinux on both the client and server. I also disabled the firewall on my router. No luck. I can see the nfs shares when I run showmount -e 192.168.1.115 from the client, and portmapper and nfs appear to be running when I use the command rpcinfo -p 192.168.1.115.

I tried the mount command as suggested by gthill and had the following result:

[root@djjeff log]# mount 192.168.1.115:/data /mnt/home -v
mount: no type was given - I'll assume nfs because of the colon
mount.nfs: timeout set for Thu Feb 3 02:12:38 2011
mount.nfs: trying text-based options 'vers=4,addr=192.168.1.115,clientaddr=10.211.55.5'
mount.nfs: mount(2): Operation not permitted
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

I didn't see anything useful in /var/log/messages on the server, and I see the following on the client:

Feb 3 02:11:44 djjeff rpc.statd[2242]: Version 1.2.2 starting
Feb 3 02:11:44 djjeff rpc.statd[2242]: Flags: TI-RPC
Feb 3 02:11:44 djjeff rpc.statd[2242]: failed to create RPC listeners, exiting

Any more ideas?

I'm using the same username and password combo on both systems, is that possibly the source of my problems?

Thanks

Jeff

[gthill]

This looks like the first problem to source

mount.nfs: trying text-based options 'vers=4,addr=192.168.1.115,clientaddr=10.211.55.5'

googling "mount.nfs: trying text-based options" and looking for issues that are similar to yours might give you some leads.

Also, are the client server on different subnets, you may have a routing issue.

[jpollard]

Have you done "rpcinfo -p <server>" from the client?

[Xavior]

Mine says:
$ mount /sharedir
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

What is this, it shows rpc.statd running...

~Needs Help

---------- Post added at 11:45 AM ---------- Previous post was at 11:42 AM ----------

This was working fine, until I upgraded from F14 to F17....

# systemctl status nfs-lock.service
nfs-lock.service - NFS file locking service.
Loaded: loaded (/usr/lib/systemd/system/nfs-lock.service; enabled)
Active: active (running) since Fri, 26 Oct 2012 11:03:36 -0700; 39min ago
Process: 924 ExecStart=/sbin/rpc.statd $STATDARG (code=exited, status=0/SUCCESS)
Process: 916 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig (code=exited, status=0/SUCCESS)
Main PID: 926 (rpc.statd)
CGroup: name=systemd:/system/nfs-lock.service
└ 926 /sbin/rpc.statd

Oct 26 11:03:35 MyPC rpc.statd[926]: Version 1.2.6 starting

Any ideas?

[SiliconSlick]

1) I think forum decorum generally recommends you start a new thread when reporting new problems and not "hijacking" one that is over a year old.

2) That said... you might want to make sure statd/lockd are running on the NFS server (as opposed to the client). Just one thought...

SS (reaching for low-hanging fruit)

[jpollard]

Different problem.

Actually, looks like two problems.

1. According to the status it exited... The log file should show WHY it exited, but might not (the problem of systemd loosing error messages during startup)

2. If you are using NetworkManager, the network may not be ready for use. Have you enabled NetworkManager-wait-online.service ?

[Xavior]

Sorry about that, I forgot in my passion to find an answer, will start new post !
Thanks !