External hard drive permissions reset because the operating system applies default mount options on every connection, ignoring previous manual changes. To preserve specific user or group ownership and access rights across reboots and disconnects, you must configure persistent mount rules. This guide explains how to use
fstab entries or udev rules to enforce these settings automatically.
Understanding Why Permissions Reset
When you connect an external storage device, the Linux kernel detects it as a new block device. By default, the system mounts this device using generic parameters defined in
/etc/fstab or via automount services like
udisks2. These default configurations typically assign ownership to the user who initiated the mount or use a generic UID/GID if no specific mapping exists. Consequently, any manual adjustments made via
chown or
chmod are overwritten the next time the drive is plugged in. This behavior is intentional for security and consistency but becomes problematic when you need consistent access control for shared drives or specific application requirements.
Method 1: Persistent Mount Options in fstab
The most reliable method for ensuring permissions stay intact is to define them directly in the
/etc/fstab file. This approach tells the system exactly how to mount the drive every time it is detected by its unique identifier. First, identify your external drive's UUID. Open a terminal and run
lsblk -o NAME,UUID,MOUNTPOINT or
blkid to find the long alphanumeric string associated with your external HDD. Do not use the
/dev/sdX path, as this can change between boots depending on which port you use.
Next, edit the
/etc/fstab file with root privileges using a text editor like
nano or
vim. Add a new line that specifies the UUID, the mount point, the filesystem type (e.g.,
ext4,
ntfs-3g, or
vfat), and crucially, the
uid,
gid, and
umask options. For example:
UUID=your-uuid-here /mnt/external ext4 defaults,uid=1000,gid=1000,umask=007 0 0
In this example,
uid=1000 and
gid=1000 correspond to your primary user account. The
umask=007 setting ensures that files are created with read/write access for the owner and read-only for the group, while denying access to others. After saving the file, test the configuration by running
sudo mount -a. If there are no errors, your permissions will now be enforced automatically upon every connection.
Method 2: Using udev Rules for Dynamic Control
If you prefer not to modify
/etc/fstab globally, or if you need more granular control over when permissions apply, udev rules offer a powerful alternative. Udev manages device events in real-time, allowing you to trigger scripts or commands immediately after a device is connected. Create a new rule file in
/etc/udev/rules.d/, such as
99-external-drive-permissions.rules. You must identify the vendor ID and product ID of your specific drive, which can be found using
lsusb.
A typical rule might look like this:
SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", RUN+="/usr/local/bin/set-drive-perms.sh"
This rule triggers a custom script whenever a drive matching those IDs is connected. The script
/usr/local/bin/set-drive-perms.sh would then execute commands like
chown and
chmod on the newly mounted partition. This method is particularly useful for NTFS or exFAT drives where native Linux permission bits do not exist, and you rely entirely on mount options or post-mount scripts to simulate access control. Note that you may need to reload udev rules with
sudo udevadm control --reload-rules after making changes.
Verifying Your Configuration
Once you have implemented either method, it is critical to verify that the settings persist correctly. Disconnect the external drive completely and wait for the system to unregister it. Reconnect it and check the ownership and permissions using
ls -l /mnt/external. The output should reflect the UID, GID, and mask you specified. If the permissions revert to default values, double-check your
fstab syntax for typos or ensure that your udev rule matches the correct hardware IDs. Additionally, ensure that no other desktop environment automounters are overriding your manual configurations by disabling automatic mounting in your system settings.
For users experiencing intermittent connectivity issues alongside permission problems, it may be worth investigating power management settings. See our guide on
Troubleshooting: External USB Hard Drive Disconnects When Unused to rule out physical instability causing mount failures. Similarly, if you suspect hardware faults are contributing to erratic behavior, check out Troubleshooting Faulty USB Ports: Tips and Methods to ensure your connection is stable before applying complex software fixes.
Frequently Asked Questions
Will changing fstab affect my internal drives?
No, because you are specifying the exact UUID of your external drive, only that specific device will be affected. Internal drives have different UUIDs and distinct entries in
/etc/fstab, so they remain untouched by changes made for external storage.
Can I use this method for NTFS drives?
Yes, but you must use the
ntfs-3g filesystem type in
/etc/fstab instead of
ntfs. The
uid,
gid, and
umask options work similarly to set ownership and access rights for Windows-compatible filesystems on Linux.
What if I forget my UID and GID?
You can find your current user's UID and GID by typing
id in the terminal. The output will display lines starting with
uid= and
gid=, providing the exact numbers you need to insert into your configuration files.
Does this work on macOS?
No, this solution is specific to Linux systems using
fstab and udev. macOS handles external drive permissions differently through Spotlight indexing and POSIX ACLs, requiring different tools like
chflags or third-party utilities for persistent permission management.
Why did my drive still mount with wrong permissions?
This usually happens if the drive was already mounted when you applied the changes, or if a desktop environment service like
udisks2 is overriding
fstab. Try unmounting the drive manually with
sudo umount /mnt/external and then remounting it to force the system to re-read the configuration.