more attempts to resolve NSF issues

[Gerhard Magnus]

I can ping (and ssh) the server from the client.
When I restart nfs and nfslock on the server I get this in the
server /var/log/messages:
PuteF kernel: [25572.902466] NFSD: Using /var/lib/nfs/v4recovery as the
NFSv4 state recovery directory
PuteF kernel: [25572.902504] NFSD: starting 90-second grace period
PuteF rpc.mountd[8699]: Version 1.2.4 starting
But on the client, mount /home/magnusg/Music returns:
mount.nfs: access denied by server while mounting
192.168.1.14:/home/magnusg/Music

a couple more things
(1) on the client, showmount -e 192.168.1.14 (the server)
Export list for 192.168.1.14: (shows nothing)
But on the server, my /etc/exports file contains:
/home/magnusg/Music 192.168.1.12,192.168.1.13(rw,insecure,sync,nohide)
(2) also on the client, trying to mount with mount.nfs:
mount.nfs PuteF:/home/magnusg/Music /home/magnusg/Music -v
mount.nfs: timeout set for Sun Oct 23 17:25:32 2011
mount.nfs: trying text-based options
'vers=4,addr=192.168.1.14,clientaddr=192.168.1.13'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting
PuteF:/home/magnusg/Music

OK, my only contact with people who use Linux these days is on this
list, so I have no idea what the current "lore" is. Does anybody
actually use NFS anymore? If not, is there any alternative to NFS
besides using ssh?

-------------------------------

Restating the problem from yesterday:

On the server, running FC15 (192.168.1.14):
(1) My /etc/exports file looks like this:
/home/magnusg/Music  192.168.1.12,192.168.1.13(rw,insecure,sync,nohide)
(2) Using the system-config-nfs "General Options tab" I have "Allow
connections from port 1024 and higher" checked.
(3) I have services nfs and nfslock running on levels 3,4,5.
(4) In /etc/sysconfig/nfs I've set these ports:
RQUOTAD_PORT=4000
LOCKD_TCPPORT=4001
LOCKD_UDPPORT=4001
MOUNTD_PORT=4002
STATD_PORT=4003
(5) In the firewall I have these ports open:
NFSV4 2049 (tcp)
4000-4003 (tcp and udp)
111 (tcp and udp)

on the client, running FC13 (192.168.1.13):
(1) I added this to /etc/fstab:
192.168.1.14:/home/magnusg/Music /home/magnusg/Music nfs
rw,auto,hard,intr,bg 0 0
(2) Services netfs, nfslock and rpcbind are running on levels 3,4,5.

When I boot the client and get to the "Mounting NFS filesystems" section
I don't get error messages -- but I do see this:
mount.nfs: backgrounding 192.168.1.14:/home/magnusg/Music
: mount options
"hard,intr,bg,vers=4,addr=192.168.1.14,clientaddr=192.168.1.13
/home/magnusg/Music remains unmounted

[Bill Davidsen]

Mark Eackloff wrote:
>  I am fishing a bit here, but I have no_root_squash as an option in
> my
>  exports (server) file.  When the client tries to mount the directory
>  automatically at boot time through the entry in /etc/fstab I believe the
>  request is identified as coming from root.  See the "User ID Mapping"
>  section in man (5) exports about this.
>  
If you have ever made that userid stuff work properly you are a better (or more 
patient) person than I. I think the root_id_squash prevents i/o requests from 
root, not the mount itself. At least that's the behavior I notice, root can read 
if public read is set, but can't write a 644 file.

-- 
Bill Davidsen <davidsen(a)tmr.com&gt;
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

[Mark Eackloff]

I am fishing a bit here, but I have no_root_squash as an option in my
exports (server) file.  When the client tries to mount the directory
automatically at boot time through the entry in /etc/fstab I believe the
request is identified as coming from root.  See the "User ID Mapping"
section in man (5) exports about this.

