Why Do File Permissions Break After Moving Files to a NAS?

Files can work normally on a computer, external drive, or download folder and then become read-only, invisible to an app, or inaccessible after they are moved to a NAS. That usually does not mean the file data is damaged. It means the files entered a new filesystem with a different ownership and permission model.

A cross-device move is commonly performed as a copy followed by deletion of the source. The NAS creates new files using the connected SMB or NFS identity, destination-folder ACLs, UID and GID values, umask, container user, and server-side creation rules. The fastest way to fix the problem is to identify who created the files, who owns them now, and which user or process is being denied.

Moving Files to a NAS Usually Creates New Files

Dragging a folder to a NAS may look like an ordinary move in Windows Explorer or Finder. Underneath, however, the source disk and NAS are separate filesystems. The client reads the original data, creates new destination objects, and deletes the originals after the transfer succeeds.

This differs from moving a file between two folders on the same filesystem, where the system may only update the file’s directory location. Microsoft’s description of copy and move behavior explains that objects copied to another volume inherit the permissions of the new folder, while a same-volume move normally retains existing permissions.

That distinction explains why “Cut and Paste” does not guarantee that ownership, ACL entries, or extended attributes will remain identical after a transfer to a NAS. The destination system is not simply relocating the original filesystem object.

Destination ACLs Decide What New Files Inherit

If every newly copied file receives the same unexpected permissions, the parent directory is usually more important than the source file. The destination may have inherited ACL entries, default POSIX ACLs, NFSv4 ACL flags, or NAS-specific permission presets.

For example, a shared folder may be configured so that new files inherit access for a family group, a media group, or a particular SMB account. A missing inheritance flag can create the opposite result: users may access the dataset root but not new files inside it.

TrueNAS-style permission systems distinguish POSIX and NFSv4/SMB ACL models. The important behavior is that NFSv4 and SMB ACL inheritance can control new files and folders, while POSIX defaults and dataset boundaries behave differently. Before changing individual files, inspect the ACL and inheritance flags on the destination folder.

The NAS Uses the Connected SMB Account

When a Windows or macOS computer copies a file over SMB, the NAS does not normally preserve the client computer’s local user identity. It creates the destination file as the account authenticated to the SMB share, or as an account to which that session is mapped.

This is why a file owned by a Windows user on the source PC may be owned by kenneth, nasuser, guest, or another NAS-side identity after the transfer. A saved SMB credential can also cause one computer to create files under a different owner than another computer.

Check the active SMB username rather than assuming the desktop login is being used. Disconnect the share, clear stale credentials if necessary, and reconnect with the NAS account that should own or manage the files.

Share Access and File Access Are Separate Permission Layers

A user may be able to open the SMB share and browse folders but still be unable to edit, rename, or delete a file. This means the network share is reachable; it does not prove the filesystem has granted the requested operation.

Share-level rules determine whether an SMB or NFS client may enter the share and whether the connection is presented as read-only or read/write. The underlying filesystem then evaluates the owner, group, mode bits, ACL entries, and inheritance rules for each file and directory.

Troubleshoot both layers. A share marked read/write cannot override a filesystem ACL that denies writing, and permissive filesystem modes do not help when the SMB account is restricted by the share configuration.

Windows-Style ACLs and POSIX Modes Do Not Map Perfectly

Windows permissions can contain multiple users and groups, explicit allow and deny entries, inheritance flags, and separate rights for reading, writing, deleting, and modifying. Traditional POSIX mode bits reduce access to owner, group, and other.

Samba and NAS operating systems must translate between those models. A Windows Security panel may show a detailed ACL even though ls -l displays only a simplified representation. Conversely, running chmod may alter mode bits without correctly rebuilding the Windows-style ACL that SMB clients expect.

If the NAS dataset uses NFSv4 or SMB ACLs, inspect the full ACL through the NAS interface or an ACL-aware command. Do not assume that a file showing rwxrwx--- tells the entire permission story.

UID and GID Mismatches Affect Linux, NFS, and Apps

Linux systems usually determine ownership through numeric user IDs and group IDs. The username is only a label associated with those numbers.

Two systems can both display a user called media while one uses UID 1000 and the other uses UID 1001. To Linux and NFS, those are different identities. A file owned by UID 1000 may be inaccessible to an application running as UID 1001 even when their visible usernames look identical.

Check numeric values on the NAS, host, client, and application:

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

Compare the numbers rather than only the displayed names. If multiple systems need to write the same storage, align the required UID/GID values or create a shared group with the correct permissions.

