[SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

stefano · 2014-07-17 14:36:57

I seem to have encountered the same problem with the upgrade to nfs-utils, discussed in this solved thread:

https://bbs.archlinux.org/viewtopic.php?id=183444

(I originally asked the question on that thread yesterday, before realizing it's probably bad etiquette. Reasking here in a new thread)

The only difference is that I am mounting shares to an Ubuntu client from an Arch server.
Enabling nfs-server.service on the server's systemd, as suggested in the thread, failed to solve the issue.
Is there anything else I am supposed to do to restore mounting? I looked at /etc/conf.d/nfs-common but did not find it very informative, I must say.

Help appreciated.

Cheers,

Stefano

Last edited by stefano (2014-07-20 21:32:32)

alphaniner · 2014-07-17 15:34:03

Does everything look right from the server side? Eg. do you see your shares when you run exportfs? Can you mount the shares on the server?

# exportfs
/srv/nfs4     	199.200.1.0/24
/srv/nfs4/bin 	199.200.1.0/24
/srv/nfs4/pub 	199.200.1.0/24
/srv/nfs4/pkg 	199.200.1.0/24
/srv/nfs4/lin 	199.200.1.0/24
# mount -v 199.200.1.110:pub /mnt/test
mount.nfs: timeout set for Thu Jul 17 11:33:25 2014
mount.nfs: trying text-based options 'vers=4,addr=199.200.1.110,clientaddr=199.200.1.110'

stefano · 2014-07-18 13:17:04

Good suggestions. I pass the first test (exportfs), but I fail the second.

mount -v 192.168.0.4:/data /mnt/temp

shows the following:

mount.nfs: timeout set for Fri Jul 18 08:10:29 2014                                                               
mount.nfs: trying text-based options 'vers=4,addr=192.168.0.4,clientaddr=192.168.0.4'                             
mount.nfs: mount(2): Connection refused                                                                           
mount.nfs: trying text-based options 'addr=192.168.0.4'                                                           
mount.nfs: prog 100003, trying vers=3, prot=6                                                                     
mount.nfs: portmap query retrying: RPC: Program not registered                                                    
mount.nfs: prog 100003, trying vers=3, prot=17                                                                    
mount.nfs: portmap query failed: RPC: Program not registered                                                      
mount.nfs: requested NFS version or transport protocol is not supported

Unfortunately I know so little about nfs and networking in general thaty I can't figure out what is going wrong. Perhaps a version mismatch on nfs protocols?

alphaniner · 2014-07-18 13:20:42

It looks like nfs4 is tried first, but connection is refused so it falls back to nfs3. It might be helpful to see your /etc/exports and the output of exportfs .

Edit: I can't say for sure that it's valid, but the wiki indicates that nfs shares must reside in /srv .

Last edited by alphaniner (2014-07-18 13:23:11)

stefano · 2014-07-18 13:24:59

Here is the verbose output from exportfs:

[stefano@polus ~]$ sudo exportfs -v                                                                               
/data     192.168.0.0/24 (rw,wdelay,insecure,no_root_squash,no_subtree_check,mountpoint,sec=sys,rw,no_root_squash,no_all_squash)

my /etc/exports file is just one line long:

# /etc/exports

  /data       192.168.0.1/24(rw,fsid=root,no_subtree_check)

Spider.007 · 2014-07-18 13:32:05

Is rpcbind running on both server & client?

stefano · 2014-07-18 13:50:37

It is.

client:

stefano@cleinias:~$ ps aux | grep rpcbind                                                                         
root      1203  0.0  0.0  23420   296 ?        Ss   Jul15   0:00 rpcbind                                          
stefano  15238  0.0  0.0  11752   904 pts/14   S+   08:49   0:00 grep rpcbind

Server:

[stefano@polus ~]$ ps aux | grep rpcbind
rpc        466  0.0  0.0  30872  1200 ?        Ss   Jul15   0:00 /usr/bin/rpcbind -w 
stefano   7615  0.0  0.0   9008   852 pts/6    S+   08:47   0:00 grep rpcbind

stefano · 2014-07-18 14:04:16

alphaniner wrote:

Edit: I can't say for sure that it's valid, but the wiki indicates that nfs shares must reside in /srv .

This is news to me. I have used nfs for years (with Arch and other distros) and never put my shares in /srv. And my current setup did work smoothly until the last upgrade.

alphaniner · 2014-07-18 14:18:53

I don't have 'mountpoint' in my exportfs -v output:

/srv/nfs4     	199.200.1.0/24(rw,wdelay,root_squash,no_subtree_check,fsid=0,sec=sys,rw,secure,root_squash,no_all_squash)
/srv/nfs4/bin 	199.200.1.0/24(rw,wdelay,nohide,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/srv/nfs4/pub 	199.200.1.0/24(rw,wdelay,nohide,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/srv/nfs4/pkg 	199.200.1.0/24(rw,wdelay,nohide,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/srv/nfs4/lin 	199.200.1.0/24(ro,wdelay,nohide,root_squash,no_subtree_check,sec=sys,ro,secure,root_squash,no_all_squash)

But more importantly, your /etc/exports isn't in line with how nfs4 is supposed to be done. My /etc/exports:

/srv/nfs4		199.200.1.0/24(rw,sync,no_subtree_check,fsid=0)
/srv/nfs4/bin		199.200.1.0/24(rw,sync,no_subtree_check,nohide)
/srv/nfs4/pub		199.200.1.0/24(rw,sync,no_subtree_check,nohide,no_root_squash)
/srv/nfs4/pkg		199.200.1.0/24(rw,sync,no_subtree_check,nohide,no_root_squash)
/srv/nfs4/lin		199.200.1.0/24(ro,sync,no_subtree_check,nohide)

I never mount the top level (until today I actually thought it was impossible to do so), only the 'children.'

Re exporting from /srv , if it's true then it's definitely a new development. I moved all my exports from /mnt/nfs4 to /srv/nfs4 a few months ago, just because it seemed like good practice.

stefano · 2014-07-18 14:49:19

alphaniner wrote:

I don't have 'mountpoint' in my exportfs -v output:
/srv/nfs4
I never mount the top level (until today I actually thought it was impossible to do so), only the 'children.'

I never mount the top level either, but I listed the top level only in exportfs and mounted the children from the client. It had always worked...
At any rate, I tried listing all the children in /etc/exportfs and reloading it, but nothing changes. Still the same problem

stefano · 2014-07-20 21:31:26

Problem "solved", or rather, disappeared. It looks like the main issue was with rpcd on the server, which crashed repeatedly. A server update and several reboots later, the problem has disappeared, so I guess it was not related to the nfs-utils upgrade as I originally thought.

Marking as [SOLVED] (perhaps improperly).

Arch Linux

#1 2014-07-17 14:36:57

[SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#2 2014-07-17 15:34:03

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#3 2014-07-18 13:17:04

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#4 2014-07-18 13:20:42

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#5 2014-07-18 13:24:59

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#6 2014-07-18 13:32:05

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#7 2014-07-18 13:50:37

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#8 2014-07-18 14:04:16

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#9 2014-07-18 14:18:53

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#10 2014-07-18 14:49:19

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

#11 2014-07-20 21:31:26

Re: [SOLVED] Upgrade to nfs-utils 1.3 breaks mounting of nfs from....

Board footer