Skip to content

Fix: Avoid failing startup when chown is not permitted on bind mounts#24

Open
tilwegener wants to merge 2 commits into
xoriin:mainfrom
tilwegener:main
Open

Fix: Avoid failing startup when chown is not permitted on bind mounts#24
tilwegener wants to merge 2 commits into
xoriin:mainfrom
tilwegener:main

Conversation

@tilwegener

Copy link
Copy Markdown

Summary

The container currently attempts to chown the configured data directory (/app/data) during startup based on the configured PUID and PGID.

On some environments this causes the container to fail during startup with:

chown: changing ownership of '/app/data': Operation not permitted

Affected environments

This can happen when running with:

  • Docker containers using cap_drop: ALL (without CAP_CHOWN)
  • Rootless Docker
  • Proxmox unprivileged LXC containers
  • NFS/CIFS/SMB bind mounts
  • Other filesystems where ownership changes are not permitted

Even when the bind-mounted directory is already owned by the correct UID/GID, the container still attempts to perform a recursive chown.

Expected behavior

If the configured directory is already writable by the application user, the container should continue starting without attempting to change ownership.

If ownership cannot be changed, the startup should emit a warning instead of terminating, allowing the application to run when permissions are already sufficient.

Possible solutions

  • Skip the recursive chown when the directory is already owned by the configured UID/GID.
  • Gracefully ignore EPERM / Operation not permitted errors.
  • Make the ownership adjustment optional via an environment variable (for example DISABLE_CHOWN=true or SKIP_CHOWN=true).
  • Only perform the ownership change on first initialization.

Reproduction

Using a bind mount:

volumes:
  - ./app/data:/app/data

with:

environment:
  PUID: 1000
  PGID: 1000

results in:

usermod: no changes
chown: changing ownership of '/app/data': Operation not permitted

The directory on the host is already owned by the configured user/group:

drwxr-xr-x user sudo ./app/data

The application would be able to access the directory, but startup fails because the unconditional chown returns an error.

Additional notes

Making the ownership adjustment optional would improve compatibility with a variety of container runtimes and storage backends while maintaining the current behavior as the default.

Added capabilities CHOWN, SETUID, and SETGID to the Docker configuration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant