Emby Emby Emby Learn
  • Emby Home
  • Video
  • Audio
  • Media Files
    • Subtitles and captions
    • Photos and images
    • Metadata and discovery
    • Libraries and media collections
    • Playback and streaming
    • Media hardware acceleration
    • Displays and AV connections
    • Live TV and recording
  1. Emby Learn
  2. Storage and server platforms
  3. Server execution environments
  4. Container execution
  5. Container volumes
Search Results for

    Show / Hide Table of Contents

    Container volumes and managed persistent storage

    A container volume stores data outside one container's writable layer, with a managed identity and lifecycle that require deliberate reuse and backup.

    A Docker volume is a managed storage resource that can be mounted into a container. Its contents live outside that container's writable layer.

    For Emby application data, that allows a replacement container to reuse persistent state—provided it mounts the intended volume at the application's actual data path.

    A volume has an identity and lifecycle

    Object What happens when its container is removed
    Container writable layer Removed with the container
    Named volume Can remain and be reused unless a separate applicable removal operation deletes it
    Anonymous volume Can remain under its generated identity; reuse requires finding or retaining that association
    Bind-mounted host tree Follows the host storage's lifecycle

    Persistence does not mean that every cleanup command preserves all volumes. Volume-removal and pruning operations have their own scopes. A new named volume with a similar label is also not the old volume's content.

    An original example is:

    Container C1: /config -> volume V1; state generation G1
    Container C2: /config -> volume V1; can open G1
    Container C3: /config -> new volume V2; does not thereby contain G1
    

    The paths and labels are fictional rather than a universal Emby image configuration.

    Initial content can be copied

    When an empty volume is mounted over a container directory that contains files, Docker normally copies those existing files into the volume. A nonempty volume mounted there instead covers the image's directory contents. Options such as volume-nocopy affect initialization.

    That mechanism explains why changing an image's packaged defaults does not necessarily replace configuration already stored in an existing volume.

    Persistence is not consistency or backup

    Several containers can mount a volume, but simultaneous access must be supported by the applications using its files. Sharing one database directory between independent servers does not make those servers a coordinated database cluster.

    Back up volume content through supported access and the application's consistency method. Docker documents managed volume access rather than treating its private host-storage layout as a directory to edit arbitrarily.

    The volume preserves a data lifecycle. Application-data backup supplies another recoverable generation, and restoration verifies that it can be used with the intended software and paths.

    See Also

    • Container bind mounts and host-path mappings
    • Persistent application data across server recreation
    • Application-data backups and consistent server state

    References

    • Docker volumes
    On this Page
    2026 © EMBY LLC. Please see our terms of use and privacy policy.
    Back to Top