Permissions for new files omit group write permission

[Baetsi]

Using the Dropbox Sync app on a Linux machine

Newly created files lack the "Write" bit and this makes the shared folder inaccessible for other users on the network.
Already checked the `umask` and it is correctly set to 0007 for the user, and also for the process when queried using `gdb`
Running `strace` on the file writer thread I see the following:

openat(AT_FDCWD, "/mnt/Dropbox/.dropbox.cache/new_files", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 120
fcntl(120, F_SETFL, O_RDONLY)           = 0
fstat(120, {st_mode=S_IFDIR|0770, st_size=7, ...}) = 0
mkdirat(120, "18075a7c044f08a6659c56dd00da82ed", 0755) = 0
openat(120, "18075a7c044f08a6659c56dd00da82ed", O_RDONLY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) = 121
fcntl(121, F_SETFL, O_RDONLY)           = 0
fstat(121, {st_mode=S_IFDIR|0750, st_size=2, ...}) = 0

...

openat(AT_FDCWD, "/mnt/Dropbox/.dropbox.cache/new_files", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 58
openat(58, "18075a7c044f08a6659c56dd00da82ed", O_RDONLY|O_NONBLOCK|O_NOFOLLOW) = 105
fcntl(105, F_SETFL, O_RDONLY)           = 0
fstat(105, {st_mode=S_IFDIR|0750, st_size=2, ...}) = 0
fstat(58, {st_mode=S_IFDIR|0770, st_size=8, ...}) = 0
fstat(123, {st_mode=S_IFDIR|0750, st_size=3, ...}) = 0
newfstatat(123, "Test2345", 0x7f8976bf6d80, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
renameat2(58, "18075a7c044f08a6659c56dd00da82ed", 123, "Test2345", RENAME_NOREPLACE) = -1 EINVAL (Invalid argument)
newfstatat(123, "Test2345", 0x7f8976bf6be0, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
renameat(58, "18075a7c044f08a6659c56dd00da82ed", 123, "Test2345") = 0
utimensat(123, "Test2345", [UTIME_OMIT, {tv_sec=1673373843, tv_nsec=0} /* 2023-01-10T19:04:03+0100 */], AT_SYMLINK_NOFOLLOW) = 0
newfstatat(123, "Test2345", {st_mode=S_IFDIR|0750, st_size=2, ...}, AT_SYMLINK_NOFOLLOW) = 0
close(105)                              = 0

So the directory is created without the group write bit

Is this hard-coded? How can this behaviour be changed?

[Walter]

Hey @Baetsi, sorry to hear you're having issues with this.

Can you please let us know some additional information and clarify what you'd like to accomplish here and where Dropbox comes into play exactly? 

When you say the shared folder  is inaccessible to other users on the network, do you mean other members of the shared folder who have their own Dropbox accounts or other users on the same network as you, using the same device(s)? 

Keep us posted!

[kegloadam]

Hi @Walter,

We have 1 Linux with 6 users. All 6 users running Dropbox agent with selective sync. All the 6 users Dropbox folder symlinked to one folder which is shared over SMB by the Linux itself.

[Megan]

Hi @kegloadam, can you clarify if the folder is shared only over the network, or if it's a shared folder in Dropbox too?

Do you simply want to have the files located in Dropbox, and share them over your local network to be accessible for other users? 

[kegloadam]

Hi @Megan,

It's mixed. 🙂 Some folders shared via Dropbox as well (online). And all files shared over SMB locally from the Linux itself.

The use case is: Internal users can reach all Dropbox files via SMB and 6 dropbox clients (6 different Linux users) syncing all the files (6 "main folder" with selective sync). Its reason to have 6 different users with selective sync instead of 1 is that, we have 2 millions of files and re-indexing after a reboot or just periodically (when the dropbox client wants to do it) takes much less time with this solution.

[Hannah]

Hey @kegloadam, thanks for the additional info.

Our team is looking into this, but we don't have an ETA for you at this time.

You will be updated, once we have more info on our end.

Thank you!