Quick answer

What this guide helps you do

Diagnose a disk that is present before reboot but missing afterwards by checking hardware detection, UUID-based fstab, filesystem errors, mount ordering and logs.

Do not format the disk

A missing mount does not mean the filesystem needs recreating. Formatting destroys filesystem metadata. Diagnose detection and mounting first.

Check whether Linux sees the device

lsblk -o NAME,SIZE,FSTYPE,UUID,LABEL,MOUNTPOINTS,MODEL,SERIAL
sudo blkid
sudo dmesg -T | grep -Ei 'usb|ata|scsi|nvme|reset|error|fail' | tail -n 100

If the device is absent from lsblk, investigate power, cable, USB bridge, controller and kernel logs. An fstab edit cannot mount hardware the kernel does not see.

Check fstab and UUID

sudo findmnt --verify
cat /etc/fstab
sudo blkid

Match the UUID and filesystem type exactly. Replace unstable /dev/sdX references with UUID identifiers. Confirm the mount-point directory exists.

Test without rebooting

sudo mount -a
findmnt /srv/data
df -hT /srv/data
sudo journalctl -b --no-pager | grep -Ei 'mount|filesystem|fsck' | tail -n 100

Do not reboot until mount -a is clean and expected files are visible.

Handle optional and slow devices

For non-essential removable storage, nofail can allow boot to continue if absent. Some setups benefit from systemd device timeouts or automounting, but those options change failure behaviour. Use them deliberately and test application startup ordering.

Investigate filesystem warnings

A read-only or failed mount may indicate filesystem errors or hardware trouble. Stop dependent services and unmount before using the filesystem-specific repair tool. Never run a repair command against a mounted filesystem, and take a backup or image first when the disk may be failing.

Check hidden root-filesystem writes

If Docker or another service started while the drive was absent, it may have written into the bare mount-point directory. Stop the service before inspection. Those hidden files can fill the root filesystem and reappear when the external disk is unmounted.

Verification checklist

  • Linux detects the correct device and serial.
  • UUID and filesystem type match fstab.
  • The mount point exists.
  • findmnt verification and mount -a succeed.
  • Hardware and filesystem errors were reviewed.
  • Dependent services wait for storage.
  • Expected data is visible after a cold boot.
  • Backups exist before any repair.

This guide avoids destructive repair steps because the correct action depends on the filesystem and disk condition.

Next: Check Drive Health with SMART on Ubuntu. Return to Mount a Drive Automatically with fstab.

Official reference: Ubuntu fstab documentation.