Quick answer

What this guide helps you do

Mount a USB storage filesystem reliably on the Ubuntu host, pass its path into Docker and solve UID, GID, read-only and reboot-order problems.

Separate two jobs

Ubuntu mounts the USB filesystem. Docker bind-mounts the established host path into a container. Do not make the application container responsible for mounting the drive.

Identify the correct device

lsblk -o NAME,SIZE,FSTYPE,UUID,LABEL,MOUNTPOINTS,MODEL,SERIAL
sudo blkid
findmnt

Confirm model, size, serial, filesystem and existing data. This guide does not format the device.

Create a stable host mount

Use a UUID-based fstab entry and a server path such as /srv/usb-media. Back up fstab, create the mount point, run findmnt —verify and mount -a, then prove the intended filesystem is present.

Read Mount a Drive Automatically with fstab before continuing.

Check host access

findmnt /srv/usb-media
df -hT /srv/usb-media
stat /srv/usb-media
namei -l /srv/usb-media

Native Linux filesystems store normal ownership. NTFS and FAT commonly need deliberate mount options because they do not provide the same Unix ownership model.

Pass the path into Compose

services:
  app:
    volumes:
      - /srv/usb-media:/media:ro

Start read-only unless the application genuinely needs to modify the drive. Keep writable configuration in a separate path.

Compare container identity

sudo docker compose up -d
sudo docker inspect YOUR_CONTAINER --format '{{json .Mounts}}'
sudo docker exec YOUR_CONTAINER id
sudo docker exec YOUR_CONTAINER sh -c 'ls -la /media | head'

If writing is required, compare numeric UID and GID with the host filesystem and make the narrowest ownership, group or ACL change.

Prevent wrong-disk writes

If the USB drive is absent, the mount-point directory may still exist on the root filesystem. Stop the service when the expected findmnt result is missing. Consider a host-level mount dependency or pre-start check for critical data paths.

Verification checklist

  • Device identity and data were confirmed.
  • The host uses a stable UUID mount.
  • The expected filesystem is mounted before Docker.
  • Compose source and destination are correct.
  • Access is read-only unless writes are required.
  • UID and GID behaviour is understood.
  • The container sees expected files after reboot.
  • USB data has an independent backup.

USB bridge behaviour and filesystem permissions vary; this is a diagnostic method, not universal tested evidence.

Next: Fix a Drive That Disappears After Reboot. Return to Mount a Drive Automatically with fstab.

Official reference: Docker bind mounts.