Bug 530591 - Can't start nfs.statd in F12Beta LiveCD
Can't start nfs.statd in F12Beta LiveCD
Status: CLOSED DUPLICATE of bug 533771
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
12
All Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-23 12:10 EDT by Jon Ciesla
Modified: 2009-11-20 08:42 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-20 08:42:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jon Ciesla 2009-10-23 12:10:55 EDT
I booted a F12Beta LiveCD, and needed to mount an NFS share (on an F11 machine).  I discovered that nfs-utils was not installed, so I did this with yum.  I then tried to start nfs.statd, and it failed.  I was then only able to mount the NFS share using the -o nolock option.

I'll be happy to provide any additional info needed.
Comment 1 Steve Dickson 2009-10-23 13:50:44 EDT
Is SELinux enabled? If so, try doing as root 
    'setenforce && service nfslock start'
Comment 2 Jon Ciesla 2009-10-23 14:14:02 EDT
It is.  Assuming you really meant "setenforce 0 && service nfslock start", that fails.

/var/log/messages gives "unable to register (statd, 1, udp)."
Comment 3 Steve Dickson 2009-10-26 08:12:49 EDT
Ah so rpcbind is not running... what does rpcinfo -p output?
Comment 4 Jon Ciesla 2009-10-26 09:05:47 EDT
rpcinfo: can't contact portmapper: RPC: Remote system error - no such file or directory
Comment 5 Steve Dickson 2009-10-26 10:16:54 EDT
Ok.. that is the problem... rpcbind is not is not started which means
rpc.statd will not start (by design) which means only '-o nolocks' mount
are possible... 

So the question is why is rpcbind not being started?? Unfortunately
I'm not sure to whom I ask that question...
Comment 6 Jon Ciesla 2009-10-26 10:36:43 EDT
I'd normally say the rpcbind maintainer, but that looks like it's you. :)  And I don't see anything earth-shattering between the version in F-11 and the rawhide one.
Comment 7 Cia Watson 2009-11-08 13:55:53 EST
I installed the Fedora12 beta livecd, now fully updated and wanted to set up an NFS share with my laptop running Fedora 7 (laptop only has 256mb ram, it's old, so it's probably staying with F7). When I tried to mount the exported folder on the laptop, I got a message 'permission denied'. I opened the ports I set up in /etc/sysconfig/nfs on the firewall -- so it shouldn't actually be a permission issue. 

I thought I'd then try the reverse, to see if I could mount a folder to the F12 pc, and here's the output:

/usr/sbin/start-statd: line 8: /sbin/rpc.statd: Permission denied
/usr/sbin/start-statd: line 8: /sbin/rpc.statd: Success
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 ran the command from message 2 "setenforce 0 && service nfslock start", then did:  'cat /var/log/messages |grep statd' and got:

Nov  7 18:27:44 localhost rpc.statd[1130]: Version 1.2.0 Starting
Nov  7 22:31:56 localhost rpc.statd[1130]: Caught signal 15, un-registering and exiting.
Nov  8 09:04:08 maple rpc.statd[1353]: Version 1.2.0 Starting  

Then ran 'nfs service restart' and now I can mount the folder on the F12 machine without the -o nolock option, but I still get a 'permission denied' trying to mount a folder on the laptop.  Let me know if you need any more info.
Comment 8 Cia Watson 2009-11-08 14:03:13 EST
Just to add to the above comment 7; on the /var/log/messages, the one with today's date (Nov 9, 09:04:08) was from when I booted the pc, because it's now 2 hours later, pacific time when I got it to mount without the -o nolock. In case it matters.
Comment 9 Cia Watson 2009-11-08 15:49:03 EST
I figured it out, I think. I opened up the NFS config to try allowing connections higher than port 1024, in the off chance that made a difference. While I was looking at the 'host' info, I saw there was an 'http:/' in front of the IP number, I didn't put that there. 

I looked at /etc/exports, and sure enough it had the host IP prepended by http:/. I edited the /etc/hosts file and removed the http:/ ; did a 'service nfs restart' then I could mount the share on my laptop just fine.

I deleted the http:/ in >system > administration >NFS (a package I'd installed), and when I exited and pulled it up again; I found it now has a 2nd entry with the http:/ added back in again. Where that's coming from I don't know.

This may or may not be related to the rpc.statd issue -- if it's a separate issue I can put this someplace else.
Comment 10 Steve Dickson 2009-11-09 12:13:57 EST
So the export entry in /etc/exports had a 'http:/' on it?
Comment 11 Cia Watson 2009-11-10 01:05:13 EST
(In reply to comment #10)
> So the export entry in /etc/exports had a 'http:/' on it?  

Yes, AdamW suggested (on fedora forums) I file a bug report, here it is: 
https://bugzilla.redhat.com/show_bug.cgi?id=533771
Comment 12 Bug Zapper 2009-11-16 09:07:21 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 Steve Dickson 2009-11-20 08:42:49 EST

*** This bug has been marked as a duplicate of bug 533771 ***

Note You need to log in before you can comment on or make changes to this bug.