A rootless worker writes into a bind-mounted host directory, and the new files show a high, unowned id - why?

## Where the strange number comes from Id remapping gives a container a contiguous block of host ids - typically a large block of high, otherwise unused numbers - and translates ids in both directions at the boundary. Inside id `0` is the base of the block; inside `1` is the next one; the whole range shifts by a fixed offset. So when the queue consumer, running as id 0 inside, creates a file on a host directory mounted into it, the kernel records the **mapped** host id as the owner, because that is the id the process really carries on the host. The number is not a corruption and not a bug: it is the inside id plus the offset. Nothing on the host is registered under it, so a directory listing has no name to print and shows the digits. This is also why the numbers look arbitrary but are not. A file created inside by a service account with inside id 1000 shows up as base plus 1000. If you know the base, you can read the ownership backwards and tell exactly which inside identity wrote the file. ## The same mechanism, read from both sides | Direction | What you do | What you see | Why | |---|---|---|---| | Writing out | Worker (inside 0) creates a file on a mounted host directory | Host shows a high, nameless owner id | The kernel records the mapped host id, not the reported inside id | | Reading in | Worker (inside 0) opens an existing host file owned by the operator | Refused, though the process reports as root | The operator's host id is outside the container's block, so inside it is an unmapped foreign id | The second row is the one that surprises people, because it looks like root being refused. It is not: the process is root over the container's view, and the file's owner is not in that view at all. Many setups render such an owner as a single catch-all unmapped id, which is why the file appears to belong to nobody in particular - and why no amount of changing the process's inside identity fixes it. ## Why the kernel cannot simply trust the inside number If the inside number were taken at face value, the entire point of remapping would collapse. Any unprivileged operator could start a container, declare itself id 0 inside, write through a mounted path and own host files as root. The translation is not a cosmetic inconvenience on top of the boundary - it **is** the boundary for file ownership. Every awkward symptom in this section is the mechanism working. That also explains a related trap. Changing a file's ownership from inside the container changes it to an inside id, which maps to another id in the same block. It can never set a host id outside the block, because the process has no authority over ids it is not mapped to. A workload cannot chown its way out of the mapping. ## Making a shared host directory actually work There is no single fix, but there is a short list of honest ones: - **Make the directory's ownership match a mapped id.** Set the host directory to the mapped equivalent of the inside id the workload runs as, so both sides agree. - **Use a group both sides can see.** Give the directory a group whose host id falls inside the mapped block, and run the workload under the corresponding inside group. - **Align the mapping deliberately.** Some setups map one chosen inside id onto one chosen host id so a specific account matches across the boundary, rather than shifting the whole block blindly. - **Stop sharing the directory.** If nothing on the host needs to read those files, a storage location the platform provisions and tracks for the container avoids the negotiation entirely - that is a separate decision about where the data should live. - **Do not paper over it with a wide-open mode.** Making the directory writable by everyone does make the symptom go away, and it hands every other workload on that host the same access. ## Reading the symptom quickly 1. If host listings show high nameless ids on files a container created, remapping is on and you are seeing the offset. That is expected; decide whether the host needs to read those files at all. 2. If a process that reports as root is refused on an existing host file, compare the file's host owner with the container's mapped block before touching privileges. This is an id problem, and granting a privilege will not fix it. 3. If the same workload behaves differently on two hosts, check whether one of them remaps ids and the other does not. That single difference changes who owns everything the workload writes through a mounted path.