You are not logged in.

#1 2021-11-08 15:57:26

shayaknyc
Member
Registered: 2021-09-17
Posts: 5

Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

Hi all,

I downloaded and compiled the `linux-cacule` (5.15.1-1 for native `ntfs3` support) kernel from the AUR repo. Following the documentation here on the new ntfs3 mount option:
https://www.kernel.org/doc/html/latest/ … ntfs3.html

You can specify the umask (files and directories) or fmask and dmask separately. I have an NTFS partition on one of my drives which is being mounted via UUID in my /etc/fstab file like so:

UUID=B29AC1289AC0EA45          /Windows8_OS   ntfs3 ro,nosuid,nodev,relatime,nohidden,sys_immutable,acl,uhelper=udisks2,umask=0022,uid=1000,gid=1000,iocharset=utf8,user 0 0

You'll notice that my umask specifies 0022, which should result in 0755 for directories and 0644 for files. However, when I run the mount command, this is what my output shows:

/dev/sda5 on /Windows8_OS type ntfs3 (ro,nosuid,nodev,noexec,relatime,uid=1000,gid=1000,fmask=37777600022,dmask=37777600022,iocharset=utf8,sys_immutable,nohidden,acl,uhelper=udisks2,user)

What are these fmask and dmask values? Does it not matter since I'm mounting the partition as ro?

I tried manually mounting another NTFS partition from /dev/sda7 with the following command:

sudo mount -t ntfs3 -o rw,nosuid,nodev,relatime,nohidden,sys_immutable,acl,uhelper=udisks2,umask=0022,uid=1000,gid=1000,iocharset=utf8,user /dev/sda7 /home/user/test

and after it successfully mounted, I ran the mount again and it displayed the same long number for fmask and dmask. I traversed into /home/user/test and typed touch hi and that worked just fine and the file perm was 644.

I even tried remounting but with umask=022 instead to see if that would have made a difference, but the subsequent mount indicated the same long values. I then tried remounting again but instead of umask, I specified fmask=022,dmask=022 but after it mounted, the mount showed the same long integer. I tried googling for the string fmask=37777600022 but couldn't find anything.

Anyone have any insight into this?

Offline

#2 2021-11-08 16:08:59

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

I'd first suspect it's a formatting bug in `mount` output.  Is that also in /proc/mounts?


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2021-11-08 16:41:07

shayaknyc
Member
Registered: 2021-09-17
Posts: 5

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

Trilby wrote:

I'd first suspect it's a formatting bug in `mount` output.  Is that also in /proc/mounts?

Here's my output:

❯ cat /proc/mounts|grep Windows
/dev/sda5 /Windows8_OS ntfs3 ro,nosuid,nodev,noexec,relatime,uid=1000,gid=1000,fmask=37777600022,dmask=37777600022,iocharset=utf8,sys_immutable,nohidden,acl 0 0

How would I determine if this is a formatting bug or not? What's bizarre, is that my /boot/efi partition is vfat and the /proc/mounts output for that fstab mount looks like this:

❯ cat /proc/mounts|grep mask
/dev/sda5 /Windows8_OS ntfs3 ro,nosuid,nodev,noexec,relatime,uid=1000,gid=1000,fmask=37777600022,dmask=37777600022,iocharset=utf8,sys_immutable,nohidden,acl 0 0
/dev/sdb1 /boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0

Very bizarre. Is there a manual way to find out what the umask value is on a given mount to confirm that it is, in fact, NOT 37777600022, which seems like more of a calculation bug than formatting?

Offline

#4 2021-11-08 16:53:14

seth
Member
Registered: 2012-09-03
Posts: 50,009

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

Bleeding from "noacsrules"? Does setting that other than 777 impact the *mask values?

Edit: you cannot "unset" that or impact its value… hmm

Last edited by seth (2021-11-08 16:54:35)

Offline

#5 2021-11-08 17:15:40

shayaknyc
Member
Registered: 2021-09-17
Posts: 5

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

seth wrote:

Bleeding from "noacsrules"? Does setting that other than 777 impact the *mask values?

Edit: you cannot "unset" that or impact its value… hmm

Sorry, not following.....

Offline

#6 2021-11-08 17:22:17

seth
Member
Registered: 2012-09-03
Posts: 50,009

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

The driver needs to map the NTFS ACLs to the POSIX permission. Next to the *mask rules there's a "noacsrules" option that'll set all permissions to 777 and I suspected that it might bleed into the *mask values, but you can only turn the *mask 777 this way and there's no way to select a different value for the ACLs.
This is why I scratched the post - it's not gonna be relevant here.

Offline

#7 2021-11-08 17:59:58

shayaknyc
Member
Registered: 2021-09-17
Posts: 5

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

seth wrote:

The driver needs to map the NTFS ACLs to the POSIX permission. Next to the *mask rules there's a "noacsrules" option that'll set all permissions to 777 and I suspected that it might bleed into the *mask values, but you can only turn the *mask 777 this way and there's no way to select a different value for the ACLs.
This is why I scratched the post - it's not gonna be relevant here.

Ahh....yeah, gotcha. Makes sense. I wonder if the fmask/dmask values will change if I remove noaclsrules.....I mean, since I'm mounting it RO anyway, it can't hurt.....stay tuned!

EDIT: Wait, I just realized, I don't have "noaclsrules" specified, in fact, I have it "acl" as a mount option..... WEIRD!

Last edited by shayaknyc (2021-11-08 18:02:54)

Offline

#8 2021-11-08 21:01:36

seth
Member
Registered: 2012-09-03
Posts: 50,009

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

seth wrote:

This is why I scratched the post - it's not gonna be relevant here.

smile

You could try w/o "acl", though - no theory, just stuff thrown against the wall to see whether it sticks…

Offline

#9 2021-11-08 21:43:33

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,449
Website

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

shayaknyc wrote:

How would I determine if this is a formatting bug or not?

If /proc/mounts showed it differently, then this would all but confirm it was just a formatting quirk of the mount command.  The fact that /proc/mounts shows the same thing, however, says nothing (doesn't support or rule out this possibility).  I'd still suspect this is the issue - and given that these are masks any value prepended to 022 will have the same effect as 022 in any case in which only the low-byte is used.

My suspicion is that the permissions, though requiring only one byte, are stored as a 4 byte data type (or 64 bits which is the base data type for any cpu that arch linux runs on).  I further suspect that the other three bytes are (normally) just quietly ignored and could really contain any random bits at all.  But for some reason those junk bits are being displayed - this could be as simple as the wrong specifier in a format string in the ntfs3 code.  Anyone familiar with the relevant bits of kernel code could have better insight on whether this suspicion makes sense.

Last edited by Trilby (2021-11-08 21:45:12)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#10 2021-11-08 21:51:45

shayaknyc
Member
Registered: 2021-09-17
Posts: 5

Re: Fstab with umask=0022, mount reports fmask=37777600022,dmask=377776000

seth wrote:
seth wrote:

This is why I scratched the post - it's not gonna be relevant here.

smile

You could try w/o "acl", though - no theory, just stuff thrown against the wall to see whether it sticks…

Yep, didn't work hmm

Offline

Board footer

Powered by FluxBB