Permission denied

Fix 'Permission Denied' on mount: the real cause isn't sudo

EP
Erropedia Team
📅 August 28, 2026 📅 Updated Sep 8, 2026 👁 19 views Linux & Unix Intermediate
Sudo won't fix a mount permission error. The cause is usually missing mount options or the wrong device. Here's the actual fix.

Yeah, that "Permission denied" on mount is annoying, especially when you're already root. You type sudo mount /dev/sdb1 /mnt/data and it still refuses. Here's what's actually happening: mount isn't checking your UID — it's checking the filesystem on the device.

The fix: add the right options

For most USB drives and external disks (vfat or ntfs), the kernel disallows mounting without explicit ownership options. The quick fix:

sudo mount -t vfat -o uid=1000,gid=1000 /dev/sdb1 /mnt/data
sudo mount -t ntfs-3g -o uid=1000,gid=1000 /dev/sdb1 /mnt/data

Replace 1000 with your actual user ID (run id -u). If the filesystem is ext4 or xfs, then the problem is elsewhere — see below.

The reason step 3 works: vfat and ntfs don't store Unix ownership metadata. They only know about files, not who owns them. Without uid/gid, the kernel defaults to root:root, and since root can't write to a root-owned directory that's mounted with default permissions (usually 755), you get permission denied on access — but mount itself might succeed. Wait, that's the other common failure: mount succeeds but you can't write inside. That's not what you're seeing if mount prints an error.

When the error is on the mount itself

If mount says "Permission denied" and exits, not just your shell, then the kernel refused the syscall. Causes, in order of likelihood:

  • The device is mounted somewhere else. Check mount | grep sdb1. If it's already mounted read-only or with different options, unmount first. You'll get "device is busy" or permission denied if the kernel thinks it's in use by another namespace.
  • The mount point is inside a restricted directory. On modern systemd distros, mounting under /tmp or /var/tmp with certain options fails with EPERM due to systemd's private tmp. Use /mnt or /media.
  • You're not actually root. sudo sometimes runs a restricted shell. Run sudo -i first to get a real root shell, then mount.
  • The device is a LUKS or has a partition table mismatch. sudo blkid /dev/sdb1 will show the actual filesystem type. If it says crypto_LUKS, you can't mount it directly — open it with cryptsetup first.

One real-world trigger I hit on Ubuntu 22.04: I had a USB drive with a corrupted partition table. The kernel saw the device as sdb but sdb1 didn't exist. Mount returned "Permission denied" instead of "No such device". Check lsblk -f /dev/sdb — if the partition doesn't show, recreate it.

Fixing it permanently in /etc/fstab

If you want the mount to survive reboots, edit /etc/fstab. The line for a vfat drive:

UUID=ABCD-1234  /mnt/usb  vfat  uid=1000,gid=1000,umask=022  0  0

Get the UUID from blkid. The umask=022 bit sets default permissions so files are readable by all, writable by owner. For ntfs-3g, you'd use windows_names too if you care about filenames.

Don't skip the nofail option on removable drives. If the drive isn't present at boot, systemd will hang waiting for it. nofail tells it to move on.

Less common variations

Mount namespace containment

If you're in a container, even as root, you can't mount unless you have CAP_SYS_ADMIN. Docker and Podman drop this by default. You'll need --privileged or the SYS_ADMIN capability. This is a different beast than the USB problem — you're not fighting filesystem permissions, you're fighting the kernel's capability system.

NFS and CIFS

Network mounts are picky about the vers option. NFSv4 with broken idmap can cause permission errors. Try mount -t nfs4 -o sec=sys. CIFS needs vers=3.0 on older servers. The kernel's default NFS version might be too new for the server, and the handshake fails with a generic EPERM. That's misleading — the server rejected the protocol version, not the user.

FUSE filesystems like sshfs

sshfs fails with permission denied when the remote user lacks access to the remote directory. Check the remote side first. Also, sshfs runs under your user, not root, so it can't mount to system directories unless you add allow_other in /etc/fuse.conf.

Prevention

Keep a template for your fstab entries. I have a comment block in /etc/fstab with the exact syntax for vfat, ntfs, and ext4. Whenever I plug a new drive, I copy the relevant line, change the UUID and mount point, and run mount -a to test before rebooting. That test catches typos without a scary boot hang.

Also, always check dmesg | tail right after a mount failure. The kernel logs the real reason, like "wrong fs type" or "bad option". That message is more honest than the generic "Permission denied" the mount command spits out. I've solved more than one mystery that way.

Finally, if you're on a distro with SELinux or AppArmor enabled, those can block mounts on certain paths. Check audit2why on Fedora or aa-status on Ubuntu to see if the security module is the culprit. Usually not, but when it is, no amount of sudo will help.

Related Errors in Linux & Unix
Terminal history not saving between sessions on Linux? Fix it now Permission Denied Fix 'Permission Denied' for sudo on Ubuntu 22.04 Fix Failed to Start Networking Service on Linux Resource temporarily unavailable Fix User Process Limit Exceeded (ulimit) on Linux
mount permission denied sudo mount fails mount error linux fstab mount denied ntfs mount permission vfat mount permission mount option uid gid mount not permitted linux mount point permission denied mount source permission denied

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.