Read-only media access and separate writable data

Read-only media access lets a server consume source files while directing required application and temporary writes to other locations.

Emby Server can read a source film without needing permission to overwrite that film. A media library can therefore use a read-only storage arrangement while the server's application-data and temporary locations remain writable.

This is a useful separation of data roles. It also makes the affected operations easier to understand: reading an existing movie and creating a new subtitle file are different storage requests.

Which workflow needs a write?

Workflow Source media access Separate writable data
Read and stream an existing film Read required Server application data remains writable
Transcode that film Read source Write temporary output
Store downloaded sidecars beside media Read relevant media; write sidecar location Depends on the chosen save location
Record into the media directory Write destination Recording and server state also update
Delete a media file Applicable deletion rights A viewer's delete permission is another check

A library configured to save artwork or metadata beside source media needs suitable writes for those files. If that location is read-only, those saves can fail even though playback succeeds. This is a consequence of the operation's destination, not an inconsistency in read-only access.

Mount, share and file restrictions

A mount can be read-only. A share can restrict writes. File-system permissions or ACLs can grant only the relevant access. These mechanisms have different scopes.

For example, a read-only mount seen by a container can restrict that container's view while the host has another writable view. File permissions apply according to identity and the underlying file system. A Windows file's read-only attribute is not a complete substitute for an access-control design governing creation and deletion of names in its directory.

The effective result comes from the entire path and operation. Directory traversal must still work, and listing a folder does not establish that its files are readable.

Viewer permissions are another boundary

An Emby viewer allowed to play a film does not acquire the server process's operating-system rights. Likewise, a viewer denied media deletion does not make the source mount read-only for every process.

Keep those checks distinct when diagnosing a failure. A permitted playback request can fail because the server cannot read the source. A prohibited delete request should remain prohibited even when the service identity technically has write access.

The server also needs persistent writable application storage for its configuration, database and other state. Making every location read-only does not create an ordinary read-only media server; it prevents required server work. Separate the media source from temporary output and persistent application data according to their actual roles.

See Also

References