How to Mount a USB Drive in Linux and Get Write Permission on It

A USB drive the kernel has already detected can still have no path to its files. The server offers no file manager and no /media folder.

Mounting is what joins a partition to a directory, and the kernel keeps that entry until you detach it. I attached a FAT32 volume as a loop device for the frames, so the device reads /dev/loop24p1 where yours reads /dev/sdb1.

How Linux sees a USB drive

The kernel does not hand you a folder when you plug the stick in. It hands you a block device, so the filesystem inside it stays unreadable until something attaches that device to a directory.

The mount point is the directory you choose, and a desktop session does the attaching for you through udisks2, which mounts removable volumes under /media and hands the files to the user who plugged the drive in.

A terminal session on a server runs no such helper, which is why lsblk can list the drive while nothing has a path to it.

The partition table is the place to look on a stick that came from another machine, because that is where the number of partitions and their sizes were decided. The layout rules are the same ones behind partitioning a disk on Linux.

lsblk
lsblk -o NAME,SIZE,TYPE,TRAN

The TRAN column names the bus the kernel attached the disk to, so the drive on the end of a USB cable is the row that says usb.

I ran the list before and after attaching the demo volume, and the new disk and partition rows were the only difference. On a machine with more than one disk, that comparison is what keeps you off the wrong device.

What you need before the first command

The mount succeeds once four things are true, and three of them are checks rather than commands.

• An account that can mount. The mount command needs root, and a plain user gets the message mount: /mnt/usb: must be superuser to use mount.
• A driver for the filesystem stored on the partition.
• An empty directory to use as the mount point.
• The device name of the partition rather than of the whole disk.

The driver half of that list is the one worth checking, because a kernel without a module for the partition’s filesystem cannot mount it with any option.

ls /lib/modules/$(uname -r)/kernel/fs | grep -E 'fat|ntfs'
# exfat
# fat
# ntfs3

The ntfs3 entry matters because current kernels mount NTFS partitions read and write through that in-tree driver, while the ntfs-3g package provides the user-space driver that older systems use instead. The NTFS side of that has its own walkthrough in mounting a Windows NTFS partition on Linux.

exFAT works the same way, so the kernel driver does the mounting and exfatprogs supplies the tools for checking and labelling the volume.

Which of those filesystems you are dealing with is a separate question from what the stick can hold. The trade-offs are covered in the Linux file system overview.

Mount the drive from the terminal

The whole job comes down to a sequence of commands, because each one answers a question the next depends on.

Find the device name

lsblk with no arguments lists every disk and partition the kernel knows about. Pass one device name and you get that disk with its partitions on their own, which is the form that keeps you off the wrong row.

The volume in the frame is a single 128 MB partition on /dev/loop24, and it has the same shape as a stick that appears as /dev/sdb.

lsblk
lsblk -p -o NAME,FSTYPE,LABEL /dev/sdb

Read the filesystem type and UUID

The filesystem type decides which driver mounts the partition, and the UUID is the value to keep for anything that has to survive a reboot. I ran blkid against the partition rather than the disk, because the disk itself carries no filesystem to report.

lsblk -f prints the type, label and UUID as columns, and blkid prints the same values on one line against the partition. The UUID identifies the filesystem rather than the device letter, so an entry built on it keeps working after the stick moves to another port.

lsblk -f
sudo blkid /dev/sdb1

Make the mount point

A mount point is an empty directory, and /mnt is where manual mounts traditionally live because the desktop keeps /media for itself.

sudo mkdir -p /mnt/usb && echo 'mount point ready: /mnt/usb' && ls -ld /mnt/usb

The -p flag makes mkdir safe to repeat, the echo prints a confirmation, and ls -ld shows the directory that mount will use. An occupied directory works as well, since the mount hides whatever was underneath until you unmount it, which is a good reason to keep this one clear.

Mount the partition

Mount the partition and never the disk, so /dev/sdb1 rather than /dev/sdb, because the filesystem lives in the partition while the disk itself holds the table. The bare form lets the kernel pick the driver from the filesystem signature, and success prints nothing at all.

A read-only mount costs one extra word, and it suits a drive of unknown origin, since nothing you do in that state can change what is on it.

sudo mount /dev/sdb1 /mnt/usb
sudo mount -t exfat /dev/sdb1 /mnt/usb     # when auto-detection picks the wrong driver
sudo mount -o ro /dev/sdb1 /mnt/usb       # first look at a drive you do not trust

I mounted the demo volume with the bare form first and the command returned with exit status 0 and no output, which is the whole success condition.

