Dropbox Download Permissions
Janae Nowinski
Sharing and collaborating in Dropbox is obviously where we shine. But when we share something outside of our org or inside of our org, there are a couple of permissions that we can put on that document, file, or folder when sharing to make sure that it's shared with the correct people, and that the correct people have the permissions that we want. To do this, simply share, find a file or folder that we want to share outside of our organization, and select it.
Or I can create a link, copy it, and then I can go to settings and change the link permissions. So I can say anyone on my team has access to this, or anyone with a link. That's an anonymous link if I want to share it with anyone outside of my org. Or I can narrow it down to people with a password. So only people with the password that I set here are going to be able to access this file via this link, or I can change it to only people invited. So that was the previous window there when we invite people to see it. They're the only people that can see it within my org.
I can also add an expiration date. So only people invited can see this until the end of a month from now, according to this. And then I can also say, hey, who needs to maybe view this, make comments on it but not necessarily edit or download it? I can disable downloads also. When I create that link, I can simply copy it and then send it to anyone I see fit after this. So, you know, email, Slack, whatever it is, I can send that link directly, and those permissions are going to be inherent.
One of the files that I am syncing needs to be writable by another user (different UID on the same machine, not referring to another dropbox user) besides myself. To be more specific, this other UID is actually a daemon. So, either the file needs to be owned by that other user, or else write permission is needed for "group" and/or "other". Initially I have set it up this way on both machines. In addition, the directory containing the file is already owned (chmod 777) by the user that needs to have write access to the file.
However, whenever the file gets synced from one box to another, it appears that Dropbox completely ignores both sets of permissions, and changes the permissions on the newly updated file to be owned by me with permissions 0644 (rw for me, r for everyone else). If the file isn't owned by me it even changes ownership back to myself! As a result, the other user no longer has write permissions until I manually go in and re-chmod the file.
It appears that all new files are first created under the /Dropbox/.dropbox.cache directory, so the above commands gives those new files the proper ownership and permissions that new files created by Dropbox has the correct group.
If you copy a file between two computers, the software that does the copying decides what the permissions are on the copy. For what you're doing, you need some fairly fine-grained permission mapping. Dropbox permission-mapping features are limited to preserving permissions if both systems run the same OS. No specific results are guaranteed for copying between two different OSs.
Anyway, I've read that the only way to change the permission to an app is by creating a new one. Therefore, what I did was, created a new app with permission type 'Full dropbox' but for some reason it didn't even show up under 'Dropbox > Apps' directory.
With this restriction, the ability to create a "Financials" subfolder with restricted permission to managment is not possible. Dropbox's recommendation to move a folder to higher level of the team folder doesn't work quite well either (if the entire team still has access to the "TEAM" folder). And creating another shared folder increases the "mess and confusion" (referred to here) at the root folder level of participants and becomes unmanageable from a folder management perspective when there are people who may have access to multiple teams (or even the ton of distinctly shared folders from other dropbox users.
I have to agree with everything that was said in this post. I too just now bought the business subscription for the granular permissions, and discovered that these are waterfall permissions. I dont know why this is such a problem, given it is standard in any linux, unix system with a chmod. Also this is standard in github.
I'm sure in the past the Dropbox link was public 'Anyone with link'. Just noticed today the link rclone is creating has private / 'Team members' permissions. Only very occasionally someone from outside out organisation (Dropbox Team) needs to view the files, looking at old links suggests this has been the case for a long time.
When working with the Dropbox APIs, your app will access Dropbox on behalf of your users. You'll need to have each user of your app sign into dropbox.com to grant your app permission to access their data on Dropbox.
Always ask for the least amount permissions required by your applications. Requesting more scope and content access than required may result in end users not accepting your OAuth request and could impact your app review process.
Before you can get started, you'll need to register your app with Dropbox by creating a new app in the App Console. That page will guide you through the process of registering your app, selecting permissions, and obtaining an app key and secret (a.k.a. client_id and client_secret) and inputting redirect URIs.
We recently launched several permissions enhancements. You can read about them in the OAuth Guide or in the blog post, Now Available: Scoped Apps and Enhanced Permissions. The major changes to be aware of are the introduction of short-lived tokens, scopes, PKCE, and refresh tokens. For now, our App Console supports both legacy and scoped app creation, but may be turned off soon as we prepare to retire long-lived tokens on September 30th, 2021. This means that:
Can anyone work out what I need to change to get Dropbox to create files with group permission "rw"? I am pretty sure that it has to be the Dropbox process that has the wrong permissions but I can't work out how or what to change. Thanks.
After spending a day tyring to work this out I realised that I needed to use setfacl at the Dropbox folder level rather than for some sub folders for this to work. It seems that when users creates files then the correct file permissions are set, but when Dropbox created file in the same folder the permissions were not correctly set. The command that I used was something like this:
I am getting the permissions error in Dropbox after I upgraded to Monterey. However, I can't get Dropbox to come up in the Full Disk Access or Accessibility panels at all. I click on the + at the bottom, select dropbox and... nothing.
HI! I appreciate the link, but that workaround doesn't address the problem I'm having. I can't even get the program to open at all because it says there are permissions errors. Evidently this has been a fairly common problem, and the workarounds I've read involve checking Dropbox in the Full Disk Access and Accessibility system panels. However, I can't seem to get Dropbox to even show up on the FDA and Accessibility panels. I unlock the panel, click the plus, point it at the Dropbox app and.... nothing. So I'm still stuck with an application that suddenly won't load at all in Monterey.
If this solves the matter, it proves this is a permission problem. Therefore, you should restore the UAC settings and turn to change the permission of the files, like ACL (access control list) or deeper permissions issues inside your home folder.
Within a Dropbox Team Folder, a subfolder can appear as having "Limited" permissions under the "Who can access" column. "Limited" means that the subfolder isn't shared with everyone who has access to the parent-level Team Folder. (For example, when someone shares a subfolder within a Team Folder, they will receive a message at the top of the sharing dialog box that states, "This folder isn't shared with everyone who has access to parent folder [Team Folder name]. Share with everyone.")
Alternative Method to reduce required Dropbox permissions
You can choose to use the "Files" method to add your Dropbox database. This works well, and does not require giving Strongbox access to your Dropbox. Just:
Every migration is unique, and it can be tricky to move data between differing systems. Box Shuttle acts as an intermediary between various content management systems, allowing you to transfer folders, files, permissions, and metadata from these platforms to Box.
Running an Analysis job helps you understand your source data at a more comprehensive level. The analysis report includes information on data type, size, age, and permissions.
As a result, it is easier to divide a large and complex job into smaller manageable pieces to plan which departments or sections to migrate first, as well as to come up with a reasonable approach to migrate your users and their data. This way, large projects can finish quicker, cost-effectively, with fewer conflicts, and more efficient delta runs.
The following instructions allow you to migrate your data to a single location on the target without applying permissions. If you want to migrate data and permissions, see Data migration including permissions.
If you run a data-only job, you must manually add permissions to the data once it lands in Box. This action restores previously available access in Dropbox. Consider migrating permissions and data together. See Data migration including permissions for instructions.
This type of data migration transfers not only files and folders, but also ownership rights and permissions from one location to another. This type migration job is suitable for comprehensive management of files, accounts, and privileges throughout the entire data migration process.
Account mapping is used for associating a source user account with a target user account. Matching accounts simplifies transferring multiple user files and folders without users losing access to the content. This is an essential component to migrating permissions.
dafc88bca6