On Tue, Jan 13, 2009 at 05:13:53PM -0500, blee2@tampabay.rr.com wrote:
> Thus Paul M Foster hast written on Tue, Jan 13, 2009 at 12:37:56PM -0500,
> and, according to prophecy, it shall come to pass that:
> > 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:
> > drwxr-xr-x 135 paulf paulf 8192 2009-01-13 10:14 paulf
>
> Yes, root should be able to read and write anything...provided something
> else isn't flaky/broken... See below.
>
> >
> > So I wondered if I could even just *copy* the file over, like so:
> > 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
> >
> > 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
>
> Your options:
> sec=mode Set the security flavor for this mount to "mode".
> soft If an NFS file operation has a major timeout then report
> an I/O error to the calling program. The default is to continue
> retrying NFS file operations indefinitely.
> intr If an NFS file operation has a major timeout and it is
> hard mounted, then allow signals to interupt the file operation
> and cause it to return EINTR to the calling program. The default
> is to allow file operations to be interrupted.
> timeo=n The value in tenths of a second before sending the first
> retransmission after an RPC timeout.
>
>
> > Anyone know 1) why this happens, and 2) how to get around it so I can
> > get back to rsyncing my backups again?
>
> There's a few different things you can do to a file system that will
> "break it" in various ways. Generally these involve some type of I/O
> error: read/write/network.
>
> Your write-up implies that you only upgraded the NFS server, so I see this
> as being a couple possibilities:
> * Versions not fully compatible (without additional options?)
> * New version requires you specify that exported volumes be writable
> * New version requires that mounts specify writable
> * Did not unmount NFS volumes from client during upgrade. Client
> saw read/write/network errors and remounted the NFS volumes read-only.
Actually I only upgraded the *client*, not the server.
>
> I suspect your problem is the last.
No, actually the new mount version wouldn't install until I unmounted
the directories. *Then* it would properly install. In fact, I had to
upgrade nfs-common and nfs-kernel-server afterward, because mount
wouldn't work without the additional mount.nfs program contained in the
nfs-* packages.
>
> Issue a mount command. You should see something of the form:
> /dev/mapper/1-root on / type ext3 (rw,errors=remount-ro)
sherman:/home/paulf# mount -v /lan/backup
mount.nfs: trying 192.168.10.40 prog 100003 vers 3 prot TCP port 2049
mount.nfs: trying 192.168.10.40 prog 100005 vers 3 prot UDP port 1590
pokey:/lan on /lan/backup type nfs
(rw,sec=none,soft,intr,timeo=12,wsize=8192,rsize=8192)
>
> However, instead of the "(rw..." in the mount options, I bet you'll see
> "(ro...", indicating read only. The second option indicates that in the
> event of errors, the filesystem will be re-mounted read-only.
>
> Unmounting /lan on the client, then remounting it should fix that problem.
As you can see, no such luck.
>
> If not, it may help to unmount the NFS volume on your client, then unmount
> the exported filesystem on server, then remount filesystem on server,
> then remount the NFS volume on the client.
>
> Let me know if that's the fix.
Nope. Tried, and no help. Incidentally, the test I'm using is the same
one I used above:
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
where the directory /lan/backup/backup/sherman/home/paulf has these
permissions:
drwxr-xr-x 135 paulf paulf 8192 2009-01-13 10:14 paulf
and the user doing the copying is paulf
>
> If that's NOT the case, do
> ls -ld /lan/backup/backup/sherman/home/paulf/
> ls -ld /lan/backup/backup/sherman/home/
> ls -ld /lan/backup/backup/sherman/
> ls -ld /lan/backup/backup/
> ls -ld /lan/backup/
> ls -ld /lan/
> and make sure all these directories are writable. Check them on the server
> too. If a parent is not writable, the children won't be writable either,
> even if the child's permissions are 777.
>
On the client:
paulf@sherman[13]:paulf$ ls -ld /lan/backup/backup/sherman/home/paulf
drwxr-xr-x 135 paulf paulf 8192 2009-01-13 15:25
/lan/backup/backup/sherman/home/paulf
paulf@sherman[13]:paulf$ ls -ld /lan/backup/backup/sherman/home
drwxr-xr-x 3 root root 4096 2007-12-29 17:48
/lan/backup/backup/sherman/home
paulf@sherman[13]:paulf$ ls -ld /lan/backup/backup/sherman
drwxr-xr-x 6 root root 4096 2008-09-29 21:46 /lan/backup/backup/sherman
paulf@sherman[13]:paulf$ ls -ld /lan/backup/backup
drwxr-xr-x 5 root root 4096 2007-12-29 17:47 /lan/backup/backup
paulf@sherman[13]:paulf$ ls -ld /lan/backup
drwxr-xr-x 4 root root 4096 2007-12-29 17:36 /lan/backup
paulf@sherman[13]:paulf$ ls -ld /lan
drwxr-xr-x 5 root root 4096 2005-12-29 19:21 /lan
On the server:
pokey:~# ls -ld /lan/backup/sherman/home/paulf
drwxr-xr-x 135 paulf paulf 8192 2009-01-13 15:25
/lan/backup/sherman/home/paulf
pokey:~# ls -ld /lan/backup/sherman/home
drwxr-xr-x 3 root root 4096 2007-12-29 17:48 /lan/backup/sherman/home
pokey:~# ls -ld /lan/backup/sherman
drwxr-xr-x 6 root root 4096 2008-09-29 21:46 /lan/backup/sherman
pokey:~# ls -ld /lan/backup
drwxr-xr-x 5 root root 4096 2007-12-29 17:47 /lan/backup
pokey:~# ls -ld /lan
drwxr-xr-x 4 root root 4096 2007-12-29 17:36 /lan
All directories are writable by their respective users, which makes
sense, since the umask on this box is 022.
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:18:35 EDT