FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 10-24-2011, 12:36 AM
Gerhard Magnus
 
Default more attempts to resolve NSF issues

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


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 10-24-2011, 01:00 AM
Genes MailLists
 
Default more attempts to resolve NSF issues

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).



--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 10-24-2011, 02:04 AM
Mark Eackloff
 
Default more attempts to resolve NSF issues

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
>
>

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 10-24-2011, 03:03 AM
Bill Davidsen
 
Default more attempts to resolve NSF issues

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@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 10-24-2011, 03:03 AM
Bill Davidsen
 
Default more attempts to resolve NSF issues

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@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 
Old 10-24-2011, 07:39 PM
Mark Eackloff
 
Default more attempts to resolve NSF issues

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.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
 

Thread Tools




All times are GMT. The time now is 02:35 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org