Bug 90238
Summary: | lockd: can't encode arguments: 5 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 2.1 | Reporter: | Bruce Garlock <bruce> |
Component: | kernel | Assignee: | Steve Dickson <steved> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 2.1 | ||
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: | 2004-06-15 19:06:45 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
Bruce Garlock
2003-05-05 21:13:39 UTC
OOps, meant to say, I did *not* have this problem under RH 6.2 - I had never seen the error before. I can further reproduce this error by doing the following: mount an NFS dir to a SCO OpenServer 5.0.5 machine, using this mount command in /etc/fstab on the AS 2.1 box: note: Garlock is the SCO 5.0.5 machine Garlock:/usr/covalent/users/mark /home/samba/work/users/mark/covalent nfs rsize=16384,wsize=16384,soft,intr The directory is the accessed as a SAMBA share on the AS 2.1 box, making the NFS directory appear as a "regular" directory on the AS 2.1 box. On the SCO side, this is my export entry for the NFS share: /usr/covalent/users/mark -rw=linux.server where linux.server is the AS 2.1 box. As I said before, all this worked fine under RH 6.2, and I never had an issue. We use the SCO machine to export a procedure the the export folder in Lotus 1-2-3 format, then the user will open the file, and get the error "File in Use", when in fact it is not in use. The linux box then logs the error: lockd: can't encode arguments: 5 I used a RH 9 machine to mount the same NFS directory, and could not get the error. The error occurs *every* time on the 2.1AS box, when the file is initially accessed. Subsequent access to the file seems to open it up just fine. |