umask

[UKenGB]

Is it possible to specify a umask for the merged directory?

I want to ensure everything is created group writable.

If it's not possible to specify for the merged directory, does mergerfs respect any umask setting for the branches? So if all branches are set umask=002, would the resulting merged directory 'inherit' that umask?

[trapexit]

It should respect umask like any other filesystem. I've not fooled with that in years but the code is there.

[UKenGB]

I thought this was sorted, but it's not making sense to me.

For the merge mount options I included 'umask=002' and after remounting the merge, a created directory was indeed now 775 so I thought all was good.

However, I now find several odd behaviours I'd like to clarify.

First of all, it seems that the umask of 002 is being applied identically to files and directories. So files also end up 775 which is definitely NOT what is wanted and as far as I'm aware is incorrect application of a umask. It should mask the default mode, which is different for files and directories, being 666 and 777 respectively. So a umask of 002 should result in new files being 664 and new directories 775, as per a normal mount. Whereas in my merged mount, I now have thousands of executable files. Audio and video files so not only incorrect but kinda nonsense.

Also, what is the relationship between file perms in the merged directory, compared to the source branches?

I had assumed this was 1 : 1 and whatever perms a source file had, it would be the same in the merged directory and if any perms were changed on any file (or directory) in the merged directory, that would be applied to the real file in whatever branch in which it resides. This seems to not be the case.

All the files in the merged directory, as I said, appear to be 775. I tried to change them to 664, but that does not work. No error, just doesn't change them and they are all still 775. However, the real files are all 664. I cannot say whether they already were (should have been), or if my attempts to change them in the merged directory had done so, but it's simply not reflected in the merged directory, they all have these different perms.

So I'm at a bit of a loss and have no idea what mergerfs is doing, or even what it is supposed to be doing. What I want is that everything is created with the umask of 002 (so files would be 664 and directories would be 775) and for these and ownership to be the same in the merged directory as the underlying source branches. Is this not how it is supposed to be?

[UKenGB]

I removed the umask setting for the merge and now it looks normal again. Viewed in the merged directory, files and directories show the same perms as in the branches, as I think it should be.

So setting umask changed the creation process, but also changes the perms on all existing files, in the merged view. This is not how it should be. Setting a umask value should simply control the perms of newly created files. In a normal filesystem mount, it specifically does NOT change any existing files, but in a mergerfs mount the umask is simply applied to all existing files and directories alike (ignoring what they are in the branches) and then allows no changes. I believe this to be very incorrect behaviour.

I have changed umask now for the appropriate users instead and that will have to do.

[trapexit]

That's how the umask value works in FUSE filesystems as I understand it. I can of course change it but that is the libfuse standard which I never had a reason to modify. AFAIK this is similar to other filesystems that have umask, dmask, fmask like FAT.

https://www.man7.org/linux/man-pages/man8/fuse.8.html

    Override the permission bits in st_mode set by the
          filesystem. The resulting permission bits are the ones
          missing from the given umask value.  The value is given in
          octal representation.

Every request that matters has a umask coming from the kernel that should work as normal. What you are asking is just broad blanket umask instead of individual setting it which isn't a supported feature for the reasons above.

The confusion here I think is that you expect "umask" with syscalls to respond the same as "umask" with filesystems. It doesn't.

[UKenGB]

But umask is purely for the creation of new items (files and directories), not to control the perms of any existing items and in any case is applied to a different default for files and directories so the same umask results in different perms for files compared to directories. Executable is a normal perm for directories, but only for special files, so if umask is taken from the same defaults, then either files or directories would be almost always wrong. A umask of 022 (standard for most linux systems these days) should result in 755 directories, and 644 files, because umask is applied to different defaults and as I said, only applies to creation of new items. I believe the umask in mergerfs is incorrect on 2 counts in that it creates the same absolute perms for both files and directories and also it is applied as a overriding control to every existing files. Suddenly discovering all my media files were executable and could not be changed was something of a surprise I have to say.

I may not be the ultimate expert in *nix filesystems, but in 30 years of dealing with unix and linux, I have never encountered umask being used as mergerfs currently does.

This is all merely feedback as I am now using alternative means to achieve what I need. Still using mergerfs though. :)

[trapexit]

But umask is purely for the creation of new items (files and directories), not to control the perms of any existing items and in any case is applied to a different default for files and directories so the same umask results in different perms for files compared to directories.

There are two umasks that should not be conflated.

1. The one that is part of the POSIX filesystem API. As discussed https://man7.org/linux/man-pages/man2/umask.2.html
2. The one that is a not uncommon argument to some filesystems and libfuse.

Naturally, given mergerfs is a) a FUSE filesystem and b) uses a modified version of libfuse has the behavior of both.

https://manpages.debian.org/testing/fuse/mount.fuse.8.en.html

Override the permission bits in st_mode set by the filesystem. The resulting permission bits are the ones missing from the given umask value. The value is given in octal representation.

https://linux.die.net/man/8/mount (Mount options for fat, hfs, ntfs, udf)

Set the umask (the bitmask of the permissions that are not present). The default is the umask of the current process. The value is given in octal.

All of these, AFAIK, behave the same way. Which is they set the value for all files. Why? Because they are not POSIX compliant and sometimes you need a way to override the values of mode. Just like they all have uid and gid overrides. Some of them have separate "umask" values for files and for dirs but the idea is the same.

Like it or not this is a "standard" behavior and has existed in libfuse for many years. Probably because it is pretty common for FUSE filesystems to not be POSIX compliant. Is it good policy to for the library to have standard arguments? No, I don't think so. And you can see from my project's history I have removed or fail to mention these arguments/default behaviors. But they still exist because I don't want to break the system of anyone who may be using them.

This is all merely feedback as I am now using alternative means to achieve what I need.

Noted... but as I tried to explain you are conflating two different things called "umask" . If you want a feature like you've talked about you can request it. However, it is not an incorrect behavior.

Most filesystems don't have this filesystem wide umask(1) setting. You are asking for something special. umask(1) works fine in mergerfs.

As you can see both with and without mergerfs the setting of umask functions as expected.

As for the mergerfs option/argument umask it behaves as found in other non-posix filesystems and libfuse.

Setting the FAT mount to use umask=007 results in the same settings as in mergerfs using the same. It may not be the feature you're looking for but it within the defined behavior.

[UKenGB]

"It's umask Jim, but not as we know it".

(A Star Trek reference non 'trekkies' might not get :)

[trapexit]

Star Trekking! Across the universe. Boldly going forward cause we can't find reverse.

[UKenGB]

😄

[trapexit]

For reference: https://www.youtube.com/watch?v=FCARADb9asE

[UKenGB]

😄👍