I have a dual-boot PC, Ubuntu / Windows 10, that share access to a NTFS disk partition (mounted as /DATA/ in Ubuntu).

I need to avoid the "Permission denied" error when a chmod command is executed on a file in such shared partition, regardless the user calling this command. This is because I chmod is called as part of bigger procedures and the users cannot just avoid them, and when they return an error the whole procedure stops.

What I tried:

/DATA/ is now being mounted with the permissions option (mapping file is activate) and under a non-root user that has the ID of 1001, and all users are part of the the group with ID of 1003, to which rwx is allowed, i.e.:

UUID=...  /DATA  ntfs  auto,users,rw,permissions,umask=007,uid=1001,gid=1003  0  0

This solution ALMOST works. Everyone can r+w and, when the user 1001 calls chmod we don't get an error. It does not make any change indeed, but it is not a problem. The problem is that for other users the command chmod still trigger errors as they are not considered the owners of the files.

Is there an way to give ownership of the partition mounted on /DATA/ to all users? Or to the user who first logins at least?

Or at least make the chmod command never return an error?

  • 1
    Microsoft formats like NTFS, do not support Linux ownership & permissions. Or you cannot use chmod nor chown on NTFS. You have to set defaults using fstab or with your manual mount of the NTFS partition.
    – oldfred
    Jul 17 at 22:57
  • Yes, indeed. This is why I added the "permissions" option in the fstab, which activates the "User Mapping File" that mocks the POSIX permissions, not causing commands like "chmod" to throw errors when the owner of the file is the own user. The issue is that I want such working for all users. Jul 17 at 23:18
  • Do not use permissions setting with NTFS ubuntuforums.org/showthread.php?t=2459226 & ubuntuforums.org/showthread.php?t=2404647
    – oldfred
    Jul 18 at 3:24
  • @oldfred NTFS fully supports POSIX permissions because it was designed for Microsoft POSIX subsystem in 1993 and later also used for Subsystem for UNIX-based Applications and WSL. Stop spreading that misconception. That's also the reason why NTFS can store all POSIX file names. The permission is stored in $EA_INFORMATION stream by MS or a user mapping file in ntfs-3g
    – phuclv
    Jul 18 at 6:03

Does the program that calls chmod hard-code the path to /bin/chmod?

If not, if it just runs whichever chmod program is first in the PATH, try creating a directory that contains only a symlink called 'chmod' to /bin/true.

e.g. (as root):

# mkdir /usr/local/dummy
# ln -s /bin/true /usr/local/dummy/chmod

Then set the PATH to have this directory first (PATH="/usr/local/dummy:$PATH") before running the program. You can create a wrapper script to set the PATH and then run the program.

You might want to make a symlink for chown too.

BTW, this is stating the obvious, but you don't want this PATH setting to be the default. You only want it when running the program that triggers the problem.

  • Nice "dirt trick that works"! I was not aware of this /bin/true and /bin/false. Thanks for the tip!. Jul 18 at 11:36

Contrary to popular belief, NTFS is a POSIX-compliant file system. It supports all POSIX filenames and POSIX permissions §

In Windows the POSIX permisions are stored as extended attributes in the $EA_INFORMATION stream. I don't know if the current ntfs-3g driver supports that, but it does support mapping Windows permissions to POSIX permissions via user mapping file. After configuring that ntfs-3g will handle the permission translation automatically when you run chmod.

§ That's because in the 1980s the US federal government required that certain types of government purchases be POSIX-compliant, therefore MS had to include a POSIX subsystem in Windows. As a result NTFS must also support POSIX features like special characters in filenames, hardlinks, case sensitivity, permissions... It was first used for Microsoft POSIX subsystem and later Windows Services for UNIX (SFU), Subsystem for UNIX-based Applications and finally .

  • Yes, this is true. In Linux, the user mapping file is not active by default, and thus we need to set the permissions options in fstab to activate it. The chmod will only take effect if the masks (umask, gmask) are not set. The point here is: a partition is still mounted with one and only one user owner, and only this owner can use chmod. Jul 18 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.