Warum wird ein NFS-Server als RW-Server gemountet, der schreibgeschützte Dateisystemfehler zurückgibt?

Ich arbeite an einem Ubuntu Server 64bit. Ich habe ein nfs als rw gemountet, aber wenn ich versuche, etwas auf dem fraglichen Mountpoint zu bearbeiten, erhalte ich einen schreibgeschützten Dateisystemfehler

meine etc/fstabliest:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
/dev/mapper/product-root /               ext4    errors=remount-ro 0       1
UUID=1cae6948-ca9d-4f0b-aec6-9e7a60bbbad8 /boot           ext2    defaults        0       2
/dev/mapper/product-swap_1 none            swap    sw              0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0
vnxnfs1.company.com:/NFS2         /mnt/nfs2                        nfs     defaults       0       0

mount kehrt zurück:

/dev/mapper/product-root on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw)
vnxnfs1.company.com:/NFS2 on /mnt/nfs2 type nfs (rw)

cat /proc/mounts kehrt zurück:

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=16465812k,nr_inodes=4116453,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,relatime,size=6590172k,mode=755 0 0
/dev/mapper/product-root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
none /sys/fs/fuse/connections fusectl rw,relatime 0 0
none /sys/kernel/debug debugfs rw,relatime 0 0
none /sys/kernel/security securityfs rw,relatime 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,nosuid,nodev,relatime 0 0
/dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0
rpc_pipefs /run/rpc_pipefs rpc_pipefs rw,relatime 0 0
vnxnfs1.company.com:/NFS2 /mnt/nfs2 nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.x.y.z,mountvers=3,mountport=1234,mountproto=udp,local_lock=none,addr=172.x.y.z 0 0

Dateien auf dem MNT lesen sich gut, aber wenn ich versuche, etwas zu ändern, erhalte ich eine Fehlermeldung:

touch: cannot touch `/mnt/nfs2/path/to/test_file.txt': Read-only file system

Ich kann mich mit dem fraglichen nfs von anderen Servern verbinden und gut lesen und schreiben. Das einzige Problem ist auf diesem Server. Ich habe versucht, mount -o remount,rw vnxnfs1.company.com:/NFS2 /mnt/nfs2wie Antworten auf verwandte Fragen vermuten lassen, aber ohne Erfolg.

Entschuldigen Sie den Datenverlust, ich habe nur versucht, alles mit aufzunehmen, was Hinweise liefern könnte.

BEARBEITEN:

mehr Details

Ich habe vom rootBenutzer auf dem Computer mit Problemen getestet , und das Schreiben in nfs funktioniert sowohl von rootals auch uservon einem anderen (nfs-write-is-working) Server aus.

vom Arbeitsserver: ls -la /mnt/nfs2/

total 76
drwxrwxrwx 12 root root   1024 2013-04-18 10:14 .
drwxr-xr-x 24 root root   4096 2013-04-17 10:42 ..
drwxrwxr-x  2 user user   80 2013-04-18 10:14 archives
drwxrwxrwx  2 user user   1024 2012-08-15 10:13 assignee_dealiasing_temp_folder
drwxrwxr-x  9 user user   1024 2013-03-11 13:50 data_runs
drwxrwxrwx  2 user user   2048 2013-04-19 14:54 db_transfer_dumps
drwxrwxrwx  2 root daemon 1024 2013-08-22 01:00 .etc
drwxrwxrwx  2 root root   8192 2012-08-16 14:47 lost+found
drwxr-xr-x 13 user user   1024 2013-08-16 13:37 projects
drwxr-xr-x 35 user user   2048 2013-05-10 16:34 reports
drwxrwxrwx  6 root root   1024 2013-04-17 16:47 saved_logs

von der vnxnfs1 server_export server_2 -list

server_2 :
export "/NFS3" rw=172.16.0.0/24 root=172.16.0.0/24
export "/NFS2" rw=172.16.0.0/24:172.16.9.0/24 root=172.16.0.0/24:172.16.9.0/24
export "/NFS1" rw=172.16.0.0/24:172.16.9.0/24 root=172.16.0.0/24:172.16.9.0/24
export "/ISO" rw=172.16.9.16:172.16.9.18:172.16.9.20 root=172.16.9.16:172.16.9.18:172.16.9.20
export "/NFS0" rw=172.16.0.0/24 root=172.16.0.0/24
export "/" anon=0 access=128.221.252.100:128.221.253.100:128.221.252.101:128.221.253.101

Der Fehler "Nur-Lese-Dateisystem" gibt an, dass das Dateisystem als schreibgeschützt exportiert wird. Die Option rw mount teilt dem Client mit, dass 'WRITE' an den Server gesendet werden darf. Überprüfen Sie auf normalen Unix-Systemen die Datei / etc / exports:

/NFS2 172.x.y.z(rw)

Überprüfen Sie bei Geräten die Dokumentation, die als Lese- / Schreibzugriff exportiert werden soll.

Der Export eines übergeordneten Ordners (ro) überschreibt einen untergeordneten Export (rw).

Beispielexporte:

/NFS_ROOT *(ro)
/NFS_ROOT/SHARE1 *(rw)

SHARE1 ist schreibgeschützt, da NFS_ROOT schreibgeschützt ist. Sie haben Einschränkungen für ein exportiertes Stammverzeichnis, die möglicherweise das Problem verursachen.

Wie Brian sagte, kann ein Elternexport einen Kindexport überschreiben. Sie können dies jedoch lösen, indem Sie Ihren Exporten Prioritäten hinzufügen. Mit dem Beispiel von Brian würde dies das Problem lösen:

/NFS_ROOT *(ro,fsid=2)
/NFS_ROOT/SHARE1 *(rw,fsid=1)

Wenn Ihr Mountpoint auf dem Client ist /var/share, stellen Sie sicher, dass er mit den Rechten 777 erstellt wurde:

chmod 777 /var/share

Andernfalls könnten Sie seltsame seltsame Fehler haben, bei denen Sie nur mit root schreiben können, aber RO mit allen anderen Benutzern, Rechten an gemounteten Dateien ---------oder anderem seltsamen Verhalten haben.