Dropbox files no longer inherit folder permissions

Thanks for the post pwc.  I am experiencing same issue and have submitted your template to support.  I look forward to hearing that this has been resolved as it has broken dropbox functionality for our office.

rjwb One suggestion: most of my external Dropbox changes are coming in the evenings or weekends as people are working from home. I've added a scheduled task on the server to reset the ACLs at 4am. Working for now, but it's a Band Aid  solution. Have a separate call to icacls for each directory that needs a ACL reset. In my example below (I've only slightly tweaked it from how we actually use it), each of these folders has a unique, non-inheirtable set of rights, so I need to run icacls for each. Here's a generic version of my batch file:

rem Resets the ACLs for all folders to fix the Dropbxo ACL problem that started in Jan 2020
icacls "E:\Dropbox\Accounting\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Transfer\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\Admin\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\Engineering\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\Finance\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\HR\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\Marketing\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\Operations\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\Purchasing\*.*" /reset /T /Q /C
icacls "E:\Dropbox\Company\Sales\*.*" /reset /T /Q /C

Make sure to run it as administrator so it has the requisite rights to make the changes. You could even go so far as to run it hourly (or at least multiple times a day... whatever makes sense for you)... it does cause Dropbox to think files have changed, so it goes through sync phase, but no files are actually transferred to it's pretty quick (a few minutes for ten of thousands of files) before Dropbox is happy again.

This is still only a temporary solution, but gives me a lot of breathing room to find an answer.

One other feature consideration I thought of while writing the post above: if you have a paid-for Dropbox account, it has a great file revision history capbility. We pay for the extended 1-year history (the standard history is 30 days), so we can recover a version of the time any time in the last year.

Additionally, and great insurance, is the ability to restore a folder tree to a specific point in time. How does that help you? It's a hugely valuable defense against a ransomware attack. If attacked, I can simple rewind a file system to the point in time just before the attack and recover everything. If you do regular backups, you might be protected, but if your backup repository is not firewalled against outside access, it's at risk of being encrypted, too. You might have offline/offsite backup, but it's going to be dated.

Not sure if O365 (my first choice as an alternate to Dropbox) has this capability, but goes back to a comment I mean in an earlier post: I've spent a lot of time understanding Dropbox, and moving to a new service is going to be a significant effort and relearning experience. And I'll likely find it's missing things I used in Dropbox (like this feature). I really hope Dropbox listens and puts proper ACL inheiritance back in place, as that'd make my life easier.

Same here, not overly keen on moving over to Onedrive and as far as I know it doesn’t have the rollback capability Dropbox has. When I looked into that for a customer a few years ago, it only had the ability to restore previous versions of Office documents. Dropbox has been well suited to the whole offsite backup/version control/undelete etc..

I have Dropbox installed on around 40 sites at the moment, and there are a handful that are suffering from this new change, where collaboration is required with the onsite server’s copy of the data. I’d be keen to hear what others are moving over to and to compare pricing/features. And also for example if Onedrive has the capability of running a single account on a server, running as a service (AlwaysUp), and has the capability to roll back entire directories or the entire account in the case of a cryptolocker attack??

I’ve run up a short term solution for some smaller clients by sticking in a Windows10 VM and making that the file server for now. Not a great fix when you have many internal users though.

dragoner, I'm a little confused by how Win10 is helping you with this problem. AFAIK, it's an equal-opportunity offender across all versions of Windows. It's not Server-specific.

I’ve only seen it at sites where Dropbox is installed on Windows server. If a file is modified from a Dropbox account at a remote site using Windows 10, when the modified file hits the Dropbox account on Windows server, the permissions are not honoured. I have just moved a bunch of users over to a Windows 10 pseudo server at a site, and the problem is no more. I’m only seeing the problems when Windows server is involved.

My thoughts are this is just a cash grab by Dropbox to try and get users to invest in their multi user plans as opposed to using a single account and sharing data out using standard Windows networking.

For support to just fob us off when they see a server OS is involved is pretty **bleep** lousy.

In my testing the same issue happens with Windows 10, even without doing any kind of network sharing. Here's how I reproduce it: 

PC#1 - set special permissions on a file. For example, add another windows user to have full modify permission on this file

PC#2 - make changes to this file in local PC #2 dropbox. 

PC#1 - Check permissions on the file after Dropbox sync's. The added user permission is gone, and the permissions of the file (as inherited from it's parent folder) are also gone. The permissions on the file change to the same permissoins as the .dropbox.cache folder (which by default gives "Users" only read-only permissions). 

dragoner, have you checked that you're comparing apples to apples in terms of inherited permissions?

That is, if you look at the appropriate  root folder on both systems, you see the same set of permissions there to begin with? It could well be that Server happens to have fewer, and if so, that's what DB is going to use in that case.

This is what threw me off when, early on, I thought Win7 didn't have the problem. Then I discovered that the Dropbox folder there had quite a different set of permissions (more) relative to Server's.

In this particular case, there is a Windows 2016 server at site 1 with Dropbox installed. There is a separate 2016 DC. It’s a Windows Domain environment.

Site 2 is not connected to site 1. Site 2 has a Windows 10 mini server with Dropbox installed and several users who access the shared data over the network using mapped drives.

Using Dropbox to sync the data between the sites has been working without issue for several years until the bad update this thread is referring to.

As of the bad update, if a file is modified at site 2 (Windows 10), the file will lose its historical local NTFS permissions when synced through Dropbox to site 1. To fix the issue I must log in and force inherited permissions down through the relevant folder hierarchy.

Both sites have very different sets of NTFS permissions as the sites are not connected in any way apart from Dropbox. This has always been the case, but never an issue. Local NTFS permissions are not synced through Dropbox. If they were it would create havoc for collaboration – one of Dropbox’s top features.

Yes, I'm glad it doesn't sync NTFS permissions either, as that would be chaos.

But what I'm wondering by way of explaining why you only see the problem in one direction: let's say the top folder in SIte 1 has only SYSTEM and Administrators permissions. This isn't uncommon for Server. That means, with this dumb bug, any file syncing TO Site 1 will end up with only those two permissions, unless you implemented the cache workaround.

But then let's say the equivalent folder in Site 2 has SYSTEM, Administrators, and others. Site 2, in that case, may appear not to have the problem because any files syncing TO Site 2 will end up with not only SYSTEM and Administrators but any other permissions that happen to be set in the top folder. Win10 defaults to including Users, for example.

I haven’t done enough testing to confirm if its bi-directional but its only come to my attention on the server side. The folders I would generally nest within Dropbox would have varying permissions depending on which departments on the network required access. On a free for all folder that would include Domain Users to have full modify permissions.

Remember, it’s been working for a long time at a lot of sites until this bug appeared. I’m not confusing site permissions in any way. I believe Dropbox have introduced this new feature to detect Server OS, and cause issues. It could possibly cause users to upgrade to multiuser plans and increase profits.

That wont happen of course 😊

Adding my 10 cents to this conversation. I used the template provided in this thread to report the issue and, of course, I received a non-helping response. We took the decision to move away from DB, we'll try sync.com as the service looks similar and it cost less! Included in the price, a 365 days of history. I am not saying it works since I didn't do any tests, I just looked at the web site, but it looks promising.

Thanks for the feedback, will take a look at sync.com. Ive just had feedback from a site, the Windows 10 to Windows 10 also now fails, no server operating systems in play.

Way to go Dropbox support, thanks for all your assistance with this.

i'm running into this same issue with our server setup. never had a problem until recently and frankly it was a bear to debug and finally figure out what was happening.

glad to find others with the same issue.

i'm not sure what the solution is here. if we put the client on every computer in the office, it becomes a CPU/memory hog and total PITA to maintain. the server-based syncing combined with NTFS permissions was a perfect solution.

i know there are NAS devices that sync with dropbox, how does this update affect them? i think they tend to use the API so not sure if they would have the same problem or not.

QNAP and Synology have devices that sync with dropbox and allow for NTFS permissions to be applied (as well as other device-specific permissions) -- will they now be DOA with this update?

Curious if anyone has one of these and has seen a change.

Just an update on the issue: Advanced Support responded to our ticket today (opened a couple weeks ago and responded to back then by what was presumably Standard Support), and this is what he said:

"I've raised a task with our engineering team in relation to this issue and as soon as I have more information I'll let you know."

I also received a response today asking to try the latest Beta Build 91.3.536 . I tested this version, and the issue is still there. No resolution yet. 

Has anyone been able to do a more complete evaluation of sync.com? It has all of the features I'd like to see, include 365-day rewind, plus granular access control within the cloud content itself (not just the top-level access control Dropbox offers), and it's half the price.

I hope to do a more thorough evaluation of sync in hte near future, will post anything useful I find. I really don't want to make the move, it'll be painful, but I need to resolve this issue. I'd stay with Dropbox, even considering the price difference, as I've otherwise had a very good experience with them, but not if this issue cannot be resolved.

As a side note, I've found that running the scheduled task in the early morning that resets the ACLs within the Dropbox folder has mostly resolved the problem, as most external changes are coming in from my users working on stuff at home in evenings or weekends. It's a total MacGyver fix, one step up from bubblegum and duct tape, but it's working for now.

Steve Gibson has, on his Security Now podcast. It's discussed in the second half of the shownotes here:

https://www.grc.com/sn/sn-734-notes.pdf

Or you can watch it more fleshed out in the last hour or so here:

https://youtu.be/ogrQgb0csoU?t=2941

Brian1thanks for the link! That's very useful information, and comes from a very trusted source (Gibson has been around for a long time). One consideration I had not really thought about is end-to-end encryption... while I do have confidence in Dropbox, it's no more than I would have for any other cloud-based service... in general, their fragility to hacking has been demonstrated many times. While data may be encrypted on their service, and they use secure tunnels to transport data, all of my information is just a cracked password away.

Just another aspect to consider when looking at Dropbox alternatives.

Excellent information, thanks Brian1

Dropbox support have completely let us down with this one. It’s amazing what good can come from situations like this 😊

I’ve got close to 40 sites I manage with Dropbox so will be very keen to roll one over to Sync and see what I’m going up against!

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...

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. 

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.

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.

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.