Linux / Bash

Linux chown -R Not Changing Permissions on Mounted Network Drives (NFS/SMB)

chown appearing to succeed but having no actual effect on a network-mounted drive almost always means the mount itself is configured in a way that either ignores ownership changes entirely, or maps ownership according to rules controlled by the remote server rather than anything the local chown command can override.

The Problem

Running chown -R on files within an NFS or SMB/CIFS mounted directory completes without an error, but checking ownership afterward shows no actual change:

sudo chown -R appuser:appgroup /mnt/network-share/data
ls -la /mnt/network-share/data
# still shows the original owner, unchanged

The command reports success, which is what makes this particularly confusing — there's no error message pointing at what actually went wrong.

Why It Happens

Network filesystems handle ownership fundamentally differently from local filesystems, and several specific configurations commonly prevent chown from having any real, persistent effect:

  • For SMB/CIFS mounts specifically, ownership is very often controlled entirely by mount options (like a fixed uid/gid specified when the share was mounted) rather than being changeable per-file at all — the mount itself may present all files as owned by a single, fixed user regardless of what chown attempts to set
  • For NFS mounts, ownership changes depend on the NFS server's own configuration and the UID/GID mapping between client and server — if the server uses ID mapping or squashing (like root_squash, which maps the root user's requests to an unprivileged user on the server side), a chown attempt from the client may be silently constrained by what the server actually permits, regardless of local permissions appearing to allow it
  • The underlying filesystem export on the remote server might not support the ownership model being requested at all, particularly relevant when the remote filesystem itself doesn't have a full Unix-style permission model (common with certain NAS devices or Windows-based SMB shares)

The Fix

First, check exactly how the network share is currently mounted, since the mount options themselves often explain the behavior directly:

mount | grep network-share

For SMB/CIFS mounts, look specifically for fixed uid=/gid= options in the output — if present, these force all files to appear owned by that specific configured user/group regardless of anything chown attempts, and the actual fix is remounting with different mount options rather than trying to change ownership after the fact:

sudo umount /mnt/network-share
sudo mount -t cifs //server/share /mnt/network-share -o username=user,uid=1000,gid=1000,file_mode=0644,dir_mode=0755

Adjusting uid/gid in the mount command itself, rather than trying to chown individual files afterward, is the correct approach for SMB/CIFS shares configured this way, since the mount option is what actually determines the ownership every file will appear to have.

For NFS mounts, check whether the server is applying root squashing, which specifically maps requests from the client's root user to an unprivileged user on the server side, which can constrain what ownership changes actually take effect even when run as root on the client:

# Check the NFS export configuration on the server side (in /etc/exports)
cat /etc/exports
# look for options like root_squash, all_squash, no_root_squash

If you control the NFS server and genuinely need full ownership control from the client, no_root_squash can be configured on the server's export — but be aware this has real security implications, since it means the client's root user has full root-equivalent access to the exported filesystem on the server, which should be a deliberate, carefully considered choice rather than a default configuration change made without understanding the tradeoff.

If you don't control the remote server's configuration (a shared NAS managed by someone else, a corporate file server), confirm with whoever does control it what ownership model is actually supported and how it's meant to be managed — for many managed network shares, ownership is intentionally controlled server-side through the file server's own user management, not something individual clients are meant to change via a simple chown at all.

Still Not Working?

If you've confirmed mount options and server-side configuration both appear correctly set up to allow ownership changes, but chown still has no effect, check whether the underlying remote filesystem itself even supports full Unix-style ownership at all — some NAS devices and certain SMB share configurations map everything to a single, fixed identity regardless of client-side settings, in which case per-file ownership simply isn't a supported feature of that specific share, and the actual fix requires either reconfiguring the share at its source (if that's genuinely possible for your specific NAS or file server) or restructuring your application's access pattern to not depend on differentiated per-file Unix ownership on that particular network location at all.

You might also like