← All writing
notes

Mount a Disk on AWS

A quick reference for mounting a new, empty EBS volume on an Ubuntu EC2 instance at /mnt/data.

Attach the volume to the instance from the AWS console or API first. The EBS volume and instance must be in the same Availability Zone. These commands assume the attached disk is /dev/nvme1n1 and the login user is ubuntu; check both before proceeding.

Partitioning and formatting can destroy existing data. Do not run these steps on the root disk or a volume containing data you want to keep. For an existing filesystem, skip partitioning and formatting, identify its UUID and mount it instead. Take an EBS snapshot before modifying a volume with valuable data.

1. Identify the disk

Terminal window
lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS,MODEL,SERIAL

Check the size, existing filesystems and mount points. On Nitro-based EC2 instances, EBS volumes appear as NVMe devices, so the device name can differ from the name supplied when attaching the volume. Use the EBS volume ID in the NVMe serial number to confirm which disk you are working on; do not assume nvme1n1 is always the data disk.

The root filesystem is mounted at /, possibly through another block-device layer. Leave its backing disk alone. If the intended disk already has partitions or a filesystem, stop and inspect it before changing anything.

2. Create a partition

Terminal window
sudo gdisk /dev/nvme1n1

gdisk edits the disk’s GPT partition table. For a new, empty disk:

  • Enter n to create a partition.
  • Accept the default partition number, first sector and last sector to create partition 1 using the available space.
  • Accept the default 8300 type code for a Linux filesystem.
  • Enter p to review the proposed partition table.
  • Enter w and confirm only after checking that you selected the correct disk.

Changes are written when you confirm w. The resulting partition should appear as /dev/nvme1n1p1:

Terminal window
lsblk /dev/nvme1n1

The disk is /dev/nvme1n1; p1 identifies its first partition. A filesystem can also live directly on an entire EBS device, but this note uses a partitioned layout.

3. Create an ext4 filesystem

Terminal window
sudo mkfs.ext4 /dev/nvme1n1p1

A partition defines a region of the disk; a filesystem gives that region the structures needed to store files and directories. mkfs.ext4 creates those structures and assigns a filesystem UUID.

Run this only on the new, empty partition. Formatting is not a mounting command and must not be repeated each time you attach or reboot the instance.

4. Configure a persistent mount

Read the UUID after formatting:

Terminal window
lsblk -f /dev/nvme1n1
sudo blkid /dev/nvme1n1p1

Use the filesystem UUID of /dev/nvme1n1p1, not the EBS volume ID or PARTUUID. A UUID lets Linux find the filesystem even if its NVMe device name changes.

Back up the mount configuration, then edit it:

Terminal window
sudo cp /etc/fstab /etc/fstab.backup
sudo vim /etc/fstab

Add this line, replacing <filesystem-uuid> with the actual UUID, without angle brackets:

UUID=<filesystem-uuid> /mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

/etc/fstab describes filesystems to mount at boot. The fields mean:

  • UUID=...: the filesystem to mount.
  • /mnt/data: the directory where its contents will appear.
  • ext4: the filesystem type created in the previous step.
  • defaults: the usual mount options, including read-write access and automatic mounting.
  • nofail: allow boot to continue if this optional data volume cannot be mounted.
  • x-systemd.device-timeout=10s: limit how long systemd waits for the device to appear to 10 seconds. This is not a timeout for the entire mount operation.
  • 0: disable the legacy dump backup flag for this filesystem.
  • 2: enable boot-time filesystem checks after the root filesystem, which normally uses 1.

nofail is useful for an optional disk, but it is not a guarantee that applications can safely run without it. A service writing to /mnt/data while the volume is absent could write to the root disk instead. Services that require this volume should have an explicit mount dependency, such as RequiresMountsFor=/mnt/data in their systemd unit.

5. Create the mount point and mount the disk

Terminal window
sudo mkdir -p /mnt/data
sudo systemctl daemon-reload
sudo mount -a
findmnt --mountpoint /mnt/data

mkdir -p creates the directory where the filesystem will be attached. Keep it empty: mounting over existing files hides them until the volume is unmounted, rather than moving them onto the volume.

systemctl daemon-reload tells systemd to reload its configuration and rerun its generators, including the one that turns fstab entries into mount units. It does not mount the filesystem by itself.

mount -a attempts to mount the eligible entries in /etc/fstab, including the new one. It also processes other entries, so investigate any reported errors before rebooting.

findmnt --mountpoint /mnt/data verifies that this exact directory is a mount point. Confirm that its source is the expected partition and its filesystem type is ext4. If the mount failed, fix the UUID, mount options or device availability before proceeding.

6. Give the Ubuntu user ownership

Only after confirming that the disk is mounted:

Terminal window
sudo chown -R ubuntu:ubuntu /mnt/data/

A freshly created ext4 filesystem is owned by root. This command changes ownership of the mounted directory and everything beneath it to the ubuntu user and group, allowing that user to write without sudo.

For a new disk, this is convenient. On a populated disk, -R can be slow and overwrite ownership required by other users or services. If only the top-level directory needs to change, use sudo chown ubuntu:ubuntu /mnt/data instead. Use the application’s actual user and group for a service-owned volume.

Finally, check the mounted filesystem’s capacity:

Terminal window
df -h /mnt/data

The volume is now mounted and configured to mount again at boot. After a planned reboot, verify it again with findmnt --mountpoint /mnt/data before relying on it.