New container install with a persistent volume, and the app cannot write to its own data directory

The thing to internalise: a bind mount does not translate ownership. The kernel checks numeric IDs, and the container and the host disagree about what those numbers mean.

Inside the container the process might run as a user called app with UID 1000. On the host, UID 1000 is your login account, or nobody at all. The directory on the host is owned by some other UID. The kernel compares the numbers, they do not match, and the write is refused.

So the name of the user is irrelevant on both sides. Only the number matters.

Find the two numbers and the problem becomes arithmetic:

docker exec <container> id          # what the process runs as
ls -ln /path/on/host                # numeric owner of the directory

Once those two agree, it works. Everything below is a way of making them agree.

The fixes, best first:

1. Change the host directory to the container's UID. chown -R 1000:1000 /path/on/host, using whatever number id reported. Explicit, permanent, no surprises.

2. Run the container as the host directory's owner. Many images accept a user at run time, and many published images accept UID and GID as environment variables specifically to solve this. Check the image's documentation before doing anything else — a lot of the friction people hit here is reinventing a setting the image already has.

3. Use a named volume instead of a bind mount if you do not need the files at a specific host path. The volume driver initialises ownership from the image, so this problem largely disappears. Bind mounts exist for when you need the exact path; named volumes are the better default for data.

What not to do: world-writable. It works because it disables the check, on a directory holding your data, on the host. If the container is ever compromised, so is anything else on the box that can reach that path.

Two complications worth knowing before you go hunting.

Mandatory access control. On distributions with SELinux enforcing, a bind mount also needs the right label, and the symptom is identical permission denied with correct-looking ownership. The mount option :Z or :z relabels it. If ownership looks right and it still fails, this is usually why.

Rootless containers. With user namespaces, the UID inside is mapped to a different UID outside, so the number you see with id inside is not the number the host sees. You have to compute the mapped ID, and the arithmetic is unintuitive the first time.

Both of these are why the ownership advice sometimes appears not to work, and both are worth ruling out before assuming something stranger.

One practical habit: create the host directory yourself with the right ownership before the first run, rather than letting the engine create it.

When the directory does not exist, the engine creates it owned by root, the container starts as a non-root user, and you get this failure on a brand new install with nothing obviously wrong. Creating it in advance with the intended owner makes the setup reproducible and documents the requirement.