File ownership and permissions across a library path

File access depends on the process identity, rights along the directory path and the requested operation, rather than the file owner's name alone.

A permission question needs three pieces of information: which process identity, which path, and which operation. “The file belongs to me” supplies only part of the answer.

For Emby, the process identity is the account under which the server runs. It may be a background-service account rather than the desktop user currently looking at the files. The Emby account signed in on a television is a separate application identity.

A file read begins with directories

To open /srv/media/Movies/Film.mkv, a Unix-style process resolves the path through each directory. Search permission, represented by the directory's execute bit, allows traversal to a named entry. Directory read permission allows listing names.

These are different rights. A process can be able to open a known file in a directory that it cannot list. A library scanner normally needs enumeration as well as access to the files it discovers.

Right	On an ordinary file	On a directory
Read	Read file content	List directory entries
Write	Modify file content	Create or remove entries, subject to other checks
Execute/search	Execute as a program when applicable	Traverse to entries by name

The table describes basic Unix discretionary permissions. ACLs, security modules, read-only mounts, capabilities and other restrictions can alter the complete access result.

Owner, group and other are selected classes

Consider this original example without extended ACLs or privilege overrides:

Process: UID 1100; groups {2000}
Directories /srv, /srv/media, /srv/media/Movies: searchable
File: owner UID 1200; group GID 2000; mode 0640
      owner rw-; group r--; other ---
Requested operation: read
Selected class: group
Result from these basic file-mode inputs: allowed

The process is not the owner. Its group set includes the file's group, so the group read bit supplies access. It does not matter whether the two users have friendly names such as “emby” or “media”; the numbers drive this model.

Now change the process UID to 1200 while retaining a file mode whose owner bits deny read and group bits allow it. The owner class applies. The check does not fail the owner test and then fall through to a more generous group or other class.

That rule prevents a common misdiagnosis: adding the owner to another group does not make the basic mode check ignore restrictive owner bits.

A blocked parent stops the path

Return to the first example and remove search permission from /srv/media for the relevant identity. The file's group read bit remains present, yet the process cannot reach the file through this path.

Increasing the final file's permissions would not fix the blocked parent. Inspect the component that actually failed. A container mapping or symbolic-link target can introduce a different path whose parents also need traversal rights.

For a scan, directory listing is another requirement. Successfully opening one precisely named file does not prove that enumerating its containing folder works.

Deletion acts on a directory entry

Changing file bytes and removing a filename are different operations. In ordinary Unix directory semantics, deletion depends on write and search rights on the containing directory, with additional checks such as the sticky bit where applicable.

A file whose contents are read-only can therefore still have its name removed by an identity with the relevant directory rights. Conversely, file write permission alone does not grant permission to remove that name from an unwritable directory.

This is why “the file is read-only” is incomplete evidence for a no-deletion policy. Hard links make the distinction especially visible: removing one permitted name does not necessarily remove the shared object's other names.

Listing, reading and saving can split into three outcomes

Suppose the service has read and search access to a media directory, and read access to its film. The scan can enumerate the name and open the film. Now the server attempts to save a newly downloaded subtitle beside it.

That save creates a new directory entry. It needs the relevant directory write permission as well as traversal. Read access to the film does not grant that operation.

If the subtitle already exists, updating its bytes instead involves that file's own access rights. A tool that saves by creating a temporary file and renaming it can also require rights for the directory operations. “Save a subtitle” can therefore represent more than one operating-system request.

Intended work	Basic Unix checks emphasized in this example
Discover the film by listing	Directory read and search
Read the known film	Path traversal and file read
Create a new sidecar	Parent directory write and search
Modify an existing sidecar in place	Path traversal and sidecar write
Publish by rename	Applicable source/destination directory rights and other rename checks

This is a deliberately limited discretionary-permission model, not a complete platform access check. It makes the failure location concrete: successful playback and a failed sidecar save are consistent with a directory that allows reads but denies creation.

Shared storage adds more decisions

For SMB, the accepted session identity and share policy participate before underlying file access. For NFS, the credential arrangement, export policy and identity mapping participate. A remote username displayed in a client interface is not proof of the final server-side identity.

Windows uses its own access rights and ordered DACL evaluation rather than the Unix owner/group/other algorithm. Translate the intended operation into the platform's real access model instead of trying to apply a Linux mode number to every system.

When diagnosing an Emby storage failure, identify the service identity, the resolved location and the failed operation first. Then inspect the relevant directory, file, share or mount rule. This creates a specific explanation for “permission denied” and avoids broadening access to unrelated files merely because the initial error was vague.