If I include the “users” or “user” option back in fstab the share mounts ro, as before.
Just speculating here: If the share was already mounted before logging out, the mount still exists with the old UID/GID mapping from the previous session.
Reboot or remount the share manually…
sudo umount /home/bruno/share
sudo mount -v 192.168.0.3:/home/bruno/share /home/bruno/share
Don’t include user or users as these are mount helper options, not NFS options, and can cause RO mounts. Let the mount be handled by root (as usual), then users will get correct ownership inside the share because NFSv4 maps UID/GID.
Thank you for your help, Deano. Unfortunately it is still not working:
bruno@backup:~> cat /etc/fstab
UUID=d1019e5a-5ca9-4f00-af65-6f1ccaa09285 / ext4 defaults 0 1
UUID=d2ef698b-bfc9-4a81-80df-e549cfb3b279 /home ext4 defaults 0 2
UUID=70B7-7125 /boot/efi vfat utf8 0 2
UUID=c5443494-7061-41ed-93cf-cd0fc0b234c4 swap swap defaults 0 0
UUID=4f8fc0ab-1f34-4660-b47a-effb2f8a136b /home/Backup auto nofail 0 0
192.168.0.3:/home/bruno/share /home/bruno/share nfs
# soft,noauto,rw,users,timeo=100,retrans=200 0 0
bruno@backup:~> sudo umount /home/bruno/share
[sudo] senha para bruno:
umount: /home/bruno/share: não montado.
bruno@backup:~> sudo mount -v 192.168.0.3:/home/bruno/share /home/bruno/share
mount.nfs: timeout set for Mon Feb 16 20:01:40 2026
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.3,clientaddr=192.168.0.6'
bruno@backup:~> cd /home/bruno/share
bruno@backup:~/share> ls
dispositivos montados 1.png Livros e Revistas Musicas Backup
dispositivos montados 2.png Manuais e Tutoriais
dispositivos montados 0.png
bruno@backup:~/share> id bruno
uid=1000(bruno) gid=100(users) grupos=100(users),496(wheel)
bruno@backup:~/share> touch teste.txt
touch: não foi possível tocar 'teste.txt': Sistema de arquivos somente para leitura
Last line translation:
touch: Could not touch ‘test.txt’: Read-only file system
Hmmm…can you show the following (from server)?
sudo exportfs -v
ls -ld /home/bruno/share
This definitely is wrong.
1 Like
All done in Virtualbox.
Setting up a new Leap 15.6 with a new NFS-Server:
opensuse156:/home/stephan # cat /etc/exports
/home/stephan/NFS *(rw,root_squash,sync,no_subtree_check)
opensuse156:/home/stephan # showmount -e
Export list for opensuse156:
/home/stephan/NFS *
opensuse156:/home/stephan #
Firewall:
opensuse156:/home/stephan # firewall-cmd --zone=public --list-all
public (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces: eth0
sources:
services: dhcpv6-client nfs nfs3
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
User:
stephan@opensuse156:~> id
uid=1000(stephan) gid=100(users) Gruppen=100(users)
Client openSUSE Leap 16.0:
stephan@opensuse160:~> cat /etc/fstab
.
.
.
192.168.0.56:/home/stephan/NFS /home/stephan/NFS nfs rw,auto 0 0
Firewall:
opensuse160:/home/stephan # firewall-cmd --zone=public --list-all
public (default, active)
target: default
ingress-priority: 0
egress-priority: 0
icmp-block-inversion: no
interfaces: enp0s3
sources:
services: cockpit cups--631 dhcpv6-client ssh
ports:
protocols:
forward: yes
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
User:
stephan@opensuse160:~> id
uid=1000(stephan) gid=1000(stephan) Gruppen=1000(stephan),459(vboxsf),496(wheel) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
stephan@opensuse160:~>
It is working here without problems.
maybe in the export on the server:
anonuid=1000,anongid=100
@brunomcl Is there a specific need for NFS, there are far easier ways to connect, sftp or sshfs?
I commented out the mount options in fstab for testing, as per Deano’s request
bruno@bruno-03:~> sudo exportfs -v
[sudo] senha para root:
/home/bruno/bin/VM
192.168.0.13(sync,wdelay,hide,no_subtree_check,sec=sys,ro,secure,root_squash,no_all_squash)
/home/bruno/bin/VM
192.168.0.27(sync,wdelay,hide,no_subtree_check,sec=sys,ro,secure,root_squash,no_all_squash)
/home/bruno/bin/VM
192.168.0.6(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/home/bruno/bin/VM
192.168.0.11(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/home/bruno/share
<world>(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/home/trabalho <world>(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
/home/bruno/Publico
<world>(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
bruno@bruno-03:~>
From server (192.168.0.3):
bruno@bruno-03:~> ls -ld /home/bruno/share
drwxrwxr-x 10 bruno users 4096 fev 16 15:29 /home/bruno/share
bruno@bruno-03:~>
Could be, but the thing is that the share is rw from another desktop client running 15.6 with the same config, apparently. That’s what is driving me nuts!
And I should know better… For the last 20 years about 90% of problems I had with linux were permissions related.
I do have a smb server running on the same box for a windows client and Kodi on a firetv stick where I could never make NFS work, or it was flaky. But mostly I tend to associate linux with nfs, and keep as far as possible from windows stuff.
Also these desktops are all in the same room with dedicated monitors and keyboard/mouse sharing with barrier, so no need to enable ssh or sftp, which I’m not familiar with.
But you have a ro mounted file system. That is not about permissions.
I have not read all of the above, but did you try to mount it with the mount command (eventualy after first umount it) to see if there is are any messages and/or related loggings?
AFAICS it is set to rw both on server export and client fstab.
Yes tried umount/mount, as suggested by Deano, see one of the posts above.
Thanks Sauerland. AFAICS it’s the same here, but I have to leave now, will check better when I return.
Ok, the server side checks out as expected…
/home/bruno/share <world>(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)
The permissions: owner bruno, group users, group writable
drwxrwxr-x 10 bruno users 4096 ...
Can you check nfsstat -m both the 15.6 and 16.0 clients? I’m beginning to wonder if SELinux might be impacting here? You could try disabling that and testing again.
Also, try testing as NFSv3 mount…
sudo umount /home/bruno/share
sudo mount -t nfs -o vers=3 192.168.0.3:/home/bruno/share /home/bruno/share
touch test.txt
Thanks Deano. No difference AFAICS:
LEAP 15.6 (share is writable)
pcem-13:/home/bruno # nfsstat -m
/home/bruno/share from 192.168.0.3:/home/bruno/share
Flags: rw,nosuid,nodev,noexec,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=100,retrans=200,sec=sys,clientaddr=192.168.0.13,local_lock=none,addr=192.168.0.3
pcem-13:/home/bruno #
LEAP 16.0 (share is readonly)
backup:/home/bruno # nfsstat -m
/home/bruno/share from 192.168.0.3:/home/bruno/share
Flags: rw,nosuid,nodev,noexec,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=100,retrans=200,sec=sys,clientaddr=192.168.0.6,local_lock=none,addr=192.168.0.3
backup:/home/bruno #
OK. Currently both filesystems are nfs4 according to share properties in Dolphin remote panel.
backup:/home/bruno # umount /home/bruno/share
backup:/home/bruno # mount -t nfs -o vers=3 192.168.0.3:/home/bruno/share /home/bruno/share
Created symlink '/run/systemd/system/remote-fs.target.wants/rpc-statd.service' → '/usr/lib/systemd/system/rpc-statd.service'.
backup:/home/bruno # exit
bruno@backup:~> cd /home/bruno/share
bruno@backup:~/share> touch test.txt
bruno@backup:~/share> ls
dispositivos montados 2.png Musicas
dispositivos montados 0.png Livros e Revistas test.txt
dispositivos montados 1.png Manuais e Tutoriais
Yay! Mounting with nfs (v3) instead of nfs4 works!
So, how do we make it work in LEAP 16 with nfs v4?
1 Like
P.S.: tried that, no change. See NFS share readonly, although set to rw on fstab - #16 by brunomcl