Frequently Asked Question
A QNAP container runs until I map its data folder, then shows Permission denied. Why?
QUICK ANSWER
The mapped host folder, mount access mode and container’s runtime identity must agree. A NAS administrator being able to open the folder does not prove the process inside the container can write there.
Applies to: Container Station persistent storage, including bind mounts and named volumes.
Work through these checks
- Save the exact log entry and path. Identify whether the mount is a host folder or a named volume, and back up the app’s existing persistent data before changing its mapping.
- Compare the host location with the container mount point and the image’s documented data directory. Mounting an empty folder over an existing container directory hides its previous contents; it does not copy them into the new folder.
- Check read-only versus read/write mode and the runtime user or UID/GID required by the image. Have the administrator grant the minimum needed access to that app’s specific folder, preserving unrelated NAS permissions.
- Restart the affected container and perform a small write in the app. Confirm that the data remains after a normal container restart. Keep the old configuration until this succeeds.
Confirm the result
The error no longer occurs, the app can save its settings and its persistent data survives restart at the intended host location.
Before going further: Do not use recursive chmod 777, run an unfamiliar image privileged, prune volumes or reinstall Container Station with data deletion as a first fix.
If you need help
Include these details in your ticket: Image/tag, Container Station version, failing path, mount type/mode and redacted runtime-user/permission details.
Updated 261107