Bug 530591
Summary: | Can't start nfs.statd in F12Beta LiveCD | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gwyn Ciesla <gwync> |
Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 12 | CC: | cia.watson, steved |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-11-20 13:42:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gwyn Ciesla
2009-10-23 16:10:55 UTC
Is SELinux enabled? If so, try doing as root 'setenforce && service nfslock start' It is. Assuming you really meant "setenforce 0 && service nfslock start", that fails. /var/log/messages gives "unable to register (statd, 1, udp)." Ah so rpcbind is not running... what does rpcinfo -p output? rpcinfo: can't contact portmapper: RPC: Remote system error - no such file or directory 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... 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. 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. 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. 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. So the export entry in /etc/exports had a 'http:/' on it? (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 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 *** This bug has been marked as a duplicate of bug 533771 *** |