You plugged in a drive and Fedora sees nothing
You just installed a new NVMe SSD or connected a USB drive to expand your storage. You open the Files app and see nothing. You run lsblk in the terminal and see a raw device like /dev/nvme1n1 or /dev/sdb with no mount point listed. The drive is physically present, but the system isn't using it yet. You need to format the drive with a filesystem, create a directory to attach it, and configure the system to mount it automatically on boot.
What is actually happening
Linux treats storage as a stack of abstractions. The kernel detects the hardware and exposes it as a block device, usually named /dev/sdX for SATA/USB drives or /dev/nvmeXnY for NVMe drives. This block device is just raw sectors. It has no structure. You cannot store files on raw sectors.
You need a filesystem to organize data into files and directories. Tools like mkfs write that structure onto the block device. Once the filesystem exists, you need a mount point, which is a directory in the existing tree where the new filesystem becomes accessible. Mounting attaches the filesystem to that directory. Without a mount point, the filesystem is invisible to user space. Without an entry in /etc/fstab, the mount disappears after a reboot.
Mounting is just a pointer. The data lives on the disk, but the directory is the door.
Identify the drive
Check the block device list to find the unmounted drive and verify its size.
lsblk -f
# -f adds filesystem type and label columns so you can spot unformatted drives
# Look for a device with no MOUNTPOINT and no FSTYPE
# The SIZE column helps you confirm you found the right hardware
The output shows a tree structure. The root device is the disk, and indented entries are partitions. If you see /dev/sdb with no partitions, you can format the whole disk. If you see /dev/sdb1, that is a partition. Formatting /dev/sdb1 affects only that partition. Formatting /dev/sdb erases the entire disk including all partitions.
lsblk is safer than fdisk -l for quick checks because it does not require root privileges and displays the hierarchy clearly. If the drive does not appear, check the physical connection or run sudo dmesg | tail to see if the kernel detected the hardware.
Format the drive
Format the target device or partition with a filesystem. This operation erases all existing data on the target.
sudo mkfs.ext4 /dev/sdX1
# ext4 is the standard Fedora filesystem for general storage
# This command writes filesystem metadata and erases existing data
# Replace /dev/sdX1 with your actual device path from lsblk
ext4 is the default choice for most workloads. It is robust, widely supported, and handles journaling efficiently. Use xfs if you need to store files larger than 16TB or require high throughput for parallel writes. Use btrfs if you want built-in snapshots and compression, but note that btrfs requires additional tools for management.
If you are formatting the whole disk instead of a partition, use the disk path like /dev/sdb. The command is the same. The risk is higher because you destroy the partition table along with the data.
Create the mount point and mount
Create a directory to serve as the mount point and attach the filesystem.
sudo mkdir -p /mnt/newdrive
# -p ensures the directory is created without error if it already exists
# Choose a semantic name like /data or /storage for permanent drives
sudo mount /dev/sdX1 /mnt/newdrive
# This attaches the filesystem to the directory tree
# Files written here now live on the new drive
Mount points in /mnt are traditional for temporary or manual mounts. For permanent storage, many users prefer /data or a subdirectory in their home folder. The location does not matter to the kernel, only to your workflow.
By default, the mount point is owned by root. If you mount the drive, you might find you cannot write files as your user. Adjust ownership immediately so your account can use the drive.
sudo chown $USER:$USER /mnt/newdrive
# Changes the owner of the mount point directory to your current user
# This allows you to create files without sudo
# Run this after every mount if the filesystem does not store ownership
For ext4 and xfs, ownership is stored in the filesystem metadata. Changing the mount point ownership once is sufficient. For ntfs or vfat, you may need mount options like uid and gid to set ownership persistently.
Check ownership immediately. A root-owned drive is useless for daily work.
Persist the mount with fstab
Add an entry to /etc/fstab so the drive mounts automatically on boot. Never rely on manual mounts for permanent storage.
First, get the UUID of the filesystem. Device names like /dev/sdb1 can change between reboots if you plug drives in and out. UUIDs are stable identifiers burned into the filesystem metadata.
sudo blkid /dev/sdX1
# Returns the UUID and filesystem type
# Copy the UUID string for the fstab entry
# The output looks like UUID="12345678-1234-1234-1234-123456789abc"
Edit /etc/fstab to add the mount entry. This file lives in /etc, which is the correct location for user configuration. Never edit files in /usr/lib/. Those ship with packages and get overwritten on updates.
# /etc/fstab entry example
UUID=12345678-1234-1234-1234-123456789abc /mnt/newdrive ext4 defaults 0 2
# UUID prevents mount failures if device names shift
# defaults gives rw, suid, dev, exec, auto, nouser, async
# 0 2 means no dump, fsck order 2 (check after root filesystem)
The columns in fstab are: device, mount point, filesystem type, options, dump flag, and fsck order. The defaults option is usually sufficient. Add nofail to the options if the drive is removable or external. This tells systemd not to panic if the drive is missing at boot.
Add the line to /etc/fstab using your preferred editor. A typo here can prevent the system from booting. Verify the syntax before saving.
Run sudo mount -a before you reboot. A syntax error in fstab can drop you to an emergency shell.
Verify the mount
Confirm the filesystem is mounted and the fstab entry is valid.
df -h /mnt/newdrive
# Shows usage and mount point
# Verify the size matches your drive capacity
sudo mount -a
# Tests all fstab entries without rebooting
# If this returns silently, your fstab syntax is correct
If df shows the wrong size, the mount failed or attached to the wrong device. If mount -a prints an error, fix the fstab entry before proceeding.
Trust the output of df. If the size is wrong, the mount failed or hit the wrong device.
Common pitfalls and errors
If the drive does not appear after reboot, check the journal. Systemd logs mount failures with specific details.
[FAILED] Failed to mount /mnt/newdrive.
See 'systemctl status mnt-newdrive.mount' for details.
Run journalctl -xeu mnt-newdrive.mount to see the full context. The log will tell you if the UUID is missing, the filesystem is corrupted, or the device is not found.
If you see mount: /dev/sdX1: not a block device, you likely typed the device path wrong or the kernel has not detected the drive yet. Check lsblk again.
If sudo mount -a prints mount: /etc/fstab: parse error, you have a typo in the fstab file. Open it and check for spaces, missing columns, or invalid characters.
If the drive mounts but you cannot write files, check permissions. The mount point might be owned by root, or the filesystem might have restrictive permissions. Run ls -ld /mnt/newdrive to inspect ownership.
Read the journal before guessing. journalctl -xe shows exactly why systemd refused to mount.
When to use this approach
Use ext4 when you need broad compatibility and reliable journaling for general storage. Use xfs when you are storing large files or need high throughput for parallel writes. Use btrfs when you want built-in snapshots and compression, and you are comfortable with a more complex toolchain. Use ntfs-3g or exfat when the drive must be shared with Windows or macOS systems. Use fstab with UUIDs when the drive is internal or permanently attached. Use fstab with the nofail option when the drive is removable or external. Use udisksctl when you want a command-line interface that mimics the desktop automount behavior.
Match the filesystem to the workload. Wrong choices cause performance pain later.