Recovering Deleted Shared Link Permissions on NTFS

NTFS shared link permissions on Linux are restored by remounting the partition with explicit uid, gid, and fmask options, not by recovering deleted ACLs. The ntfs-3g driver maps Windows ownership to Linux users at mount time. This guide explains how to configure these parameters in /etc/fstab to resolve access issues.

Understanding NTFS Permission Mapping on Linux

When you connect an NTFS drive to a Linux system, the kernel does not natively understand Windows Access Control Lists (ACLs) in the same way it understands POSIX permissions. Instead, the ntfs-3g driver (or the newer ntfs3 driver in recent kernels) presents the entire filesystem as a single user or group. This is why you often see files owned by root or your current user regardless of their actual Windows permissions. The concept of "deleted shared link permissions" is a misnomer in this context. You are not recovering lost metadata from the disk. Rather, you are configuring how the Linux kernel translates the static NTFS structure into dynamic Linux permissions. If your links or files appear inaccessible, it is because the mount options do not grant your user account the necessary read or write capabilities. This behavior is distinct from standard ext4 or btrfs partitions. On those systems, permissions are stored in the inode. On NTFS, they are virtualized at the point of entry. Therefore, fixing the issue requires adjusting the mount configuration rather than running data recovery tools. For more context on managing dual-boot environments where such drives are common, you might find our guide on Double Booting Windows 11 and Ubuntu 20.04 LTS on a New HDD helpful for understanding cross-platform storage challenges.

Identifying the Current Mount Configuration

Before making changes, you must identify how the drive is currently mounted. Open a terminal and use the mount command filtered for ntfs:

mount | grep ntfs

You will likely see output similar to this:

/dev/sdb1 on /media/user/Data type ntfs-3g (rw,nosuid,nodev,allow_other,default_permissions,uid=1000,gid=1000)

Pay close attention to the uid and gid values. These numbers represent the User ID and Group ID of the user who should own all files on that partition. If these IDs do not match your local user account, you will encounter permission denied errors when trying to create or modify files. To find your current user's ID, run:

id -u
id -g

Compare these outputs with the uid and gid in your mount line. If they differ, this is the root cause of your access issues. Additionally, check the fmask and dmask values if present. These masks determine the default permissions for files and directories respectively. A mask of 0077 means only the owner has access, while 0002 allows group write access.

Editing fstab for Permanent Permissions

The most robust solution is to edit the /etc/fstab file. This ensures that your permissions settings persist across reboots and are applied consistently every time the drive is connected. First, back up your current fstab:

sudo cp /etc/fstab /etc/fstab.bak

Then, open the file for editing:

sudo nano /etc/fstab

Locate the line corresponding to your NTFS partition. It will look something like this:

/dev/disk/by-uuid/XXXX-XXXX  /media/data  ntfs-3g  defaults  0  0

Replace defaults with specific options that define your desired ownership and permissions. Here is a template for a typical home user setup:

/dev/disk/by-uuid/XXXX-XXXX  /media/data  ntfs-3g  uid=1000,gid=1000,fmask=113,dmask=002  0  0

Let's break down these parameters:

• uid=1000: Sets the owner of all files to the user with ID 1000 (usually the first created user).
• gid=1000: Sets the group owner to the primary group of that user.
• fmask=113: This octal value removes execute permissions for others and read/write for others. It effectively sets files to 644 (readable by all, writable by owner).
• dmask=002: This allows group members to write to directories, setting them to 775.

If you want broader access for other users on the machine, you can adjust the masks. For example, fmask=000,dmask=000 would make all files world-readable and writable, which is generally insecure but useful for temporary media sharing. After saving the file, unmount and remount the drive to apply changes:

sudo umount /media/data
sudo mount -a

Verify the new permissions using ls -l /media/data. All files should now show your user as the owner.

Alternative: Using udisksctl for Temporary Access

If you cannot edit /etc/fstab due to administrative restrictions, or if you need a quick fix for a removable drive, you can use udisksctl. This tool manages storage devices via the D-Bus interface and respects user policies. To mount a drive with specific permissions without editing fstab, use:

udisksctl mount --block-device /dev/sdb1 --no-block -o uid=1000,gid=1000

This command mounts the device temporarily. Once you log out or reboot, the drive will be unmounted, and the next manual mount will revert to system defaults unless you update your policykit rules. This method is less reliable for persistent workflows but useful for troubleshooting. For users experiencing hardware-related issues during such operations, such as sudden disconnects causing corruption, refer to our article on Troubleshooting System Freezes after Changing Processors or GPUs on Linux, as unstable power delivery can sometimes corrupt mount states.

Troubleshooting Common Errors

Even with correct fstab entries, you may encounter errors. The most common is "Wrong fs type, bad option, bad superblock." This usually indicates a mismatch between the driver specified in fstab and the installed kernel modules. Ensure you have ntfs-3g installed:

sudo apt install ntfs-3g

Another issue is the drive mounting as read-only. This happens if the NTFS volume has an inconsistent journal state, often caused by unsafe removal from Windows. In this case, boot into Windows and perform a full shutdown (not hibernation), or use the Windows chkdsk utility to fix the volume. If you still face permission issues, check the SELinux context. Some distributions enforce strict security policies that override standard Unix permissions. Use restorecon -Rv /media/data to reset contexts to their default values.

Frequently Asked Questions

Why do my files show as owned by root?

This occurs when the mount options specify uid=0 or omit the uid parameter entirely. By default, some systems mount removable media as root for security. Explicitly setting uid=your_user_id in fstab resolves this immediately.

Can I recover original Windows ACLs on Linux?

No, the standard ntfs-3g driver does not preserve or map Windows ACLs to Linux permissions. It uses a flat mapping strategy. You can view raw ACLs using getfattr if they are stored on the disk, but Linux applications will ignore them unless you use specialized drivers or WSL.

What is the difference between fmask and dmask?

fmask applies to regular files, stripping bits from the default 777 permission set. dmask applies to directories. For example, fmask=113 results in 644 permissions, while dmask=002 results in 775 permissions.

Is ntfsfix safe to use for permission errors?

ntfsfix repairs basic filesystem inconsistencies and clears dirty flags, but it does not change ownership or permission mappings. It is useful if the drive won't mount due to corruption, but it will not fix "Permission Denied" errors caused by UID/GID mismatches.

How do I handle multiple users needing access?

Create a shared group (e.g., smbshare) and add all relevant users to it. Set the gid in fstab to this group's ID. Then, use dmask=002 and fmask=013 to allow group write access to directories and group read access to files.