Dropbox files no longer inherit folder permissions

[rjwb]

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?

[Walter]

Hi @RAR_Systems - welcome to our Community!

I'm not sure if you're referring to this, but could you take a look at the discussion I had a little while ago with some other users that noticed something similar? 

Cross-linking it here for reference: 

• https://www.dropboxforum.com/t5/Files-folders/Dropbox-files-not-inheriting-NTFS-sharing-permissions/...

Is this what you're talking about as well? 

[dragoner]

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.

[Brian1]

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

[dragoner]

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.

[volfman]

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

[Brian1]

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

[dragoner]

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.

[Brian1]

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.

[dragoner]

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 😊

[LeavingDB]

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.