New installation of the desktop app on Fedora remains on Starting...

Jrocchio

Application Affected

Dropbox deamon for Linux

System
Operating System: Fedora Linux 43

KDE Plasma Version: 6.5.5

KDE Frameworks Version: 6.22.0

Qt Version: 6.10.1

Kernel Version: 6.18.7-200.fc43.x86_64 (64-bit)

Graphics Platform: Wayland

Processors: 24 × AMD Ryzen AI 9 HX 370 w/ Radeon 890M

Memory: 32 GiB of RAM (30.6 GiB usable)

Graphics Processor: AMD Radeon 890M Graphics

Manufacturer: Framework

Product Name: Laptop 16 (AMD Ryzen AI 300 Series)

System Version: A9

Dropbox App Version
dropbox-lnx.x86_64-241.4.4795

Issue

Fresh install of dropbox on a new laptop running fedora 43 linux. It is "stuck" on "Starting..." I can't figure it out. Need help. If it matters I've been running dropbox on Linux for about a decade and have never experienced this issue. It is currently running just fine on my desktop PC, which is running fedora 42 Linux.

I installed drop using the instructions on the dropbox site, using the Fedora 64 bit RPM. That was fine, and the usual files are installed in the places I usually see them. The deamon even properly set itself up to auto start - so when I reboot it starts up and puts itself in the tray (see screenshot).

When I reboot it does ask me to sign in - bringing up the web browser, which asks me to 'Connect' my existing account. Which I do in the web browser. I get no complaints or errors. But it doesn't seem to have any effect on the deamon. 

When I look at the linked devices in my dropbox account the new laptop is listed there. So dropbox has made the association somewhere in it's databases.

I have looked around in the linux firewall settings, but don't see anything relevant there. But then again I'm no expert in that regard.

Permissions on the disks/files are under my user/group. I am the only user account on this system. 

I am not seeing any network issues on the system - all other network-using apps are running as expected.

If anyone has ideas -- I'm all ears! 

 

 

Jrocchio

I did contact the official Dropbox support team. That, in itself, was a challenge. Apparently you have to convince the chat-bot that the issue is beyond it's capabilities; then a human will come on and if they can't solve they will then, finally, open a ticket; which she did. It's been esclated up two levels now and so far I've heard nothing back. BUT...

I did figure it out this morning. Ya-all are going to smirk at me, rightly so. Let me start by stating what my intentions were, which will help to make sense of it.

Intention: I have two SSDs installed in the laptop. My intention was to use one for the OS and all the apps. Then dedicate the 2nd SSD to being only a replica of my Dropbox. This way I could futz around with the OS, mess it up, then reformat and reinstall the OS and apps without having to resync my whole Dropbox across the network each time.

The Error: I created a mount point for the Dropbox folder under my home directory. And I named it “Dropbox.” In my naïveté I assumed that Dropbox you would see this and do it’s thing. To make a long story short: Well, it did see it, but it couldn’t gain access to it. Instead of telling the user this key fact it just hung there, forever, waiting to be granted access. No message to the user. No attempt to create an alternative directory for itself. Not even any entries in the journal. This last one, no journal entries, I do find to be a pretty perplexing oversight on the part of your developers (even tho at base it was my error).

The Solution: I moved the mount point for the SSD into the /media directory (as /media/SSD-dropbox-local). Dropbox then fired up and started syncing. I used it’s ‘Preferences…’ to move the sync location to the mounted SSD in /media. Then I added the Dropbox folder at /media/SSD-dropbox-local to my ‘places’ list in Dolphin.

Alls well that ends well.