Linux user and group IDs in storage access

Linux storage access uses process and file user/group IDs, so matching account names do not guarantee matching permissions across hosts or namespaces.

Linux identifies users and groups numerically. Account names provide readable labels, but a file's ownership and a process's credentials contain IDs.

A media directory owned by a user named emby on one computer does not automatically belong to the server process named emby on another. The numbers and any mapping rules have to line up.

One name can label different numbers

An original example uses ordinary file-permission checks without extended ACLs or privilege overrides:

Host A: emby -> UID 1100
Host B: emby -> UID 1200
File owner: UID 1200
Host A process with UID 1100 is not this file's owner.

The reverse is also possible: two computers can display different names for the same numeric ID. That matters for simple numeric-ID network arrangements and for files moved without translating ownership.

For local Linux file access, filesystem UID and GID are used with supplementary groups. These usually match the effective UID and GID. Specialized programs can change them, so the general rule concerns the process's actual credentials rather than the desktop's visible account name.

Groups belong to the running process

A process has a primary group and a set of supplementary groups. Those credentials are normally established when it is launched.

Changing an account's group membership in the account database does not automatically rewrite the supplementary groups of every existing process. A newly launched shell can therefore have a group that a still-running server lacks.

Observation What it describes
Account database says “member of media” Membership available to a new credential setup
Running process lists GID 2000 That process currently has the group
File's group is GID 2000 Group associated with this file object
A label displays “media” A local name for an ID, not proof of all three states

In a fictional read test, a file owned by another UID with group 2000 and mode 0640 is readable through the basic group class when the process has GID 2000. Removing that GID from the process's current groups changes the result. The name printed for group 2000 does not change the calculation.

A namespace can translate IDs

A user namespace can map an ID inside a container to another ID outside it. An apparent UID zero inside the namespace is not automatically the host's privileged UID zero. Mount arrangements can also have ID mappings that affect ownership interpretation.

For NFS, the authentication arrangement and server mapping determine the accepted identity. For SMB, session credentials can be mapped to a server-side user. A host id result cannot alone establish those remote decisions.

When Emby can see a directory but cannot read newly added files, compare the running process's IDs and groups with the actual file ownership and permissions. This keeps the investigation specific to the file and credential state, rather than treating matching names as evidence of access.

See Also

References