Weird NFS problem

t0ken

t0ken

Server: FreeBSD 8.1-RELEASE-p2 on ZFS (using zfs exports, not firewalled)
Client: Arch Linux

This just began happening a few days ago and seems to come and go. On my client (arch linux laptop), I get the following when trying to mount an NFS share from my 8.1-p2 server:

Code: 
[andre@dlaptop ~]# sudo mount -v /mnt/nas
mount.nfs: timeout set for Fri Feb 25 16:19:15 2011
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,vers=4,addr=10.0.0.98,clientaddr=10.0.0.102'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,vers=4,addr=10.0.0.98,clientaddr=10.0.0.102'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,vers=4,addr=10.0.0.98,clientaddr=10.0.0.102'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,vers=4,addr=10.0.0.98,clientaddr=10.0.0.102'
mount.nfs: mount(2): Connection refused


The above is only AFTER I forced the FreeBSD server to user version 4 by adding the following to /etc/rc.conf:

Code: 
nfs_server_flags="-u -t -n 4 -e"


BEFORE, the above change, I was getting:

Code: 
[andre@dlaptop ~]sudo mount -v /mnt/nas
mount.nfs: timeout set for Fri Feb 25 16:15:24 2011
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,vers=4,addr=10.0.0.98,clientaddr=10.0.0.102'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,addr=10.0.0.98'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.98 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.0.0.98 prog 100005 vers 3 prot UDP port 809
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,vers=4,addr=10.0.0.98,clientaddr=10.0.0.102'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'soft,rsize=8192,wsize=8192,addr=10.0.0.98'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 10.0.0.98 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 10.0.0.98 prog 100005 vers 3 prot UDP port 809
mount.nfs: mount(2): Connection refused


Anyone else been having problems with NFS lately? I haven't updated or made any changes to the NFS configuration, it's frustrating trying to figure out why this began happening. I've tried restarting all services, going to sysinstall and disabling NFSv3 (though it just appears to return after I exit...not sure if this has anything to do with it). I'm not running a firewall on the server.

I thought that this may have something to do with Arch because I noticed the problem after a recent update, but I just tested my Fedora install on a different computer (my desktop) and it's throwing the same "connection refused" error.

I think this may have something to do with the NFS versioning...but who knows. Any tips would be appreciated.
 
Via rc.conf, pretty sure when I set it up I'd copy & pasted that part from the handbook. Here's the requested info, thanks!:

Code: 
#Enable NFS server with locking
rpcbind_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 8 -e"
mountd_enable="YES"
mountd_flags="-r"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

Code: 
[root@daemon ~]# rpcinfo
   program version netid     address                service    owner
    100000    4    tcp       0.0.0.0.0.111          rpcbind    superuser
    100000    3    tcp       0.0.0.0.0.111          rpcbind    superuser
    100000    2    tcp       0.0.0.0.0.111          rpcbind    superuser
    100000    4    udp       0.0.0.0.0.111          rpcbind    superuser
    100000    3    udp       0.0.0.0.0.111          rpcbind    superuser
    100000    2    udp       0.0.0.0.0.111          rpcbind    superuser
    100000    4    local     /var/run/rpcbind.sock  rpcbind    superuser
    100000    3    local     /var/run/rpcbind.sock  rpcbind    superuser
    100000    2    local     /var/run/rpcbind.sock  rpcbind    superuser
 
Your rpcinfo tells me that neither nfsd nor mountd are running. So far I never used NFS4, but from the manpage I would say that you have to put a "-e" to mountd_flags as well. Did you check /var/log/messages for rpc/nfs/mountd related stuff?
 
Actually I don't specifically need to use NFSv4. I really just wanted it to work and tried to force the user of NFSv4 in a (likely misguided) attempt to fix my problem -- I saw the 'protocol unsupported' and decided to focus on a resolution for that.

Thanks for the suggestions regarding /var/log/messages. I did look earlier but I didn't give it a hard enough look until you just suggested it again. I'm seeing this in the logs when running the following command (not sure if I need to restart each of these or only certain ones):
Code: 
[root@daemon ~]# /etc/rc.d/rpcbind restart ; /etc/rc.d/nfsd restart ; /etc/rc.d/mountd restart

Feb 25 19:19:45 daemon rpcbind: cannot create socket for udp6
Feb 25 19:19:45 daemon nfsd[8895]: Can't open /var/db/nfs-stablerestart
Feb 25 19:19:45 daemon mountd[8915]: can't delete exports for /nas/Videos/.zfs/snapshot/Feb21.1200: Invalid argument
Feb 25 19:19:45 daemon mountd[8915]: can't delete exports for /nas/Videos/.zfs/snapshot/Feb11.1200: Invalid argument
Feb 25 19:19:45 daemon mountd[8915]: can't delete exports for /nas/Videos/.zfs/snapshot/Feb22.1200: Invalid argument

I now believe the problem is from a few days ago when I made visible the above snapshot mentioned in the log. I ran
Code: 
zfs set snapdir=[visible|hidden] nas/Videos


I think I'm pretty close, just gotta resolve that mountd issue I'm sure. Thanks again
 
ian-nai said:
Are all of your nfs exports zfs?
Click to expand...


Yeah, definitely. I've read about being sure not to mix native and zfs exports.

This was resolved after I rebooted. I'd also read about others who've had problems after changing the 'snapdir' property to visible and then back to hidden so I may just shy away from doing so in the future.
 
You must log in or register to reply here.
Back
Top