NFS Permissions¶

How It Works¶

The Synology NAS NFS share is configured with Map root to admin. This means:

Connections from root (UID 0) are remapped to the admin user on the NAS — root has no special access.
NFS folders are owned by the administrators group on DSM.
The docker user (UID 1034, GID 100) has read/write permission to these folders.
Any container that needs to read or write NFS-backed volumes must run as 1034:100.

If the UID/GID is wrong, the container will get Permission denied errors on the mount.

For Helm-based apps, set the security context in the HelmRelease values:

podSecurityContext:
  runAsUser: 1034
  runAsGroup: 100
  fsGroup: 100

For plain Deployments:

spec:
  template:
    spec:
      securityContext:
        runAsUser: 1034
        runAsGroup: 100
        fsGroup: 100

fsGroup ensures the mounted volume is group-accessible at startup, which is required for apps that initialize files on first run.

Symptom	Cause	Fix
`Permission denied` on NFS mount	Container running as wrong UID/GID	Set `runAsUser: 1034`, `runAsGroup: 100`
Files created as `nobody:nogroup`	NFS squashing root without correct UID set	Set `fsGroup: 100` in pod security context
rsync fails in backup CronJob	rsync running as root, squashed on write	Use `su-exec 1034:100` to run rsync as the NFS owner
`rsync: chgrp failed: Operation not permitted`	Backup NFS share owned by wrong group	On the NAS, set the owner of the backup share directory to `docker` via File Station
App starts but can't write config	App uses a hardcoded UID that differs from 1034	Chown the NAS directory to `1034:100` manually, or check if app supports overriding UID