LiveChat 
Support 
How to Change Permissions on an External Hard Drive in Ubuntu (Why chmod Often Fails)
You plug an external drive into Ubuntu, try to copy a file, and get Permission denied. You run `chmod` to fix it, and nothing changes. The same command works perfectly on your home directory, so why does it silently fail on the USB drive?
The answer is the single nuance that most tutorials skip: changing permissions on an external drive depends entirely on the drive’s filesystem. Linux-native filesystems like ext4 store Unix permissions, so `chmod` and `chown` behave exactly as you expect. But NTFS, exFAT, and FAT32 — the formats most external and USB drives ship with for Windows compatibility — do not store Unix permissions at all. On those drives, `chmod` is effectively a no-op, and access is controlled through mount options instead.
This guide shows you how to identify your filesystem first, then apply the correct method for each type.
Key Takeaways
• Check the filesystem before anything else with `lsblk -f` or `df -T`. The fix depends on it.
• ext4 external drives use real Unix permissions — `chown` and `chmod` work normally.
• NTFS, exFAT, and FAT drives do not store Unix permissions. `chmod` appears to do nothing; you control access with mount options (`uid=`, `gid=`, `umask`, `dmask`, `fmask`).
• “Permission denied” on a mounted drive usually means it is mounted read-only or owned by root — not that you set the wrong `chmod` bits.
• Set access persistently in `/etc/fstab`, or reformat to ext4 if the drive is Linux-only.
Why does chmod do nothing on my external drive?
If `chmod 777 /media/user/MyDrive/file` runs without error but the permissions never change, the drive is almost certainly formatted as NTFS, exFAT, or FAT32. These filesystems were not designed around the Unix permission model. They have no concept of an owner UID, a group GID, or rwx bits stored per file.
When Linux mounts one of these filesystems, the kernel synthesizes permissions on the fly using a driver. Every file is presented with the *same* ownership and the *same* permission bits, derived from the options used at mount time. Because those bits are generated rather than stored, `chmod` has nothing to write to — the change is discarded.
This is why the real lever is the mount, not the file. To change access, you change *how the drive is mounted*, not the individual files on it.
The insight most guides miss: When `chmod` “doesn’t work” on an external drive, it is not a bug and not a corrupted permission. It is the filesystem telling you it cannot store Unix permissions. Before you try `chmod` even once, run `lsblk -f`. If the drive type is `ntfs`, `exfat`, `vfat`, or `fat32`, stop using `chmod` entirely and reach for mount options (`uid`, `gid`, `umask`). If the type is `ext4`, then and only then is `chmod`/`chown` the correct tool.
How do I check which filesystem my drive uses?
Run either of these before touching permissions:
“`bash lsblk -f “`
“`bash df -T “`
`lsblk -f` lists every block device with its FSTYPE, label, and mount point:
“`text NAME FSTYPE LABEL MOUNTPOINT sdb └─sdb1 exfat MyDrive /media/user/MyDrive “`
Here the partition `sdb1` is exfat, so `chmod` will not work — you need mount options. If you instead see `ext4`, standard ownership commands apply.
Filesystem behavior at a glance
| Filesystem | Stores Unix permissions? | How to control access |
|---|---|---|
| ext4 (also ext3, ext2, Btrfs, XFS) | Yes | `chown` and `chmod` work normally |
| NTFS | No (synthesized at mount) | Mount options: `uid`, `gid`, `umask`/`dmask`/`fmask` |
| exFAT | No | Mount options: `uid`, `gid`, `umask`/`dmask`/`fmask` |
| FAT32 / vfat | No | Mount options: `uid`, `gid`, `umask`/`dmask`/`fmask` |
The rule is simple: one Linux-native filesystem (ext4) uses permissions; the Windows-friendly ones do not.
How do I change permissions on an ext4 external drive?
If `lsblk -f` reports ext4, the drive behaves like any internal Linux disk. The most common problem is that files are owned by `root` (because the drive was mounted or written to as root), so your user cannot modify them.
Take ownership of the drive by pointing `chown` at the mount point and recursing:
“`bash sudo chown -R $USER:$USER /media/user/MyDrive “`
`$USER` expands to your username, and `-R` applies the change to every file and folder. Then set the permission bits you want:
“`bash
sudo chmod -R u+rwX,go+rX /media/user/MyDrive “`
The capital `X` is deliberate: it adds the execute bit to directories (so you can enter them) without marking every regular file as executable. For a deeper walkthrough of the bit patterns, octal notation, and recursive flags, see our general guide.
After this, `chmod` and `chown` work permanently on that drive because ext4 stores the result on disk.
How do I control access on an NTFS, exFAT, or FAT drive?
On these filesystems you set ownership and permissions at mount time using options. The key options are:
- `uid=` — the numeric user ID that owns every file on the drive.
- `gid=` — the numeric group ID for every file.
- `umask=` — permission bits to *remove* from files and directories (e.g. `022` gives `755`, `077` gives `700`).
- `dmask=` / `fmask=` — apply separate masks to directories and files respectively.
Find your numeric UID and GID with:
“`bash id
“`
Mounting manually with the right options
Unmount the drive first if it auto-mounted, then mount it yourself. For an exFAT or NTFS partition `/dev/sdb1`:
“`bash sudo umount /dev/sdb1 sudo mkdir -p /mnt/mydrive sudo mount -o uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/mydrive “`
Now every file is owned by UID 1000 and readable/writable by that user (`755`). Use `umask=077` if you want the drive private to your user only (`700`).
For NTFS specifically, Ubuntu uses the `ntfs3` (or `ntfs-3g`) driver, which accepts the same options:
“`bash sudo mount -t ntfs3 -o uid=1000,gid=1000,umask=022 /dev/sdb1 /mnt/mydrive “`
Remember: these settings apply to the whole filesystem. You cannot give one file `644` and another `600` on NTFS/exFAT/FAT — they all share the masks you set at mount.
How do I make the permissions stick after a reboot?
Manual mounts disappear on reboot. To make access persistent, add an entry to `/etc/fstab`.
First get the partition’s UUID:
“`bash sudo blkid /dev/sdb1
“`
Then edit the file:
“`bash sudo nano /etc/fstab “`
Add a line for the drive. For an exFAT drive:
“`text UUID=1234-ABCD /mnt/mydrive exfat defaults,uid=1000,gid=1000,umask=022 0 0 “`
For an ext4 external drive (no uid/umask needed — it stores permissions itself):
“`text UUID=abcd-… /mnt/mydrive ext4 defaults,nofail 0 2 “`
The `nofail` option is important for removable drives: it prevents the boot from hanging if the drive is unplugged. Test the entry without rebooting:
“`bash sudo mount -a “`
If `mount -a` returns no errors, the configuration is valid. For the broader topic of editing `fstab` safely and what each column means, see our mounting guide.
Why do I still get “Permission denied” after mounting?
If access is still blocked, the cause is usually one of two things, and neither is solved by `chmod`:
- The drive is mounted read-only. This is common with NTFS drives that were not cleanly ejected from Windows (a “dirty” or hibernated volume) or any drive with hardware write-protection. Check with `mount | grep mydrive` — if you see `ro`, it is read-only. For NTFS, fully shut down Windows (not Fast Startup / hibernate) so the volume is clean, then remount.
- The mount is owned by root. If you mounted without `uid=`, every file is owned by root and your user cannot write. Remount with `uid=$(id -u),gid=$(id -g)` for NTFS/exFAT/FAT, or `chown` the mount point for ext4.
A quick diagnostic:
“`bash mount | grep mydrive ls -ld /mnt/mydrive “`
If `ls -ld` shows the directory owned by `root` and the filesystem is not ext4, the answer is mount options — not file commands.
Need storage where permissions behave predictably?
The filesystem headaches above come from cross-platform external drives. On a server, you control the environment end to end. DarazHost VPS and dedicated servers run on Linux-native filesystems where standard ownership and permission commands — `chown`, `chmod`, octal modes, recursive flags — work exactly as documented, with no synthesized-permission surprises. You also get reliable SSD storage, full root access for complete control over mounts and permissions, and 24/7 technical support if you ever need a hand configuring `fstab` or partitions. When your storage is Linux-native, permissions just work.
When should I reformat the drive to ext4?
If the external drive is used only on Linux and you are tired of mount-option gymnastics, reformatting to ext4 gives you real, per-file Unix permissions. This is the cleanest long-term fix.
Warning: reformatting erases all data. Back up first.
“`bash
sudo umount /dev/sdb1 sudo mkfs.ext4 -L MyDrive /dev/sdb1 sudo chown -R $USER:$USER /mnt/mydrive “`
After this, `chmod` and `chown` work normally and persist on disk. Keep the drive on NTFS or exFAT only if you still need to read it on Windows or macOS.
Frequently asked questions
Why does chmod 777 not work on my USB drive? Because the drive is almost certainly NTFS, exFAT, or FAT32, which do not store Unix permissions. The command runs but has nothing to save. Check with `lsblk -f`; if the type is not ext4, control access with mount options (`uid`, `gid`, `umask`) instead of `chmod`.
How do I find my user’s UID and GID for the mount options? Run `id` in a terminal. The output shows `uid=1000(user) gid=1000(user)`. Use those numbers as `uid=` and `gid=` in your `mount` command or `/etc/fstab` entry. On a single-user desktop the values are usually `1000`.
What is the difference between umask, dmask, and fmask? `umask` removes permission bits from both files and directories. `dmask` applies only to directories and `fmask` only to files, letting you, for example, make directories `755` (`dmask=022`) while keeping files `644` (`fmask=133`). Use `umask` when one value is fine for both.
My NTFS drive is read-only in Ubuntu — how do I fix it? This usually happens when Windows left the volume in a hibernated or “dirty” state via Fast Startup. Fully shut down Windows (Shift + Restart, or disable Fast Startup), then remount in Ubuntu. The modern `ntfs3` driver mounts read-write once the volume is clean.
Can I set different permissions for individual files on an exFAT drive? No. NTFS, exFAT, and FAT apply one set of masks to the entire mounted filesystem, so all files share the same effective permissions. For true per-file permissions on an external drive, reformat it to ext4.
Conclusion
Changing permissions on an external hard drive in Ubuntu comes down to one decision made *before* you type any command: check the filesystem with `lsblk -f`. If it is ext4, use `chown` and `chmod` exactly as you would on any internal disk. If it is NTFS, exFAT, or FAT32, forget `chmod` — control access through mount options (`uid`, `gid`, `umask`) applied manually or made persistent in `/etc/fstab`. When `chmod` seems broken, the filesystem is the explanation, not the command.
