This appears to be a Debian-specific issue, so I'm just looking for a
pointer from someone who may know about it.
I installed Debian sid on a new machine back in July, including the
current nfs-common and nfs-kernel-server. NFS mounts were successful,
but did not allow write -- I lost some serious data on one occasion
before I noticed the problem. mount and nfs-utils were upgraded several
times since, and never gave the requested write access. I've been
assuming the problem was firewall-related and lived with it.
On the other machines in the group, NFS writes worked fine. I banged my
head against the wall for a while today, after finally finding time to
look into the problem, and discovered a completely different version of
nfs-utils was running on the new machine. After a painful downgrade
things work fine again.
Here's the verbose output of the version that didn't work, nfs-common
1:1.1.3-2:
mount -vvv /mnt/cortona1
mount: fstab path: "/etc/fstab"
mount: lock path: "/etc/mtab~"
mount: temp path: "/etc/mtab.tmp"
mount: spec: "cortona:/tv1"
mount: node: "/mnt/cortona1"
mount: types: "nfs"
mount: opts: "noauto,user,exec,rw,rsize=16k,wsize=16k,hard,intr"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "cortona:/tv1"
mount: external mount: argv[2] = "/mnt/cortona1"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] =
"rw,nosuid,nodev,noauto,user,rsize=16k,wsize=16k,hard,intr"
mount.nfs: trying xxx.xxx.xxx.178 prog 100003 vers 3 prot TCP port 2049
mount.nfs: trying xxx.xxx.xxx.178 prog 100005 vers 3 prot UDP port 32774
cortona:/tv1 on /mnt/cortona1 type nfs
(noauto,user,exec,rw,rsize=16k,wsize=16k,hard,intr)
tna@roma$ cd /mnt/cortona1
tna@roma:/mnt/cortona1$ touch one
touch: cannot touch `one': Permission denied
Downgrading to 1:1.1.0-5 restored proper write access. Is this a
familiar-looking problem to someone?
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
