Bug 3313 - Kernel NFS client errors (can't silly-delete host/.nfs.etc
Kernel NFS client errors (can't silly-delete host/.nfs.etc
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
sparc Linux
low Severity low
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-07 09:23 EDT by Ian Cameron
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-07-02 18:40:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ian Cameron 1999-06-07 09:23:24 EDT
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 08:52:59 EDT
This issue has been forwarded to a developer for further action.
Comment 2 Cristian Gafton 1999-07-02 18:40:59 EDT
Those are debugging messages.
Comment 3 Ian Cameron 1999-07-05 04:13:59 EDT
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 04:17:59 EDT
Assigned to davem
Comment 5 David Miller 1999-08-13 19:24:59 EDT
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 12:23:59 EDT
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.