SMB and NFS May Write the Same Dataset as Different Users

Permission problems often appear gradually when SMB clients and NFS clients both have write access to the same directory. Files uploaded through SMB may belong to one NAS user, while files created through NFS may carry a numeric UID from another system.

The two protocols can also apply different ACL and identity-mapping rules. As a result, a folder may contain files that look identical to a user but have different owners, groups, masks, or inherited entries.

Choose one primary write protocol when possible. When SMB and NFS must share a dataset, align numeric IDs, shared groups, default ACLs, umask values, and creation behavior before placing production data in it.

Docker Containers Add Another User Identity

A file may be readable through SMB but unavailable to Plex, Jellyfin, Nextcloud, a downloader, or a backup container. Docker can mount the correct path while the process inside the container still lacks permission to read or write it.

A container process runs under a UID and GID of its own. If that identity does not match the owner or an allowed group on the mounted NAS path, the application receives Permission denied. A volume mount makes the directory visible; it does not bypass filesystem authorization.

A common solution is to match the container UID and GID with the identity allowed to use the mounted volume. Verify the actual process identity rather than relying only on a PUID or PGID field shown in a Compose file:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Writable"

One Container Can Create Files Another Cannot Read

This frequently happens in media automation stacks. A download container successfully writes a completed file, but the media server cannot scan it, or an organizer cannot rename it.

The applications may use different UID/GID values or different umasks. If the downloader creates files as 600, only its owner can read and write them. A mode such as 640 allows group reading, but only when both applications share the correct group.

For shared application directories, use a planned owner group, add the necessary application identities to that group, and select a umask that gives the group the required access. Fixing only old files will not help if the downloader continues creating new files with restrictive modes.

Umask and Server Creation Rules Control New Permissions

If old files work but every new file is inaccessible, the creation process is the likely cause. Each program begins with a requested file mode, and its umask removes selected permissions before the file is created.

Samba may also use settings such as create mask, directory mask, force user, or force group. NAS interfaces may hide these behind permission templates, shared-folder presets, or inheritance options.

Create one test file through each path: Windows SMB, macOS SMB, NAS file manager, NFS, and each relevant container. Compare the resulting owner, group, mode, and ACL. This quickly reveals which creation path produces the broken permissions.

Different Transfer Tools Preserve Different Metadata

Finder, Windows Explorer, a NAS web interface, cp, and rsync do not guarantee identical results. Some preserve timestamps, some can retain POSIX modes, and others simply create new files under destination rules.

Before choosing a migration method, decide which properties must survive:

• File contents and directory structure
• Modification times
• POSIX permissions
• Owner and group
• ACL entries
• Extended attributes
• Symbolic links

For ordinary family documents or media files, destination inheritance may be preferable to preserving source computer accounts that do not exist on the NAS. For application data, Linux home directories, or server migrations, preserving ownership and ACL metadata may be essential.

Rsync Does Not Preserve Every Attribute With One Basic Command

Rsync is useful for controlled NAS migrations, but the result depends on its options, the privileges of the executing user, and the capabilities of the source and destination filesystems.

Archive mode preserves common metadata including modes, timestamps, groups, and ownership where permitted. Additional options are required when the migration must preserve permissions, ACLs, and extended attributes with rsync. A typical Linux-to-Linux test may use:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

The -A option preserves ACLs and -X preserves extended attributes when both sides support them. --numeric-ids should be used deliberately because preserving a numeric owner that has no valid account on the NAS can reproduce the very mismatch you are trying to avoid.

An SMB-Mounted Rsync Destination May Not Behave Like the NAS Filesystem

Running rsync from a computer into a locally mounted SMB share is not always equivalent to running rsync over SSH directly against the NAS filesystem. The SMB layer may map owners, transform ACLs, or reject attempts to set attributes.

The user performing the SMB copy may not have permission to assign arbitrary ownership, even when rsync requests it. The destination filesystem may also support a different ACL model from the source.

Test a small representative directory first. Examine the files directly on the NAS after the transfer, not only through the client’s mounted share. Confirm ownership, modes, ACLs, extended attributes, and application access before migrating the full dataset.

NAS Permission Presets Can Override Simple Mode Bits

Some NAS systems manage access through dataset ACL templates and extended metadata rather than only traditional owner/group/other modes. This can make a manual chmod appear successful while SMB or an application continues to deny access.

A dataset may also be configured to reapply inherited rules when new files are created or when permissions are edited through the management interface. Mixing GUI-managed ACLs with repeated command-line changes can produce an inconsistent state.

