Your workflow is unique 👨💻 - tell us how you use Dropbox here.
Can't log in to the desktop app on Windows11 with an "access is denied" error
Application Affected Dropbox Device Lenovo laptop Operating System/Browser (if using the web) Windows 11 Dropbox App Version (if using the app) Dropbox 242.4.5815 Offline Installer.x64.exe Question or Issue i couldn't login into dropb and i got the follwing error: bn.BUILD_KEY: Dropbox bn.VERSION: 241.4.4853 bn.constants.WINDOWS_SHELL_EXT_VERSION: 89 bn.is_frozen: True machine_id: cdafbbac-4a5d-44c0-9bea-a72c1c8c8234 pid: 6080 cwd: 'C:\\WINDOWS\\system32' real_path='C:\\Windows\\System32' mode=0o40777 uid=0 gid=0 parent mode=0o40777 uid=0 gid=0 HOME: None appdata: 'C:\\Users\\amir.dar\\AppData\\Local\\Dropbox\\instance6' real_path='C:\\Users\\amir.dar\\AppData\\Local\\Packages\\DropboxInc.Dropbox_xbfy0k16fey96\\LocalCache\\Local\\Dropbox\\instance6' 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_241.4.4853.0_x64__xbfy0k16fey96\\Dropbox.exe' real_path='C:\\Program Files\\WindowsApps\\DropboxInc.Dropbox_241.4.4853.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_241.4.4853.0_x64__xbfy0k16fey96\\241.4.4853\\python-packages.zip\\dropbox\\client\\ui\\common\\boot_error.pyc' real_path='C:\\Program Files\\WindowsApps\\DropboxInc.Dropbox_241.4.4853.0_x64__xbfy0k16fey96\\241.4.4853\\python-packages.zip\\dropbox\\client\\ui\\common\\boot_error.pyc' not found parent not found TMP: C:\Users\amir.dar\AppData\Local\Temp TEMP: C:\Users\amir.dar\AppData\Local\Temp tempdir: 'C:\\Users\\amir.dar\\AppData\\Local\\Temp' real_path='C:\\Users\\amir.dar\\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 6945, in _setup_root_for_account File "desktop/dropbox/sync_root/helpers.py", line 199, in create_root_for_account File "desktop/dropbox/foundation/futures/basic.py", line 1040, in result File "desktop/dropbox/sync_root/manager.py", line 382, in create_root File "desktop/dropbox/sync_root/handlers/windows/cloud_files.py", line 299, in register File "desktop/dropbox/sync_root/handlers/windows/cloud_files.py", line 601, in _register PermissionError: [WinError -2147024891] Access is denied So, i've uninstalled the app and deleted the registery key (used chatgpt for those steps) now, i can't reintall the app
The app seems to be crashing on macOS Tahoe 26.4 (Beta 1)
Application Affected Dropbox Device mac studio Operating System/Browser (if using the web) macOS 26.4 Beta 1 Dropbox App Version (if using the app) 241.4.4853 Question or Issue Dropbox is crashing since I installed macOS Tahoe 26.4 (Beta 1) this morning. The errormessage is: DYLD_LIBRARY_PATH: None cwd: '/' real_path='/' mode=0o40755 uid=0 gid=0 parent mode=0o40755 uid=0 gid=0 HOME: '/Users/sander' appdata: '/Users/sander/.dropbox/instance3' real_path='/Users/sander/.dropbox/instance3' mode=0o40700 uid=501 gid=20 parent mode=0o40755 uid=501 gid=20 dropbox_path: '/Volumes/Data/.CloudStorage/Data/Dropbox' real_path='/Volumes/Data/.CloudStorage/Data/Dropbox' mode=0o40700 uid=501 gid=20 parent mode=0o40755 uid=501 gid=20 sys_executable: '/Applications/Dropbox.app/Contents/MacOS/Dropbox' real_path='/Applications/Dropbox.app/Contents/MacOS/Dropbox' mode=0o100755 uid=501 gid=20 parent mode=0o40755 uid=501 gid=20 trace.__file__: '/Applications/Dropbox.app/Contents/Resources/python-packages.zip/dropbox/client/ui/common/boot_error.pyc' real_path='/Applications/Dropbox.app/Contents/Resources/python-packages.zip/dropbox/client/ui/common/boot_error.pyc' not found parent not found tempdir: '/var/folders/v5/1fn_t3055sd904vr0bg75ts40000gn/T' real_path='/private/var/folders/v5/1fn_t3055sd904vr0bg75ts40000gn/T' mode=0o40700 uid=501 gid=20 parent mode=0o40755 uid=501 gid=20 Traceback (most recent call last): File "desktop/dropbox/fs_api/lifecycle.py", line 238, in client File "desktop/dropbox/fs_api/lifecycle.py", line 297, in _create_thin_client File "desktop/dropbox/fs_api/fs_api_adapter.py", line 54, in __init__ File "desktop/extensions/fs_api/fs_api_python.pyx", line 63, in fs_api_python.FsApiServer.__cinit__ fs_api_python.FsApiError: "Initializing fs api |>> Initializing platform |>> Opening worker root directory |>> open syscall |>> FSErrorCode::PermissionDenied" The above exception was the direct cause of the following exception: Traceback (most recent call last): File "desktop/dropbox/client/main.py", line 1106, in wrapper File "desktop/dropbox/client/main.py", line 8849, in finish_dropbox_boot File "desktop/dropbox/client/message_queue.py", line 338, in _wrapped File "desktop/dropbox/client/main.py", line 8130, in _init_components_for_account File "desktop/dropbox/client/main.py", line 8038, in create_sync_engine File "desktop/dropbox/sync_engine_boundary/factory.py", line 237, in make_sync_engine File "desktop/dropbox/sync_engine/nucleus/classic_client/sync_engine.py", line 264, in __init__ File "desktop/dropbox/sync_engine/nucleus/classic_client/modern_client/modern_client.py", line 330, in __init__ File "desktop/dropbox/sync_engine/nucleus/classic_client/modern_client/base.py", line 260, in __init__ File "../mac_arm64_dropbox_virtual_env/lib/python3.8/functools.py", line 967, in __get__ File "desktop/dropbox/fs_api/lifecycle.py", line 267, in client dropbox.fs_api.lifecycle.FsApiClientCreationException: "Initializing fs api |>> Initializing platform |>> Opening worker root directory |>> open syscall |>> FSErrorCode::PermissionDenied""Your device couldn't connect to the server" error on the desktop app
Device iMac 2024 Operating System/Browser (if using the web) Tahoe 26.2 Dropbox App Version (if using the app) v241.4.4853 Syncing Status "Up to date" Question or Issue I recently set up my existing company Dropbox account on my new iMac. All the folders/files appeared to sync fine and I can open individual ones with no issues. However, if I right click on anything and selected "Make available offline" from the Dropbox actions I get an error message stating the following: "Your device couldn't connect to the server. There may be a problem with the server or network." I'm regularly accessing individual files from the team account with no issues by just double-clicking them to open, but when I try to download a whole folder, this is what I get every time. I do not have a VPN set up, I have not installed any security software, my date/time are correct, and I'm definitely connected to the internet. I've tried logging out and back in, restarting, shutting down/restarting the iMac, stopping and restarting sync, and deleting the Dropbox application entirely and reinstalling. (I'm currently on my second attempt of that process.) Any suggestions? I'm completely at a loss here.
macOS 26.3 (M4) Dropbox v243.3.6895: CxSupportTool window loop + Chromium 102 renderer abort
Application Affected: Dropbox Desktop (macOS) Device: MacBook Pro M4 Max, 36GB RAM Operating System: macOS 26.3 Tahoe (Apple Silicon) Dropbox App Version: 243.3.6895 (Electron 19.1.9-dropbox.50 / Chromium 102) Subscription: Dropbox Pro Question / Issue Two distinct bugs prevent normal use of the Dropbox desktop client: CxSupportTool diagnostic window launches automatically every 2-12 seconds whenever any Dropbox UI is opened (Settings, tray popup), displaying raw sync engine debug output to the end user. This makes the Settings UI unusable and predates macOS Tahoe. Renderer processes abort on macOS 26 due to a FATAL:logging.cc failure in Chromium 102, causing IPC errors and renderer death. This is macOS 26-specific. Bug 1: CxSupportTool Diagnostic Overlay Reproduction Steps Launch Dropbox normally Click the Dropbox menu bar icon Open Settings/Preferences (or interact with the tray UI) Wait 2-12 seconds A 960x540 window titled "CX Support Tool" appears, showing raw sync engine diagnostics: PhaseInformation, SyncStatus, EngineWaitTracker, PendingSetTracker Pending set count (600-900+ items), capped: true Closing the window does not help - it reappears within seconds The cycle repeats indefinitely, making Settings navigation impossible Observed Behavior The diagnostic window is not a crash dialog - the main process and renderer processes remain alive. The window is a fully rendered BrowserWindow ( cxSupportToolView ) spawned by the Dropbox "journey" system. It displays the output of fetchEngineDebugInfo() , which is internal sync engine state not meant for end users. The issue persists across: Multiple macOS versions (predates Tahoe) Clean reinstalls of Dropbox Clearing all local caches and crash data Root Cause Analysis I extracted and analyzed app.asar and traced the trigger chain: SyncErrorServiceImpl detects sync errors → fetchEngineDebugInfo() IPC call → CxSupportToolController.launchJourney() (module 898 in main.js) → spawnViewWithServices() creates BrowserWindow (960×540) → cxSupportToolView renders engine debug info CxSupportToolController (in main.js module 898) extends BaseUserJourneyController and is registered as: registerUserJourney( UserJourneyType.CX_SUPPORT_TOOL_FLOW, { singleton: true, controllerClass: CxSupportToolController } ) The journey is launched by SyncErrorServiceImpl when the sync engine's pending set enters a "capped" state. Telemetry is tagged under DesktopComponent.SYNC_ERRORS . Why the sync engine is capped: The user's Dropbox folder contains software development projects with node_modules , .git , and __pycache__ directories totaling approximately 965,000 files. These small, numerous files overwhelm the sync engine's pending set tracker, causing it to cap (a circuit-breaker mechanism). The capped state is then interpreted by SyncErrorServiceImpl as a sync error, which repeatedly launches the diagnostic journey. Storing development projects in cloud-sync folders is common. The sync engine should handle large file counts without surfacing internal diagnostics to users. Workaround Applied Set com.dropbox.ignored extended attribute on node_modules (17 dirs), .git (44 dirs), and __pycache__ (86 dirs) to exclude them from sync Patched app.asar to replace CxSupportToolController.launchJourney method body with return{result:0} (same byte length to preserve asar offsets), preventing the diagnostic window from spawning The asar patch is temporary - the auto-updater will overwrite it. Suggested Fixes Do not show raw engine debug info to end users. The CxSupportToolView displays PhaseInformation , SyncStatus , EngineWaitTracker , and PendingSetTracker output - this is engineering diagnostic data with no actionable information for customers. Add rate limiting or debounce to CxSupportToolController.launchJourney() . Currently, when SyncErrorServiceImpl detects a capped pending set, it can launch the journey repeatedly (every 2-12 seconds). Even if the diagnostic window is appropriate in some contexts, it should not spawn in an unbounded loop. Don't treat a capped pending set as a user-facing sync error. A large number of pending files is a normal condition for users with many small files (developers, photographers, etc.). The sync engine's circuit breaker should not trigger a customer-facing diagnostic journey - it should log internally and continue processing. Auto-ignore common regenerable directories. Directories like node_modules , .git , __pycache__ , venv , and build are well-known to be regenerable and contain large numbers of small files. These could be suggested for exclusion or ignored by default when detected, similar to how .gitignore patterns work. Bug 2: Chromium 102 Renderer FATAL Abort on macOS 26 Reproduction Steps Run Dropbox on macOS 26.3 Tahoe Observe stderr output (launch with ELECTRON_ENABLE_LOGGING=1 ) Renderer processes emit: FATAL:logging.cc(144) Failed to init logging: Operation not permitted Renderers abort immediately Main process logs: Error: Render frame was disposed before WebFrameMain could be accessed Root Cause Chromium 102 (used by Electron 19.1.9-dropbox.50) attempts to initialize file-based logging inside the renderer sandbox. macOS 26 tightened sandbox permissions, causing the logging.cc initialization fails with 'Operation not permitted'. Chromium treats this as a FATAL error, which calls abort() and kills the renderer process. The Electron project tracks similar issues with older Chromium on newer macOS (e.g., electron/electron#48311). Workaround Setting CHROME_LOG_FILE=/dev/null before launching Dropbox prevents the FATAL abort: CHROME_LOG_FILE=/dev/null /Applications/Dropbox.app/Contents/MacOS/Dropbox This sidesteps the permission failure by redirecting Chromium's log file. Suggested Fix Upgrade the Electron/Chromium runtime. Electron 19 (Chromium 102) is from June 2022 and EOL. Newer Chromium handles macOS sandbox changes fine. At the very least, logging.cc init should handle permission failures instead of calling abort() . Environment Details Component Value Dropbox version 243.3.6895 Electron 19.1.9-dropbox.50 Chromium 102 macOS 26.3 Tahoe Hardware MacBook Pro M4 Max, 36GB RAM Sync folder ~/Library/CloudStorage/Dropbox.nosync (~82 GB) Sync folder file count ~965,000 files (including node_modules/.git) Pending items at time of issue 600-900+, capped: true Diagnostic Artifacts I collected the following during the investigation and can provide any of it on request: Stderr logs from multiple launch configurations ( ELECTRON_ENABLE_LOGGING=1 , CHROME_LOG_FILE=/dev/null ) Extracted and annotated sections of main.js (module 898 - CxSupportToolController ) Extracted cxSupportToolView renderer and preload scripts apex.sqlite3 Stormcrow configuration (feature flag state) Screenshots of the CxSupportTool diagnostic window Process traces showing the renderer FATAL abort sequence Approaches That Did Not Resolve the Issue Approach Result Clean reinstall of Dropbox The CxSupportTool issue persisted Clearing GPU cache, Electron caches, and saved window state No effect ELECTRON_DISABLE_GPU=1 environment variable Delayed diagnostic window, but it didn't prevent it --disable-gpu , --disable-gpu-compositing CLI flags Crashed the entire application --no-sandbox CLI flag Crashed the entire application Clearing the Crashpad crash dump directory No effect --remote-debugging-port=9222 Dropbox strips the flag; no remote debug access Deleting Stormcrow feature flag database ( apex.sqlite3 ) No effect - rebuilt on next launch Deleting 59 conflicted copies from the sync folder Pending count actually increased temporarily Feel free to get in touch for any additional details or inquiries. Best regards, Ryan [personal information removed per the Community's Guidelines]
Updating to File Provider API has made my Mac unusable
Hi all, I'm joining the "File Provider API broke my computer" dance and sure wish I had read more in this forum before attempting to update. Dropbox had consistently been using 600-800MB RAM even when idle, so I was hoping the update would fix the issue (it did not). The update initially ran smoothly, and I left the computer to index and the files to repopulate overnight. The next morning, after indexing, I restarted my computer, upon which Dropbox would hang on the “Connecting components” message during startup. All files in the newly-constructed Dropbox folder in the user CloudStorage library appeared correctly (all there and showing the correct amount of storage used), but none of the files could be opened (double-clicking or right click+open yielded no result). Even worse, when attempting to relaunch finder to resolve the issue, my computer would freeze until a forced reboot. This rendered my computer totally unusable, so I booted in safe mode, disabled Dropbox on startup, and followed these instructions to revert to the pre-updated dropbox library structure, including a clean reinstall: https://help.dropbox.com/installs/dropbox-for-macos-support . The folders repopulated correctly and I can open and save files in the original [User]-dropbox library, but now I am facing several other peculiar and crippling issues: 1) saving files works, but attempting to save-as or export-as any file located anywhere on the computer crashes whatever program is trying to execute the task (tested in preview, textedit, excel, and word so far) 2) Dropbox fails to launch about 50% of the time, hanging on “Starting…”. I can navigate through the desktop dropbox interface, but I am not logged in nor able to log in. The issue persists until the program is relaunched. 3) when I select the option to delete the now-unconnected dropbox folder under [User]->Library->CloudStorage->Dropbox and confirm my selection, nothing happens. 4) The finder interface no longer shows any Dropbox options when right clicking on a file that’s stored in dropbox. I tried to follow the these instructions to resolve the issue: https://www.dropboxforum.com/discussions/101001012/sync-icons-missing-in-the-dropbox-folder-in-finder/596014/replies/599554 . However, finder crashes whenever I attempt to relaunch in. After restarting the computer with Finder Extension privileges rechecked, the buttons do not appear. I am running my laptop on OS Ventura 13.7.8 (22H730) on a 2017 Intel MacBook Air and using dropbox version 241.4.4853 on a plus account. Dropbox is using 350-400MB of RAM whenever it is open, regardless of login or sync status. fileproviderd is operating at 50-100% CPU usage regardless of whether Dropbox is open. Files appear to sync correctly when Dropbox launches successfully, and files that I remember are saved online-only (because I can’t see this when right-clicking on them) redownload correctly when opened. Any other troubleshooting to try? I've obviously spent far too long on this already, and I'm not hopeful that the issue can be fixed. I'll leave the computer on to think overnight and hopefully rebuild whatever libraries are causing this issues, but otherwise I'm mostly hopeful that I will be able to uninstall Dropbox far enough that my laptop works again. I understand the API quagmire is partially Apple's fault, but dropbox has had multiple years to address these issues and appear to be having the same issues as at the initial launch.
I'm trying to add Dropbox as a location in Files app, but it says syncing is paused.
I cannot use dropbox as a location to select files from on iphone ios 26.2.1 I have restarted, installed everything over and over. Removed preview app, and nothing. Application Affected dropbox on iphone Device iphone 17 pro ios 26.2.1 Operating System/Browser (if using the web) files iphone app Dropbox App Version (if using the app) 460.2.2 Question or Issue Need a solution
I'm getting a startup error for the desktop app on my Windows computer.
As the title suggests, upon opening Dropbox, I am prompted with this error: This occurs when Dropbox attempts to register the Windows Cloud Files filter during startup. I've uninstalled Dropbox, checked my firewall, everything. Nothing seems to have fixed it. Upon opening the error message: bn.BUILD_KEY: Dropbox bn.VERSION: 241.4.4795 bn.constants.WINDOWS_SHELL_EXT_VERSION: 89 bn.is_frozen: True machine_id: [Redacted] pid: [Redacted] cwd: 'C:\\Windows\\System32' real_path='C:\\Windows\\System32' mode=0o40777 uid=0 gid=0 parent mode=0o40777 uid=0 gid=0 HOME: None appdata: 'C:\\Users\\USERNAME\\AppData\\Local\\Dropbox\\instance4' real_path='C:\\Users\\USERNAME\\AppData\\Local\\Dropbox\\instance4' 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 (x86)\\Dropbox\\Client\\Dropbox.exe' real_path='C:\\Program Files (x86)\\Dropbox\\Client\\Dropbox.exe' mode=0o100777 uid=0 gid=0 parent mode=0o40777 uid=0 gid=0 trace.__file__: 'C:\\Program Files (x86)\\Dropbox\\Client\\241.4.4795\\python-packages.zip\\dropbox\\client\\ui\\common\\boot_error.pyc' real_path='C:\\Program Files (x86)\\Dropbox\\Client\\241.4.4795\\python-packages.zip\\dropbox\\client\\ui\\common\\boot_error.pyc' not found parent not found TMP: C:\Users\USERNAME\AppData\Local\Temp TEMP: C:\Users\USERNAME\AppData\Local\Temp tempdir: 'C:\\Users\\USERNAME\\AppData\\Local\\Temp' real_path='C:\\Users\\USERNAME\\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 6945, in _setup_root_for_account File "desktop/dropbox/sync_root/helpers.py", line 199, in create_root_for_account File "desktop/dropbox/foundation/futures/basic.py", line 1040, in result File "desktop/dropbox/sync_root/manager.py", line 382, in create_root File "desktop/dropbox/sync_root/handlers/windows/cloud_files.py", line 299, in register File "desktop/dropbox/sync_root/handlers/windows/cloud_files.py", line 601, in _register OSError: [WinError -2145452017] Do not attach the filter to the volume at this timeDropbox fails to install on my new Mac M4 running Tahoe.
I've tried multiple time to install dropbox using both the regular install and the offline install. I enter my password and then get this error (and if I drag the dmg to applications, I just get a shortcut to the installer). I reviewed this thread -- same problem, no solution. Any suggestions? Thank you!
