Bug 53265
| Summary: | rpc.statd fails to start. | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | lars |
| Component: | nfs-utils | Assignee: | Pete Zaitcev <zaitcev> |
| Status: | CLOSED WORKSFORME | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-04-19 19:32:04 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: | |||
So, the problem is pretty obvious. rpc.statd changes to uid 29/gid 29 (rpcuser/rpcuser), and tries to chdir() to /var/lib/nfs/statd. The permissions in /var/lib/nfs look like this: -rw-r--r-- 1 root root 799 Sep 4 16:21 etab -rw-r--r-- 1 root root 2077 Sep 5 15:33 rmtab drwxr-xr-x 4 root root 4096 Sep 5 15:45 statd -rw-r--r-- 1 root root 1952 Sep 5 14:51 xtab The statd() directory should be chgrp'd to rpcuser, and then chmod'd to allow group read/write/execute access. The nfs-utils RPM should make /var/lib/nfs/statd owned by rpcuser by default. What happens if you reinstall the nfs-utils RPM? |
Description of Problem: Any attempt to start rpc.statd fails with the following error in /var/log/messages: nfslock: rpc.statd startup succeeded rpc.statd[8286]: Cannot access current directory after dropping privs: access() Version-Release number of selected component (if applicable): nfs-utils-0.3.1-12 How Reproducible: Just run rpc.statd; you can also run the 'nfslock' init script. Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information: Just for kicks I tried changing to /tmp and then rpc.statd by hand, and it still fails with the same error. The error is accurate; an strace of the process concludes with: 8222 setuid32(0x1d) = 0 8222 getgid32() = 29 8222 getuid32() = 29 8222 access(".", R_OK|W_OK|X_OK) = -1 EACCES (Permission denied)