You encounter a permission denied error when mounting an ext4 drive in Manjaro Linux because the mount point directory lacks the necessary ownership or permissions for your user account, or because the filesystem itself restricts access based on its internal metadata. This issue typically arises after creating a new partition or formatting a drive, where the default root-owned mount point prevents standard users from reading or writing data without elevated privileges or proper configuration adjustments.
Understanding the Root Cause
When you attempt to mount a block device such as
/dev/sdb1 to a directory like
/mnt/data, the Linux kernel checks two primary layers of security: the permissions of the target directory and the access controls defined within the ext4 filesystem itself. If the mount point is owned by
root with permissions set to
700 or
755, a regular user will receive a "permission denied" error when trying to access files inside that mounted volume. Additionally, ext4 partitions created without specific mount options may default to restricting write access to the superuser (root) only, especially if the filesystem was formatted recently and no user mapping has been established.
This scenario is distinct from issues related to partition UUID changes or LVM volume management, which require different diagnostic approaches as detailed in our guide on
Failed Mount API: Filesystems with Updated Partition UUIDs in Linux. In those cases, the system fails to locate the device entirely rather than denying access after a successful mount. Here, the mount succeeds, but the user cannot interact with the contents.
Verifying Current Permissions and Ownership
Before making any changes, it is crucial to inspect the current state of both the mount point and the mounted filesystem. Open a terminal and use the
ls -ld command on your mount directory to check who owns it and what permissions are assigned. For example, running
ls -ld /mnt/mydata might reveal output like
drwxr-xr-x 2 root root ..., indicating that only the root user has write capabilities.
Next, verify the actual mount status using the
mount | grep sdb1 command (replacing
sdb1 with your specific device identifier). Look at the options listed; if you see
rw, the filesystem is mounted read-write, but user-level restrictions still apply. If the output shows
ro, the filesystem is mounted read-only, which also causes access errors. You can also check the internal ownership of files within the mounted drive by navigating to the directory and running
ls -l. If all files show
root as the owner, this confirms that the filesystem metadata is enforcing root-only access.
Solving Directory Permission Issues
The most common fix involves changing the ownership of the mount point directory to your user account. This does not alter the files on the disk but allows your user to create, modify, or delete files within that directory structure. Use the
chown command with the recursive flag to ensure all existing content inherits the new ownership. The syntax is
sudo chown -R $USER:$USER /path/to/mountpoint. Replace
$USER with your actual username or leave it as is if you are already logged in as the target user.
For instance, if your username is
john and your mount point is
/mnt/ext4drive, you would execute:
sudo chown -R john:john /mnt/ext4drive
After executing this command, try accessing the directory again. If you still face issues, you may need to adjust the permissions using
chmod. A common setting for personal data drives is
755 (owner read/write/execute, others read/execute) or
775 (group writable). Apply this with
sudo chmod -R 755 /mnt/ext4drive. This step ensures that the directory structure itself permits traversal and modification by non-root users.
Configuring Mount Options for User Access
If changing directory ownership does not resolve the issue, the problem likely lies in how the filesystem is being mounted via
/etc/fstab or the
mount command line. Ext4 supports specific mount options that map the drive's root ownership to a specific user ID (UID) and group ID (GID). This method is often more robust than manually changing ownership because it persists across reboots and handles dynamic file creation correctly.
Edit your
/etc/fstab file using a text editor like
nano or
vim with sudo privileges. Locate the line corresponding to your ext4 partition. Add the
uid and
gid options to the mount options column. First, find your UID and GID by running
id in the terminal. Then, update the fstab entry to look something like this:
/dev/sdb1 /mnt/ext4drive ext4 defaults,uid=1000,gid=1000 0 2
Replace
1000 with your actual UID and GID numbers. After saving the file, remount the drive using
sudo mount -a. This forces the system to re-read the fstab configuration and apply the new user mapping. Any new files created on this drive will automatically be owned by your user, eliminating future permission conflicts.
Alternative Approaches and Safety Checks
In some cases, particularly if the drive was previously used in another Linux distribution or Windows environment, there might be residual ACLs (Access Control Lists) or extended attributes causing conflicts. You can clear these by remounting the drive with the
nouser_xattr option, though this is rarely necessary for standard ext4 setups. Another consideration is whether the drive is being auto-mounted by desktop environments like KDE Plasma or GNOME. These tools sometimes override manual fstab entries or apply their own restrictive policies. Disabling auto-mounting for that specific device in your system settings can help isolate whether the desktop environment is interfering with your manual mount commands.
For users who frequently switch between partitions, understanding how to properly set up these permissions is essential. Properly configuring your storage devices early on prevents many common headaches. If you are setting up a new drive from scratch, refer to our comprehensive guide on
How to Partition Disk for Manjaro: A Step-by-Step Guide to ensure your initial setup includes appropriate user mappings.
Frequently Asked Questions
Why do I get permission denied even after using sudo?
Using
sudo grants you root privileges for the command execution, but it does not change the ownership of the files you create unless you explicitly specify the user. If you run
sudo mkdir /mnt/test, the directory remains owned by root. Always ensure the mount point itself is accessible to your user before attempting to write data.
Can I mount an ext4 drive on Manjaro and read it from Windows?
No, native Windows systems cannot read ext4 filesystems without third-party drivers. While you can access files in a Manjaro partition from Windows using specialized software, this requires different tools than standard mounting. For cross-platform compatibility, consider using exFAT or NTFS instead of ext4. See our article on
Access Files in Manjaro Partition from Windows Partition for more details.
What happens if I format a drive without specifying a user?
If you format a drive using standard tools like
mkfs.ext4 without additional parameters, the root directory of that filesystem will be owned by root (UID 0). This means any regular user attempting to mount and write to it will face permission errors until ownership is changed or mount options are adjusted.
Is it safe to change permissions on a mounted drive?
Yes, changing permissions on a mounted ext4 drive is safe as long as you have the correct ownership rights. However, be cautious when using
chmod recursively on system directories or shared network drives, as this can inadvertently grant excessive access to other users or services. Always verify the path before applying recursive changes.
How do I find my UID and GID on Manjaro?
You can find your User ID (UID) and Group ID (GID) by typing
id into the terminal. The output will list your username followed by groups and IDs in parentheses. Look for
uid=XXXX(YourName) and
gid=YYYY(Group) to extract the numeric values needed for fstab configuration.