[SLUG] mount/NFS problems

From: Paul M Foster (paulf@quillandmouse.com)
Date: Tue Jan 13 2009 - 12:37:56 EST


I'll try to make this brief, but I'll probably fail.

I typically do a backup of my home directory to a backup directory on
another machine. That backup directory is mounted as an NFS mount on my
machine. I run the backup through cron as a job executed through
/etc/cron.daily. Normally, all goes well, and I get a daily email
detailing what was backed up, etc.

Yesterday, for a variety of reasons, I had to upgrade mount and my nfs
daemons (nfs-common, nfs-kernel-server) to the latest versions from
Debian unstable. The mount version is now 2.13.1.1. nfs-common is
1.1.4-1, and nfs-kernel-server is 1.1.4-1. Nothing's changed about the
*way* I'm mounting the NFS mounts (the entries in /etc/fstab haven't
changed).

With me so far? So this morning I get a half-meg email from cron
detailing thousands of errors attempting to do the rsync backup of my
home directory. The rsync command didn't change, either. It's:

rsync -avWx --delete --temp-dir=/tmp /home/paulf/ \
/lan/backup/backup/sherman/home/paulf

Hundreds and hundreds of failures to back up files, all "permission
denied (13)" errors. I decided to do some testing. To make the process
not take hours, I decided to just deal with a single file. And to make
it even easier, I decided to delete the file on the target, so rsync
would be able to work with a clean slate and just copy the file. The
file I chose was ~/.0verkill. Here are the results of trying this:

sherman:/home/paulf# rsync -avWx --delete --temp-dir=/tmp
/home/paulf/.0verkill /lan/backup/backup/sherman/home/paulf/.0verkill
sending incremental file list
.0verkill
rsync: open "/lan/backup/backup/sherman/home/paulf/.0verkill":
Permission denied (13)
rsync: copy "/tmp/..0verkill.6xCm2J" -> ".0verkill": Permission denied
(13)

sent 109 bytes received 31 bytes 280.00 bytes/sec
total size is 17 speedup is 0.12
rsync error: some files/attrs were not transferred (see previous errors)
(code 23) at main.c(1058) [sender=3.0.4]

Hmm. Didn't make sense. I'm executing this as root, and the user paulf
on both the source and target machines have the same user ID (1000). On
the source box, this file's details look like this:

-rw-r--r-- 1 paulf paulf 17 2007-11-06 23:38 .0verkill

As root, I ought to be able to copy this file anywhere, right? What
about the permissions on the target directory? Here they are:

sherman:/home/paulf# ls -l /lan/backup/backup/sherman/home
total 8
drwxr-xr-x 135 paulf paulf 8192 2009-01-13 10:14 paulf

So I wondered if I could even just *copy* the file over, like so:

cp .0verkill /lan/backup/backup/sherman/home/paulf

And the results:

sherman:/home/paulf# cp .0verkill /lan/backup/backup/sherman/home/paulf/
cp: cannot create regular file
`/lan/backup/backup/sherman/home/paulf/.0verkill': Permission denied

Huh? You're telling me that root can't copy a file from one directory to
another? Okay, what if I'm just me and try to do it? That is, what if I
try as "paulf" to copy a file from one directory owned by me to another
directory owned by me? The results:

paulf@sherman[13]:paulf$ cp .0verkill /lan/backup/backup/sherman/home/paulf
cp: cannot create regular file
`/lan/backup/backup/sherman/home/paulf/.0verkill': Permission denied

So I'm mystified. How is it that I can't copy a file from one directory
I own to another directory I own, and how is it that root can't do it
either? Just for fun, here is how the NFS daemons mount this directory:

pokey:/lan /lan/backup nfs sec=none,soft,intr,timeo=12,wsize=8192,rsize=8192 0 0

Anyone know 1) why this happens, and 2) how to get around it so I can
get back to rsyncing my backups again?

Paul

-- 
Paul M. Foster
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS).  Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:17:49 EDT