When your NFS mount shows as read-write in mount
output but behaves as read-only, this typically indicates a permissions mismatch between client expectations and server enforcement. Here's what we're seeing in this case:
# Client mount status shows RW
vnxnfs1.company.com:/NFS2 on /mnt/nfs2 type nfs (rw)
# But operations fail
touch: cannot touch /mnt/nfs2/path/to/test_file.txt': Read-only file system
First, verify the NFS server's export permissions. The export configuration shows:
export "/NFS2" rw=172.16.0.0/24:172.16.9.0/24 root=172.16.0.0/24:172.16.9.0/24
Key points to check:
- Is the client's IP in the allowed ranges (172.16.0.0/24 or 172.16.9.0/24)?
- Is there an active firewall rule blocking NFS traffic?
- Does the server have disk space available?
The current fstab entry uses defaults:
vnxnfs1.company.com:/NFS2 /mnt/nfs2 nfs defaults 0 0
Try more explicit options:
vnxnfs1.company.com:/NFS2 /mnt/nfs2 nfs rw,hard,intr,noatime,vers=3,tcp 0 0
Then remount:
mount -o remount /mnt/nfs2
Examine directory permissions on both servers:
# On working server:
drwxrwxrwx 2 user user 1024 Aug 15 2012 assignee_dealiasing_temp_folder
# On problematic server:
ls -ld /mnt/nfs2
Potential solutions:
# Try accessing as root first
sudo touch /mnt/nfs2/testfile
# If root works but user doesn't, check:
id -u
getfacl /mnt/nfs2
The mount shows NFSv3 is being used:
vers=3,proto=tcp
Try forcing NFSv4 which has better permission handling:
mount -t nfs4 vnxnfs1.company.com:/NFS2 /mnt/nfs2
Check for outdated components:
# Check NFS utilities
dpkg -l | grep nfs
# Check kernel version
uname -a
# Restart NFS services
sudo service nfs-common restart
sudo service rpcbind restart
Enable NFS debugging on client:
sudo rpcdebug -m nfs -s all
Then attempt operations and check logs:
tail -f /var/log/syslog | grep nfs
For network-level debugging:
sudo tcpdump -i eth0 -n port 2049 -w nfs.pcap
When mounting an NFS share with rw
permissions but encountering "read-only file system" errors, we're dealing with a classic NFS permission paradox. The key indicators from your setup:
# From fstab
vnxnfs1.company.com:/NFS2 /mnt/nfs2 nfs defaults 0 0
# Mount output shows RW
vnxnfs1.company.com:/NFS2 on /mnt/nfs2 type nfs (rw)
# But operations fail
touch: cannot touch /mnt/nfs2/path/to/test_file.txt': Read-only file system
The export configuration shows:
export "/NFS2" rw=172.16.0.0/24:172.16.9.0/24 root=172.16.0.0/24:172.16.9.0/24
Critical checks needed:
# On NFS server:
showmount -e vnxnfs1.company.com
rpcinfo -p vnxnfs1.company.com | grep nfs
First, verify the actual mount options in use:
cat /proc/mounts | grep nfs2
Try mounting with explicit options:
mount -t nfs -o rw,vers=3,hard,intr,timeo=600,retrans=2 \
vnxnfs1.company.com:/NFS2 /mnt/nfs2
The directory listing shows mixed ownership:
drwxrwxrwx 12 root root 1024 2013-04-18 10:14 .
drwxrwxr-x 2 user user 80 2013-04-18 10:14 archives
Try creating files with different users:
sudo -u user touch /mnt/nfs2/user_test.txt
sudo -u nobody touch /mnt/nfs2/nobody_test.txt
Check for network issues that might cause NFS to fall back to read-only:
# Test basic connectivity
ping vnxnfs1.company.com
nc -zv vnxnfs1.company.com 2049
# Check for packet loss
sudo tcpdump -i eth0 host vnxnfs1.company.com and port 2049
Enable NFS debugging:
# Client side
echo 32767 > /proc/sys/sunrpc/nfs_debug
dmesg | tail -20
# Server side (if accessible)
nfsstat -s
nfsstat -m
Alternative mount options to try:
mount -t nfs -o rw,nolock,soft,timeo=10,retrans=3 \
vnxnfs1.company.com:/NFS2 /mnt/nfs2
On the NFS server, verify filesystem health:
# For VxFS (common on NetApp)
fsck -F vxfs /dev/xxx
# For ext* filesystems
fsck -f /dev/xxx
Create a comprehensive test script:
#!/bin/bash
TEST_FILE="/mnt/nfs2/nfs_test_$(date +%s)"
echo "Testing NFS write capabilities..."
if touch $TEST_FILE; then
echo "File created successfully"
if echo "test" > $TEST_FILE; then
echo "Write successful"
rm $TEST_FILE
echo "Test completed successfully"
else
echo "Write failed"
fi
else
echo "File creation failed"
dmesg | tail -10
exit 1
fi