nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dropbox desktop client failing with 'PermissionError: [WinError -2147024891] Access is denied'

jperkins

We have a user in our department who is getting an error trying to run the Dropbox client on his Windows 11 device; the client was installed through the Windows Store. This error only happens for this particular user; when I login on this computer it works fine.

There is no sign of antivirus/threat detection finding any incidents on this device. That seems to be a popular response when others have reported this issue. Also odd antivirus would be cause when another user can use the product on the same device.

I have verified the user's account does have access to the zip archive where boot_error.pyc resides, and the user has full access to the Temp directory referenced in the crash trace. It's not clear to me from this crash trace which file is reporting the "access denied" condition.

Crash trace is listed below:

bn.BUILD_KEY: Dropbox
bn.VERSION: 266.4.3911
bn.constants.WINDOWS_SHELL_EXT_VERSION: 96
bn.is_frozen: True
machine_id: 409ff623-ff4f-4efc-98d2-7f47e674b738
pid: 20432
cwd: 'C:\Program Files (x86)\Microsoft\Edge\Application\152.0.4191.62'
real_path='C:\Program Files (x86)\Microsoft\Edge\Application\152.0.4191.62'
mode=0o40777 uid=0 gid=0
parent mode=0o40777 uid=0 gid=0
HOME: None
appdata: 'C:\Users\user\AppData\Local\Dropbox\instance5'
real_path='C:\Users\user\AppData\Local\Dropbox\instance5'
mode=0o40777 uid=0 gid=0
parent mode=0o40777 uid=0 gid=0
dropbox_path: None
not found
parent not found
sys_executable: 'C:\Program Files\WindowsApps\DropboxInc.Dropbox_266.4.3911.0_x64__xbfy0k16fey96\Dropbox.exe'
real_path='C:\Program Files\WindowsApps\DropboxInc.Dropbox_266.4.3911.0_x64__xbfy0k16fey96\Dropbox.exe'
mode=0o100777 uid=0 gid=0
parent mode=0o40777 uid=0 gid=0
trace.file: 'C:\Program Files\WindowsApps\DropboxInc.Dropbox_266.4.3911.0_x64__xbfy0k16fey96\266.4.3911\python-pypkg.zip\dropbox\client\ui\common\boot_error.pyc'
real_path='C:\Program Files\WindowsApps\DropboxInc.Dropbox_266.4.3911.0_x64__xbfy0k16fey96\266.4.3911\python-pypkg.zip\dropbox\client\ui\common\boot_error.pyc'
not found
parent not found
TMP: C:\Users\user_short\AppData\Local\Temp
TEMP: C:\Users\user_short\AppData\Local\Temp
tempdir: 'C:\Users\user_short\AppData\Local\Temp'
real_path='C:\Users\user\AppData\Local\Temp'
mode=0o40777 uid=0 gid=0
parent mode=0o40777 uid=0 gid=0
Traceback (most recent call last):
File "desktop/dropbox/client/main.py", line 7390, in _setup_root_for_account
File "desktop/dropbox/sync_root/helpers.py", line 204, in create_root_for_account
File "desktop/dropbox/foundation/futures/basic.py", line 1040, in result
File "desktop/dropbox/sync_root/manager.py", line 385, in create_root
File "desktop/dropbox/sync_root/handlers/windows/cloud_files.py", line 322, in register
File "desktop/dropbox/sync_root/handlers/windows/cloud_files.py", line 721, in _register
PermissionError: [WinError -2147024891] Access is denied

Find more posts tagged with

Desktop

Error Messages

Windows

Accepted answers

All comments

Hannah

Thanks for bringing this to our attention, @jperkins.

Is this user on a paid Dropbox plan or on the free Basic version?

If the latter, is it possible that they have 3 devices linked to their account already and are trying to link this computer as the fourth one?

If the user is on a paid plan that has no device limit, can you please ask them to follow these steps and let me know if they help?

Thanks!

Здравко

Hi @jperkins,

When you say:

… This error only happens for this particular user; when I login on this computer it works fine.

Had you move or rename the Dropbox folder (like the particular user has done)? 🤔 Rhetoric of course. 🙂 That's why you can use Dropbox application while at the same time the other user cannot do the same on the same machine. Dropbox folder should never be moved/renamed "by hands"; the only way to do so (without damage application work) is throughout Dropbox preferences.

This may be fixed with returning the Dropbox folder in the same place/state as has been during last successful application work. After that the affected user may move the Dropbox folder to the desired place in the correct way. 😉

All error messages report the same - "Permission error". It Doesn't matter whether there is real permission issue or not (the same like in your case is no any permission issue). 🤷 This is long residing problem that neither Dropbox development nor Dropbox support take any care about (as you saw already). Don't try reinstall (especially advanced reinstall) since you'll likely end up with second Dropbox folder - one existing now and moved already and second that will come up on the default place if you don't set something else.

Good luck.

jperkins

Our user is on a paid Dropbox plan, so we should not be bumping up against the 3-device limit.

We have attempted to reinstall the Dropbox client, although we did not go through cleaning out registry keys and AppData Dropbox folders (is there some reason your installer doesn't do this during the uninstall operation??). I can report back if that makes a difference.

jperkins

There was no change to the Dropbox folder. This device did go through a domain migration moving from one set of domain controllers to another and a username change…but the profile location remained the same as part of that migration. The profile directory is still C:\users\old_user_name with Dropbox folder at C:\users\old_user_name\Dropbox even though the user's name has changed from old_user_name to new_user_name.

One thing we are looking into is setting up a brand new user profile. This would reset user profile into C:\Users\new_user_name instead. If Dropbox is looking for C:\Users\%username% for its Dropbox location rather than using a predefined %appdata% location, that might explain the behavior we are seeing. This wouldn't be particularly good behavior for an application to implement, but based on your comments about when "Permission error" messages appear, it might not be out of the realm of possibility.

Здравко

@jperkins, if the used name is the same and the drive letter too, then all should work, but as it seems that's not the case. In this context your statement "If Dropbox is looking for C:\Users\%username% for its Dropbox location rather than using a predefined %appdata% location, that might explain the behavior we are seeing" sounds strange; it contradicts to what you sad just before it! ALL paths that Dropbox application keeps in its settings are ABSOLUTE! (bug) Since the application cannot find out its folder, the folder is definitely moved or some of the intermediate folders in the path has renamed (including possibly resulted from changed username or similar). Also keep in mind that even when you keep the old path of the Dropbox folder itself, the issue may persists because of path to the settings files are absolute too and most probably they are moved to the new profile context that will definitely result in such a behaviour.

Next time when you do such a move, first unlink the application from your (or affected user accordingly) account and link it back at the end. In such a way the changed paths will come correctly up to the settings during next link to the account.

Здравко

Take a look here for possible solution/workaround.

jperkins

We opted to give the user a new user profile rather than removing %localappdata%\Dropbox and restart. The permission denied errors are no longer happening. This user didn't have a lot of customizations on his desktop or in applications he was using, so it wasn't as much of a problem to go with a completely new user profile directory.

Hannah

Thanks for updating the thread about the issue and what resolved it, @jperkins.

I'm glad to see that this user is no longer getting the permissions error on their desktop app.

If they or you come across any other issues, please don't hesitate to let us know.

Have a great weekend!