Confirm the mount

findmnt reads the kernel’s mount table and prints the entry for one directory, which is the shortest answer to whether the mount happened. df reports the same entry with the size and free space, and the same tool covers watching disk usage on a Linux machine.

findmnt /mnt/usb
df -h /mnt/usb

The options string in that output is where the mount tells you what it did, and a fresh FAT mount carries rw, relatime, fmask=0022, dmask=0022, codepage=437 and iocharset=iso8859-1. uid or gid appear there once you set them.

Make the drive writable for your account

A first mount of a FAT volume through sudo belongs to root, because the mount manual gives the default as the uid and gid of the process that runs the command. For sudo, that process is root.

The failure that follows is a write refused on a drive with plenty of free space.

chown cannot repair this. It fails with Operation not permitted on a file inside the volume and on the mount point itself, because a FAT directory entry has no owner field to change.

sudo chown $USER /mnt/usb
# chown: changing ownership of '/mnt/usb': Operation not permitted
sudo chown $USER /mnt/usb/notes.txt
# chown: changing ownership of '/mnt/usb/notes.txt': Operation not permitted

I tried both copies of that command against the demo volume and both came back with the same refusal. I remounted the same volume with uid and gid from my own shell and the same write went through.

Ownership comes from the mount options instead. The pair that matters is uid and gid, the numeric ids that sit behind account names in users and groups on Linux.

sudo umount /mnt/usb
sudo mount -o uid=$(id -u),gid=$(id -g) /dev/sdb1 /mnt/usb

The ids come from your own shell, so the volume reports your account as the owner as soon as it is mounted, and files you create land with the same ids.

ext4 is a different story, because each file carries its own owner. The chown command works there, the uid option is unnecessary, and a stick formatted for Linux behaves like any other directory on the system.

Keep the drive mounted across reboots

fstab is the boot-time list, and one line per filesystem is all it takes. The first field causes the trouble, because a device name can point at a different disk after a reinstall or a change of port.

UUID is the recommended identifier for that field, and the fstab manual gives the reason: device names follow the order hardware was detected, which can change when disks are added or removed.

sudo blkid /dev/sdb1
# /dev/sdb1: LABEL="USBSTICK" UUID="4DD2-903D" TYPE="vfat"

A FAT entry also wants the ownership ids spelled as numbers, because no shell expands the id command inside fstab.

UUID=4DD2-903D /mnt/usb vfat defaults,nofail,uid=1002,gid=1002 0 0

nofail keeps a missing drive from stopping the boot, while noauto leaves the line out of mount -a so the filesystem mounts only when you name it. A third option, x-systemd.automount, mounts the volume on first access rather than at boot, which suits a stick that is not always attached.

Test a candidate line before it lands in the boot file. Copy the current file, append the line to the copy, and mount from the copy, which points the command at an alternative fstab.

sudo cp /etc/fstab /tmp/test-fstab
printf 'UUID=4DD2-903D /mnt/usb vfat defaults,nofail,uid=1002,gid=1002 0 0\n' | sudo tee -a /tmp/test-fstab
sudo mount -T /tmp/test-fstab -a -v

I ran that sequence against a copy and the verbose output ended with /mnt/usb : successfully mounted, which is the line to look for. Drop nofail and a missing UUID becomes mount: /mnt/usb: can’t find UUID=1111-2222, which is the failure the option exists to prevent.

A wrong line in the boot file can stop a machine from starting. The test copy earns its place before the boot file itself changes.

When mount refuses

Every failure in this chain arrives as a message, and each one names the link between the device and the directory that refused.

The wrong fs type text comes from the kernel, after it read the partition and found no driver for what was stored on it. Asking for a type that the partition does not hold produces the same message.

The busy text comes from the unmount. A shell sitting inside the mount point, or an editor with a file open there, is enough to hold the filesystem.

A lazy unmount removes the entry from the mount table while the process still holds the filesystem, which clears the message without freeing the device. A forced unmount is for an unreachable network filesystem and does nothing for a local stick.

Unmount before you pull the drive

Writes to a FAT volume sit in the page cache until the kernel flushes them, so a stick pulled on the strength of a finished copy can lose the last of it. umount flushes the volume as it detaches it.

sync
sudo umount /mnt/usb

sync pushes the cache to the device first, so the detach starts with nothing pending, and an unmount that returns without an error leaves the filesystem consistent.

I ran that unmount from outside the directory on the demo volume and it came back with no output, which is the passing case. The drive can come out at that point, and the entry in the mount table goes with it.