Quick answer

What this guide helps you do

Identify an existing filesystem by UUID, add a safe fstab entry, test it without rebooting and recover from common boot and mount failures.

Safety boundary

This guide mounts an existing filesystem. It does not format, partition or erase a disk. Confirm the device, filesystem and data before editing anything.

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

Do not identify a permanent mount only by /dev/sdX because that name can change across boots.

Choose a stable mount point

For server data, a path under /srv is usually clearer than a desktop-style removable-media path.

sudo mkdir -p /srv/data
sudo stat /srv/data

If the directory contains files, mounting over it will hide them until unmounted. Inspect it first.

Back up and edit fstab

sudo cp /etc/fstab /etc/fstab.backup-$(date +%F-%H%M%S)
sudo nano /etc/fstab

Example for an existing ext4 filesystem:

UUID=YOUR-REAL-UUID  /srv/data  ext4  defaults,nofail  0  2

Use the real UUID and filesystem type reported by lsblk or blkid. The nofail option lets boot continue if this non-essential disk is absent; decide whether that behaviour is right for the service.

Test before reboot

sudo findmnt --verify
sudo mount -a
findmnt /srv/data
df -hT /srv/data
sudo dmesg --level=err,warn | tail -n 50

Do not reboot while these commands report an error. Check that expected files are visible and permissions match the applications that need them.

Understand permission ownership

Mounting and file permissions are separate. Native Linux filesystems store numeric ownership and modes. FAT or NTFS may use mount options to present ownership. Do not add random uid, gid or umask options to ext4 expecting them to override stored ownership.

Recover safely

If the server drops to emergency mode, use local or provider console access, mount the root filesystem read-write if required, comment out the faulty non-essential fstab entry, and reboot. The usual causes are a copied UUID, wrong filesystem type, missing mount point or invalid option.

Verification checklist

  • Device identity and existing data were confirmed.
  • UUID and filesystem type are correct.
  • Mount point was empty or understood.
  • fstab was backed up.
  • findmnt verification and mount -a succeed.
  • Expected files and permissions are visible.
  • A controlled reboot succeeds.
  • Dependent Docker or media services see the correct filesystem.

This is mounting guidance, not a claim that SmallGrid has tested every filesystem and enclosure.

Next: Fix Permission Denied on Ubuntu Server. Return to the Docker cluster: How to Install Docker on Ubuntu Server.

Official reference: Ubuntu fstab documentation.