Choose one permission model and manage it consistently. If the dataset is configured for an SMB/NFSv4 ACL, use the NAS ACL editor or ACL-aware tools instead of repeatedly replacing the structure with POSIX mode commands.

Reinstalling the NAS Does Not Necessarily Reset Data Permissions

Permissions usually belong to the files and filesystem dataset, not merely to the NAS operating-system configuration. Reinstalling the boot system may therefore leave the same inaccessible ownership and ACL entries on an imported storage pool.

A TrueNAS community case illustrates how filesystem permissions remain attached to the storage pool and must be matched with the correct users and access configuration. It also shows the risk of making large recursive changes without first understanding the intended identity model.

Before reinstalling or rebuilding services, inspect the dataset owner, group, ACL, and application users. The data may be intact and only require its access rules to be restored correctly.

Why Recursive chmod 777 Is Not a Real Fix

When thousands of files become inaccessible, chmod -R 777 looks like a fast way to restore access. It grants read, write, and execute permission to the owner, group, and every other local identity.

That can expose private data, allow unrelated services to modify files, set execute permission on ordinary documents, and damage a carefully inherited ACL structure. It also does not correct the wrong owner, mismatched container UID, missing group membership, or broken SMB identity mapping.

Use the intended access model instead: establish the correct owner and shared group, rebuild the appropriate ACL, set directory and file modes separately, and correct future inheritance and umask settings. Test on a small folder before applying recursive changes.

Repair Permissions From the Identity Outward

Start with the denied user or process rather than the command you hope will fix it. A human SMB user, a media server, and a backup container may require different levels of access.

For each affected workflow, record:

• The user or process attempting access
• Its numeric UID and GID where applicable
• The protocol or mount used
• The file’s current owner and group
• The complete ACL and inherited entries
• The access actually required: read, create, modify, or delete

Then modify only the layer that is wrong. Add the user to an allowed group, correct ownership, repair the ACL, align a container UID, or update the creation rule. Avoid granting broader access than the workflow needs.

Follow a Layered Troubleshooting Order

Changing the share ACL, container identity, NFS export, and file modes at the same time destroys useful evidence. Test one permission layer at a time.

Begin with one affected file and one affected user or application. Once that small case works, create a new file through the normal workflow and confirm that the fix also prevents the problem from returning.

Prevent Permission Problems Before a Large NAS Migration

Repairing permissions across hundreds of thousands of files is much harder than testing the access model before migration. Build a small destination folder with the same ACL and application configuration planned for the final dataset.

Copy several file types, nested directories, read-only files, executable scripts, and files with extended attributes. Test them from each required path: SMB, NFS, the NAS interface, backup software, and relevant containers.

Only begin the full migration after new files consistently receive the correct owner, group, ACL, and application access. Keep a snapshot or backup before applying any recursive ownership or permission changes to existing data.

Final Takeaway

File permissions break after moving data to a NAS because the transfer usually creates new filesystem objects. Those objects are governed by the NAS account used for the transfer, the destination ACL, UID/GID values, umask, protocol mapping, and application or container identity.

Do not begin with chmod 777. First answer three questions: who created the file, who owns it now, and which identity is being denied. Then inspect share access, filesystem ACLs, inheritance, container IDs, and future creation rules.

A successful repair should do two things: restore appropriate access to the existing files and ensure that the next file copied, downloaded, or created on the NAS receives the correct permissions automatically.

FAQ

Why do copied files inherit the NAS folder’s permissions?

A transfer to a NAS usually creates new files on another filesystem. New objects are commonly assigned permissions from the destination folder’s ACL, inheritance flags, and server-side creation rules.

Why can I open NAS files over SMB but my Docker container cannot?

The SMB session and the container use different identities. Check the container’s actual UID and GID, the mounted path’s numeric ownership, group membership, and whether the mount is read-only.

Should I use chmod 777 to repair a NAS share?

No. It grants every local identity broad access, may damage ACL inheritance, and does not solve incorrect ownership or UID/GID mapping. Define the intended users and groups, then repair ownership and ACLs accordingly.

Can rsync preserve NAS file permissions?

It can preserve POSIX permissions and other metadata when the selected options, executing privileges, and both filesystems support them. ACLs and extended attributes require additional options such as -A and -X.

Why do new files keep breaking after I repair the old files?

The creation path is still wrong. Check the destination folder’s inherited ACL, the SMB or NFS identity, application umask, Samba create rules, and container UID/GID.