Re: Dropbox files no longer inherit folder permissions

rjwb · ‎12-03-2019

Within my Dropbox folder, I have sub-folders with different Windows ACL permissions. Up until recently, whenever Dropbox synced a file it inherited its folder permissions perfectly.

Now it no longer does. It overrides the folder permissions and sets all file permissions to something completely different - Full Control for admins and Read/Read & Execute for users.

Is there any way to get back to the old days - when Dropbox respected the inheritance of ACL permissions to all files in each folder?

alux · ‎02-16-2020

@jane I'm having this exact same problem. Can you please fill me in on what the resolution was? Can you please create a support request for me as well, if that's what it takes? This is a major problem for us.

Brian1 · ‎02-16-2020

@alux There was no resolution. This is Dropbox we're talking about, after all. They're thinking on it (see recent posts).

Meanwhile, see the explanation and workaround from @XLI a month ago:

https://www.dropboxforum.com/t5/Files-folders/Dropbox-files-no-longer-inherit-folder-permissions/m-p...

alux · ‎02-17-2020

It worked! Thanks .@Brian1

@Brian1 wrote:
@aluxThere was no resolution. This is Dropbox we're talking about, after all. They're thinking on it (see recent posts).
Meanwhile, see the explanation and workaround from @XLI a month ago:
https://www.dropboxforum.com/t5/Files-folders/Dropbox-files-no-longer-inherit-folder-permissions/m-p...

LeavingDB · ‎02-17-2020

Hello,

I started a trial with sync.com. Unfortunately, from an objet rights point of view, it works the same, so it doesn’t fix the problem, at not just like that. However ...

The sync.com file structure, on a PC, is similar to Dropbox, a directory is selected at install time and all the sync.com files go there. Located in that directory, a special one used for sync.com control, named Sync.Cache, which is quite similar to what DB does. When the client fetches a file from the cloud, it goes in the Sync.Cache\blobs directory under a temporary (maybe random) name. Once download is completed the file is moved to the proper directory. At one point it’s renamed, but I was not able to ascertain when this happened, before or after the move, which is a moot point for our problems.

Because of a 26-year-old bug in NTFS, some call it a feature, it’s not, it's a bug from lazy designers, when a file is moved on the same drive, it retains its previous security scheme rather than inherit security from the parent directory. - can we really call the NTFS rights propagation process inheritance? Let's call it a poor man solution. Novell NDS had inheritance, NTFS does not, but I degress.- One thing that saved my life in numerous occasions is junction points, two weeks ago I tried to move the Dropbox control directory to another drive, but the Dropbox client didn’t like it, but it looks like the sycn.com client doesn’t mind.

So, yes, if using sycn.com we can have NTFS rights propagated by moving the sync.com directory to another drive and creating a junction point in the original directory. No, it’s not an elegant solution because we never know when this will stop working and, let's not forget, I just did a few tests to see if the rights were propagated properly, not test the entire solution, so something else may break down the road.

The solution is quite simple, these clients should apply the rights of the parent directory once the file move is completed, which is what DB was doing, most probably, before December 15, 2019. I will let the sync.com support know of our plight and ask them to patch their client, let's see if they are more responsive...

zombie343 · ‎02-17-2020

I'm encountering the issue described by Windows 10 Pro users in this thread. I've been using dropbox since 2012 and in the simplest configuration possible: my dropbox is my offsite backup solution for files and that's it.

Files/Folders have stopped syncing since 2020/01/08 ~2PM EST due to permission changes.

Brian1 · ‎02-17-2020

That doesn't sound like the same issue though, since syncing doesn't stop with the problem in this thread. It's just that's what synced doesn't have expected permissions.

phaaeeL · ‎02-20-2020

Hope some of you are still here, mostly the ones that are investigating the issue further (at least looks like we are doing it more than dropbox support)

my case is exactly the same as the ones using windows server, but im using Ubuntu server, and was told the same thing (server is not supported)

the solution i did was the same as suggest here, i crontab "chmod" to give permissions back to every file/folder on the dropbox path, but for some of the offices i manage its not viable since we have very large files.. at first it seemed like i was just stuck on a loop with sync/indexing but after looking more i found that everytime my crontab ran the dropbox started to sync.. well, of course, since the permissions change the files were "changed" ..

and it started at the same date as reported here, i started to get complaints after the holidays since ppl started to get back to their offices and couldnt edit files/save on folders that they had created from outside (using dropbox app from notebook/cellphone) and as someone pointed out, even from the dropbox site.

im thinking of changing to windows server (as many of the alternatives doesnt support linux) so i would like some input from you guys if possible, if you have made the swap, how it went, is it realiable?

ive been using this combination for over 4years and suddenly it doesnt work anymore.. and the worst part is that i didnt even UPDATED the app, it was a SILENT UPDATE !!! i dont update anything but security packages so i DONT BREAK stuff, to avoid THIS, exaclty THIS !

as said in this post i trully belive that it IS A MOVE from dropbox to make we jump to their business acc and use multiples users, which it was already said too, would be a pain to manage..

sorry for the rant, it was just good to be able to "validate" what i was thinking and telling my clients..
hope we can all find a solution, sadly i couldnt reproduce the solution on this (ps, look at the date)
> https://superuser.com/questions/549591/how-to-preserve-ownership-and-permissions-in-dropbox

which was >

HOME="$HOMEDIR" start-stop-daemon --umask 0006 -b -o -c $dbuser:$dbgrp -S -u $dbuser -x $HOMEDIR/$DAEMON

hope it at least can help someone, even tho it was for a MAC, maybe someone have some ideia with that.

thks in advance for any inputs, and good luck to we all.

LeavingDB · ‎02-21-2020

@phaaeeL

I started a trial with Sync.com. Unfortunately their client moves a downloaded file from a temporary directory to the final destination, however, I think the software was designed to work this way from the start, as in ... they didn’t go out of their way to break something that was working, contrary to Dropbox. Of note, Sync.com works, for what I tested it, when junction points are used (MKLINK /J) while Dropbox does not work in such a setup.

I informed Sync.com that preserving NTFS rights was mandatory for us, administrators. I also cited that Dropbox had left many of us in the dark with this issue since December and that I was ready to make the jump to their company if they implanted this change. I was informed that my recommendation had been forwarded to the development team. Will it be implemented? That remains to be seen, but at least it’s better than no answer at all, à la Dropbox.

@AllIf you plan on moving to Sync.com, let them know that NTFS rights propagation is important for you.

chouste · ‎02-25-2020

Same Issue! Thanks for posting, I have been pulling my hair out as well trying to figure this out. BAD MOVE DROPBOX! WHY WHY WHY! We have a lot of $$$ invested into our DB tools and the way we use them. THIS IS FRUSTRATING!

chouste · ‎02-25-2020

Same Issue! Thanks for posting, I have been pulling my hair out as well trying to figure this out. BAD MOVE DROPBOX! WHY WHY WHY! We have a lot of $$$ invested into our DB tools and the way we use them. THIS IS FRUSTRATING!