Whenever I look at any of my unionfs/rclone folders, every single file is set with the executable bit. I've looked at my configs and I don't see anything that should be allowing that. The systemd services all have a umask of 002, yet it's still 777 across the board. How can I fix this so that the files are 664, like I would expect them to be?
What is your rclone version (output from rclone version)
1.52.2
Which OS you are using and how many bits (eg Windows 7, 64 bit)
Ubuntu 18.04.5 TLS 64bit
Which cloud storage system are you using? (eg Google Drive)
Google Drive with Team Drives
The command you were trying to run (eg rclone copy /tmp remote:tmp)
Can you run a mount with debug and share the same output?
felix@gemini:~/test/test$ ls -al
total 0
-rw-rw-r-- 1 felix felix 0 Oct 8 19:44 one
-rw-rw-r-- 1 felix felix 0 Oct 8 19:50 two
felix@gemini:~/test/test$
I think this is the important part, because (normally) that will result in files having mode 775, which is rwxrwxr-x, which matches what you see with ls.
It's not sure if this will remove the x permission from directories though. If it does then you might want to remove the umask value and use dir-perms and file-perms instead.
That's actually not correct as it works a bit different.
felix@gemini:~/test$ umask 002
felix@gemini:~/test$ touch one
felix@gemini:~/test$ umask 000
felix@gemini:~/test$ touch two
felix@gemini:~/test$ ls -al
total 4
drwxrwxr-x 2 felix felix 28 Oct 8 21:39 .
drwxr-xr-x 24 felix felix 4096 Oct 8 20:39 ..
-rw-rw-r-- 1 felix felix 0 Oct 8 21:39 one
-rw-rw-rw- 1 felix felix 0 Oct 8 21:39 two
If you have a umask of 002, all the files will be created with 664(666-002) permissions and dir with 775(777-002) permissions.
You've missed a subtle point. It's important to remember that umask modifies the permission mask requested by the program, and touch requests 0666 as the permissions, and so the umask would then make that 0664. If you call creat(2) with mode 0777 then it'd be different. That's how files are created.
That's because the result of gcc is created with permissions 0777, the same as my example program.
But this isn't the same as how modes are faked when reading filesystems that don't have unix permission modes.
Now I don't know what protocol rclone mount follows when faking permissions. But the original umask of 002 matches very well "0777 AND NOT(002)" and so is very suggestive.
The umask command modifies how files are created. The umask command does not modify output.
$ ls -l x ; umask 0 ; ls -l x ; umask 0777 ; ls -l x
-rwxrwxr-x 1 sweh sweh 0 Oct 8 22:18 x*
-rwxrwxr-x 1 sweh sweh 0 Oct 8 22:18 x*
-rwxrwxr-x 1 sweh sweh 0 Oct 8 22:18 x*
Your examples, earlier, showed the umaskcommand.
However the umaskflag to mount affects output. These are two different things. Even though they're both called "umask" they are two different things. Related, but different.
I may be wrong about the mount, which is why I said "suggestive" and "may". But nothing you've written demonstrates you think it does. You provided unix commands that only affect creation. Not how rclone uses it for mounts.
I think you are confusing what happens on a cloud remote vs a local file system.
That statement is accurate on a cloud remote. On a mounted rlcone remote it is all display as there is no concept of permissions on my mounted Google Drive so it modifies the output.
Here is the constrast between a local Linux disk and a mounted rclone remote.
felix@gemini:~/test$ ls -al
total 1
-r--r----- 1 felix felix 243 May 19 2019 mounted
dr--r----x 1 felix felix 0 Jun 17 2018 Movies
dr--r----x 1 felix felix 0 Oct 8 19:44 test
dr--r----x 1 felix felix 0 Apr 18 2017 TV
felix@gemini:~/test$ umask 000
felix@gemini:~/test$ touch blah
ls -al
felix@gemini:~/test$ ls -al
total 1
-r--r----- 1 felix felix 0 Oct 8 22:36 blah
-r--r----- 1 felix felix 243 May 19 2019 mounted
dr--r----x 1 felix felix 0 Jun 17 2018 Movies
dr--r----x 1 felix felix 0 Oct 8 19:44 test
dr--r----x 1 felix felix 0 Apr 18 2017 TV
felix@gemini:~/test$ cd
felix@gemini:~$ touch test2
felix@gemini:~$ ls -al test2
-rw-rw-rw- 1 felix felix 0 Oct 8 22:36 test2
Umask in rclone is purely display unlike a local disk when it's all about file creation.
I agree. It's what I've been saying. What I was disagreeing with was your use of the unix command line umask command to demonstrate how it works. Which is what you did. Because the two concepts are totally different.
umask on a mount is synthesising permissions on file read. umask on the command line is modifying permissions on file creation.
In his command though, he's running --umask 002 and getting the wrong output so either his rclone command he shared is wrong or he's not on the rclone drive.
in the original post the OP is running mergefs on two "local" directories, of which one directory is rclone mounted. The mergefs layer could be hiding things and synthesising its own set of permissions.
I don't think we actually saw the underlying rclone mounted filesystem, just the merged one.