On 10/23/2011 08:36 PM, Gerhard Magnus wrote:
>  I can ping (and ssh) the server from the client.
>  When I restart nfs and nfslock on the server I get this in the
>  server /var/log/messages:
>  PuteF kernel: [25572.902466] NFSD: Using /var/lib/nfs/v4recovery as the
>  NFSv4 state recovery directory
>  PuteF kernel: [25572.902504] NFSD: starting 90-second grace period
>  PuteF rpc.mountd[8699]: Version 1.2.4 starting
>  But on the client, mount /home/magnusg/Music returns:
>  mount.nfs: access denied by server while mounting
>  192.168.1.14:/home/magnusg/Music
>
>  a couple more things
>  (1) on the client, showmount -e 192.168.1.14 (the server)
>  Export list for 192.168.1.14: (shows nothing)
>  But on the server, my /etc/exports file contains:
>  /home/magnusg/Music 192.168.1.12,192.168.1.13(rw,insecure,sync,nohide)
>  (2) also on the client, trying to mount with mount.nfs:
>  mount.nfs PuteF:/home/magnusg/Music /home/magnusg/Music -v
>  mount.nfs: timeout set for Sun Oct 23 17:25:32 2011
>  mount.nfs: trying text-based options
>  'vers=4,addr=192.168.1.14,clientaddr=192.168.1.13'
>  mount.nfs: mount(2): Permission denied
>  mount.nfs: access denied by server while mounting
>  PuteF:/home/magnusg/Music
>
>  OK, my only contact with people who use Linux these days is on this
>  list, so I have no idea what the current "lore" is. Does anybody
>  actually use NFS anymore? If not, is there any alternative to NFS
>  besides using ssh?
>
>  -------------------------------
>
>  Restating the problem from yesterday:
>
>  On the server, running FC15 (192.168.1.14):
>  (1) My /etc/exports file looks like this:
>  /home/magnusg/Music  192.168.1.12,192.168.1.13(rw,insecure,sync,nohide)
>  (2) Using the system-config-nfs "General Options tab" I have "Allow
>  connections from port 1024 and higher" checked.
>  (3) I have services nfs and nfslock running on levels 3,4,5.
>  (4) In /etc/sysconfig/nfs I've set these ports:
>  RQUOTAD_PORT=4000
>  LOCKD_TCPPORT=4001
>  LOCKD_UDPPORT=4001
>  MOUNTD_PORT=4002
>  STATD_PORT=4003
>  (5) In the firewall I have these ports open:
>  NFSV4 2049 (tcp)
>  4000-4003 (tcp and udp)
>  111 (tcp and udp)
>
>  on the client, running FC13 (192.168.1.13):
>  (1) I added this to /etc/fstab:
>  192.168.1.14:/home/magnusg/Music /home/magnusg/Music nfs
>  rw,auto,hard,intr,bg 0 0
>  (2) Services netfs, nfslock and rpcbind are running on levels 3,4,5.
>
>  When I boot the client and get to the "Mounting NFS filesystems" section
>  I don't get error messages -- but I do see this:
>  mount.nfs: backgrounding 192.168.1.14:/home/magnusg/Music
>  : mount options
>  "hard,intr,bg,vers=4,addr=192.168.1.14,clientaddr=192.168.1.13
>  /home/magnusg/Music remains unmounted
>
>

[Mark Eackloff]

On 10/23/2011 11:03 PM, Bill Davidsen wrote:
>  Mark Eackloff wrote:
> > I am fishing a bit here, but I have no_root_squash as an option in my
> > exports (server) file.  When the client tries to mount the directory
> > automatically at boot time through the entry in /etc/fstab I believe the
> > request is identified as coming from root.  See the "User ID Mapping"
> > section in man (5) exports about this.
> >
>  If you have ever made that userid stuff work properly you are a better (or more 
>  patient) person than I. I think the root_id_squash prevents i/o requests from 
>  root, not the mount itself. At least that's the behavior I notice, root can read 
>  if public read is set, but can't write a 644 file.
>  
Yea.  I tried it and you're right.

[Genes MailLists]

 One question - is this the only export which would be available to the
client in question? Is it possible there are others which for some
reason may be interfering (I have seen this issue in the past with
overlapping exports).