Bug 201438
| Summary: | vi (chown) doesn't work in an nfs4 mount | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Kostas Georgiou <k.georgiou> | ||||
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.4 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | nfs-utils-1.0.6-76 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2007-02-12 22:52:00 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: | |||||||
| Attachments: |
|
||||||
ping Still there in update4 I'm not seen this behavior at all... so could you please posted as bzip2 binary tethereal trace of the problem. Something similar to 'tethereal -w /tmp/data.pcap host <server> ; bzip2 /tmp/data.pcap' Hmm this is going to take a while, it seems that the machine is hit by something similar to: http://linux-nfs.org/pipermail/nfsv4/2006-April/004132.html and http://linux-nfs.org/pipermail/nfsv4/2006-April/004103.html Since the new nfs-utils-lib includes librpcsecgss-0.10 I suspect that this is the cause. I'll roll back to the older version of nfs_utils* to get the network dump. Do you want me to open a new bug for the "rpc.gssd: WARNING: can't create rpc_clnt for server ...." error message? Yes.. please... thanks!! Created attachment 134314 [details]
nfs4 network trace with host servername and port 2049
I had to roll back the server (x86_64 also) as well since it was failing with: Aug 16 15:33:23 icva rpc.svcgssd[3443]: WARNING: get_uid failed Aug 16 15:33:23 icva rpc.svcgssd[3443]: WARNING: handle_nullreq: get_uid failed Aug 16 15:33:48 icva rpc.svcgssd[3443]: WARNING: get_uid failed Aug 16 15:33:48 icva rpc.svcgssd[3443]: WARNING: handle_nullreq: get_uid failed Aug 16 15:34:13 icva rpc.svcgssd[3443]: WARNING: get_uid failed Aug 16 15:34:13 icva rpc.svcgssd[3443]: WARNING: handle_nullreq: get_uid failed Which makes me wonder how did I manage to claim that the chown bug is still there in update4? Probably I only tested with the new kernel... #203239 for the regression. Any thoughts on what is causing the problem? Can you replicate the problem at all? This probably does not happen when you don't use sec=krb5, correct? Both sec=sys and sec=krb5 show the problem, the server is x86_64 but I tried both i386 and x86_64 clients (with and without krb5). When does the server reply with NFS4ERR_DELAY? From what I can see the client keep sgetting the delay "error" forever :( Well when the server returns NFS4ERR_DELAY, it generally means the server has done an upcall to some user daemon and is waiting for the response (i.e. a downcall)..... Now a NFS4ERR_DELAY on the client means go away for a second or two and then retry... So seeing the client continuously trying is normal.... Now looking a Comment #7, it appears the user level daemon the server is waiting for is rpc.svcgssd, who seems to be having a problem getting the uid from Kerberos... What version of nfs-utils and nfs-utils-lib are you using? This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. The testing was done with the version previous to 4.4, since the latest version is broken under x86-64. The error message in comment #7 is from nfs-utils-1.0.6-70.EL4 (bugzilla #203239) which is a different issue. Just curious... what is the containts of /etc/gssapi_mech.conf?
It should have an entry like:
libgssapi_krb5.so.2 mechglue_internal_krb5_init
It's libgssapi_krb5.so mechglue_internal_krb5_init I think I did remove the /usr/lib/ by hand since the install was before the fix (was it in 4.4? I can't remember really) The errors in Comment #7 should be fixed in nfs-utils-1.0.6-76 Is nfs-utils-1.0.6-76 available anywhere? I imagine it's part of 4.5 right? yes... Please feel free to reopen this bug if you still have the same problem.. |
Running vi in a nfs4 home directory gets stuck in a call to chown strace shows that the chown call never returns. chown("5159", 1111, 222) = ? ERESTARTSYS (To be restarted) the ERESTARTSYS is because of a kill. The server is a x86_64 RHEL4 machine and both i386/x86_64 RHEL4 clients have the problem with nfs4 mounts with sec=sys and sec=krb5. A mount from a FC5 client to the same server works fine. The RHEL4 machines are fully patched (U3+fasttrack) and the latest available kernel (2.6.9-42.ELsmp) doesn't help either. Let me know if you want tcpdump logs etc.