Forum Discussion
Solved
Issue with old user permissions and NFS
I recently migrated my RN214 to expose NFS shares instead of SMB (no Windows PCs anymore). Turned out that there was a UID collision, user "volker" was auto-assigned UID 100 which I didn't care too m...
Here's what I did in a nutshell. Hope that helps.
# SMB → NFS Migration (UID/GID aligned)
* Problem: SMB does not reliably preserve timestamps → breaks rsync incremental backups
* Solution: switch to NFS with consistent UID/GID
---
# 0. Target State
* volker → UID 1000
* anja → UID 1001
* shared group: users (GID 100 on NAS + client)
* /data/Media → group RW (users)
* /home → per-user ownership
* NFS uses numeric IDs (must match!)
---
# 1. NAS Setup (RN214)
## Users
* Create:
* volker_new (UID 1000)
* anja_new (UID 1001)
* Trigger home creation via SMB login once
* Rename:
* old → *_old
* *_new → final names
## Fix ownership (/data/Media)
* chown -R --from=100:100 1000:100 /data/Media
* chown -R --from=101:100 1001:100 /data/Media
* cleanup check:
* find /data/Media -uid 100
* find /data/Media -uid 101
## Fix permissions
* chown -R :users /data/Media
* chmod -R 2775 /data/Media
## /home migration (if needed)
* move data or just:
* chown -R 1000:100 /data/home/volker
* chown -R 1001:100 /data/home/anja
* ensure ~/.ssh:
* chmod 700 ~/.ssh
* chmod 600 ~/.ssh/authorized_keys
## Final cleanup
* ensure no UID 100/101 left anywhere
---
# 2. Client Setup
## Group
* getent group users
* if missing: sudo groupadd -g 100 users
## Add users
* sudo usermod -aG users volker
* sudo usermod -aG users anja
* relog or newgrp users
## Install NFS + mount points
* sudo apt install nfs-common
* mkdir -p /media/rn214-Home
* mkdir -p /media/rn214-Media
---
# 3. NFS + fstab
## Enable on NAS
* /home → NFS on
* /data/Media → NFS on
* RW, async, root_squash, NO all_squash
## /etc/fstab
* rn214-volker:/home /media/rn214-Home nfs noauto,users,nfsvers=3 0 0
* rn214-volker:/data/Media /media/rn214-Media nfs noauto,users,async,nfsvers=3 0 0
* sudo systemctl daemon-reload
---
# 4. Test
* mount /media/rn214-Home
* mount /media/rn214-Media
## Verify IDs (IMPORTANT)
* ls -ln → must show:
* 1000 100
* 1001 100
## Write test
* touch + delete file → must work without sudo
---
# 5. rsync Migration (SMB → NFS)
## Copy
* rsync -aHAX --dry-run --no-xattrs --no-g /source/ /dest/
* rsync -aHAX --no-xattrs --no-g /source/ /dest/
## Verify
* rsync --dry-run again
* no output = perfect
## Finalize
* rename:
* user → user_old
* user_new → user
* test access
* delete old only after verification
---
# 6. Common Issues
* UID 100/101 still exist
→ migration incomplete
* permission denied
→ missing users group on client
* root issues
→ check NO all_squash
...even as admin user belonging to the admin group. sudo does not exist and for su - I don't know the root password - if there is any.
root is just a name, e.g. in /etc/passwd or some other authentication store. You could just as well call the account admin, and the OS itself won't care, ...
Key is the UID/GID:0 - this is what -all- U**x'es Kernel and the code care about.
There seems to be a long way ahead on your Linux learning curve. Not sure abandoning SMB in favour of NFS is a good idea therefore.
Well possible, there is -much-more around of these files and folders than U**x file and folder permissions:
Files can be secured through U**x file permissions - based on UID and GID - and through ACLs. Files with sticky bits, and files that are executable, require special security measures. What ever of these (visible and harder visible) does deny you desired action or actions.
Thanks for not being helpful at all. But perhaps you can shine your light on me to shorten the long and steep learning curve with some instructions how to change ownership of the files belonging to UID 100 to UID 1000 on the RN214 without copying over a large backup. Or alternatively how rsync -aHAX can update permissions of a NFS share when the target file belongs to a UID that does not match the user who runs rsync.
In terms of abandoning SMB: Whether or not the idea was good is indeed arguable. The truth being that after an update of my Linux PC, modification time of files copied to the NAS via cp -p or rsync -t was suddently not preserved anymore and I got fed up with this lottery messing up any reasonable incremental backup.
For details, head over to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2007055
https://community.netgear.com/discussions/readynas-use/modification-time-preservation-issue-using-smb-in-certain-configurations-with-re/2361349
and make sure to leave a juicy comment there as well.
The best way to do it is via the GUI. In the GUI, change the ownership of the share to the new user and then reset the permissions. It has to be done separately on each share, but is still easier than doing so via SSH. In general, it's best to use the GUI for things on a ReadyNAS unless the only way too do it is via SSH. The NAS OS uses basic Debian for much of the user permissions, folder options, etc., but also has a database of some things. Doing anything via SSH for which there is a separate database can create issues, and Netgear has never documented where those places might be.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
