Bug 3313 - Kernel NFS client errors (can't silly-delete host/.nfs.etc
Summary: Kernel NFS client errors (can't silly-delete host/.nfs.etc
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.0
Hardware: sparc
OS: Linux
low
low
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-06-07 13:23 UTC by Ian Cameron
Modified: 2008-08-01 16:22 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 1999-07-02 22:40:27 UTC
Embargoed:


Attachments (Terms of Use)

Description Ian Cameron 1999-06-07 13:23:24 UTC
I'm running a SPARC as an NFS client (with amd) to a
Solaris/SunOS 5.6 system.  I periodically get messages via
syslog of:

Jun  7 12:39:27 sloe kernel: NFS: can't silly-delete
sloe.open.ac.uk/.nfs00016dcb00000004, error=-13

I'm running kernel-2.2.5-22.

The files mentioned are always (AFAIK) under ~/.xauth.

Comment 1 Jay Turner 1999-06-29 12:52:59 UTC
This issue has been forwarded to a developer for further action.

Comment 2 Cristian Gafton 1999-07-02 22:40:59 UTC
Those are debugging messages.

Comment 3 Ian Cameron 1999-07-05 08:13:59 UTC
But the files mentioned in the messages do get left around as well...
It's then necessary to remove them manually.  The files contain either
one, two or three bytes of 0x00 characters...

Comment 4 Cristian Gafton 1999-07-28 08:17:59 UTC
Assigned to davem

Comment 5 David Miller 1999-08-13 23:24:59 UTC
error -13 is permission denied
I believe the issue is that the temporary file is
created when the X session is beginning and the startup
of X has root privileges, the file is deleted but the
process which removes the final reference in the end
has non-root privileges, and this is what scuffs up the
NFS client code.

This is just a guess, but knowing the permissions and
ownership of the file in question would be a big help to
further diagnose this.

Comment 6 Ian Cameron 1999-08-16 16:23:59 UTC
Here are the permissions of the .xauth directories:

# ls -laR /root/.xauth/
/root/.xauth:
total 2
drwx------   2 root     ifef         1024 Aug 16 17:07 .
drwxr-xr-x   3 root     root         1024 Aug 16 17:10 ..

$ ls -laR .xauth/
.xauth:
total 3
drwx------   3 iac2     ifef          512 Aug 16 17:05 .
drwxr-xr-x   5 iac2     ifef          512 Aug 16 17:08 ..
drwx------   3 iac2     ifef          512 Aug 16 17:05 refcount

.xauth/refcount:
total 3
drwx------   3 iac2     ifef          512 Aug 16 17:05 .
drwx------   3 iac2     ifef          512 Aug 16 17:05 ..
drwx------   3 iac2     ifef          512 Aug 16 17:05 root

.xauth/refcount/root:
total 3
drwx------   3 iac2     ifef          512 Aug 16 17:05 .
drwx------   3 iac2     ifef          512 Aug 16 17:05 ..
drwx------   2 iac2     ifef          512 Aug 16 17:10
dhcp-tech-254.open.ac.uk

.xauth/refcount/root/dhcp-tech-254.open.ac.uk:
total 6
drwx------   2 iac2     ifef          512 Aug 16 17:10 .
drwx------   3 iac2     ifef          512 Aug 16 17:05 ..
-rw-------   1 iac2     ifef            2 Aug 16 17:05
.nfs0001a2bf00000003
-rw-------   1 iac2     ifef            2 Aug 16 17:06
.nfs0001a2c200000004
-rw-------   1 iac2     ifef            2 Aug 16 17:07
.nfs0001a2c300000005
-rw-------   1 iac2     ifef            2 Aug 16 17:08
.nfs0001a2c400000006

My machine is now set up as follows:

A single NFS mount to a Solaris 2.6 box for my home directory
NIS (no local accounts)

I have found a way to reproduce this problem.  If I log in as myself,
then 'su' to root, then exit back to my own login, /var/log/messages
will indicate the can't silly-delete .nfs... right after I end the
'su' session.

You mention permissions problems, which makes me wonder if it's a
problem with root's UID trying to delete a file in my home directory.
This is not possible since my home directory is NFS mounted, but would
be possible on local disks.  Either that or my UID is attempting to
delete files under /root/.xauth.

Hope this is useful.


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