Container bind mounts and host-path mappings

A container bind mount exposes a selected daemon-host path at a container path, with the source tree and process identity still determining access.

A bind mount exposes a host file or directory at a chosen path inside a container. The two pathnames can be entirely different.

An original media mapping is:

Daemon-host source: /srv/media/Movies
Container target:   /media
Container file:     /media/Film.mkv
Host file:          /srv/media/Movies/Film.mkv

Emby configured inside the container uses /media. It does not need the host's path text to be identical, but the mapping must point at the intended source.

The source belongs to the daemon's host

If a Docker client controls a remote daemon, the bind source is resolved on the daemon's machine. A directory on the client laptop is not automatically uploaded into that source path.

Similarly, a desktop container environment may have a supported file-sharing path into its Linux execution environment. The surrounding host arrangement participates in access and performance.

A source pathname can identify the wrong tree

Source condition Possible result
Intended mounted media tree is available The mapping exposes that tree
Mount absent but underlying directory exists The mapping can expose the underlying directory
Source path absent Behavior depends on the mount syntax/options
Source present but unreadable to container identity Mount existence does not supply file read permission

Docker's ordinary --mount bind syntax reports a missing source rather than silently creating it. The -v syntax can create a missing host source as a directory; documented options can change particular behavior. This is a syntax distinction, not a guarantee that the mounted data are the correct collection.

A read-only bind mapping restricts writes through that view. It does not automatically make every other host or container view read-only.

Mapping and permissions are separate

The container process's actual IDs, any user-namespace mapping, underlying file permissions and other access rules determine what it can open. A correct mapping can still produce denied access.

For an Emby scan, verify the intended tree and readable files from the container's environment. A wrong empty directory and a correct directory with denied access are different failures even when neither yields movies in the scan.

See Also

References