[Support] ken-ji - Dropbox

[Spazhead]

Hi, just installed and got all files sync and updated.  but can only modify files in the Dropbox root folder.  if i go into a directory (example dropbox\my files)  i can read the files but it won't let me modify or create any files.

any help is appreciated

thanks for the great docker!

 

Running inside Windows 10 VM

Dropbox share is set to "public' in SMB share

 

Edited October 13, 2020 by Spazhead

[Spazhead]

UPDATE: just ran 'Docker Safe New Perms" now i have access...

is this normal?

thanks

 

[ken-ji]

This Docker container will run stuff as the nobody user, hence the error message above regarding permissions. Docker Safe New Perms will work until new files get sync'd or updates are made.

I'm guessing, but are you accessing the Dropbox share in guest mode (ie its set to Public) while you have a user in Unraid that the Windows PC you have is set to use/match? (Windows Credentials in Settings)

If so, you probably want to blow away this container and the appdata/dropbox and Dropbox share/folders (ie really start over)

Then when you reinstall the container, before linking to your account, make sure that the user id to run as is set to the user id of your user (the one windows is using to connect to)

If you don't know your user id, just open a terminal to Unraid and run this

[email protected]:~# id username
uid=1000(username) gid=100(users) groups=100(users)

which is usually be 1000.

[Spazhead]

22 hours ago, ken-ji said:

This Docker container will run stuff as the nobody user, hence the error message above regarding permissions. Docker Safe New Perms will work until new files get sync'd or updates are made.

I'm guessing, but are you accessing the Dropbox share in guest mode (ie its set to Public) while you have a user in Unraid that the Windows PC you have is set to use/match? (Windows Credentials in Settings)

If so, you probably want to blow away this container and the appdata/dropbox and Dropbox share/folders (ie really start over)

Then when you reinstall the container, before linking to your account, make sure that the user id to run as is set to the user id of your user (the one windows is using to connect to)

If you don't know your user id, just open a terminal to Unraid and run this

[email protected]:~# id username
uid=1000(username) gid=100(users) groups=100(users)

which is usually be 1000.

ok will try that thanks

but what happens when i access dropbox from another PC with another different user name??

[ken-ji]

Because Dropbox is meant to be run and used by a single user, the container must create files as a single user and any access over Samba/NFS shares must result in the files being owned by the same user or some issues will occur (like being unable to update directories and files modified from other devices)
There is a setting you can apply (just not sure how it will mess things up further for you)
in Settings | Samba | SMB extras I added under the [global] section

force user = nobody
force group = users

this makes it so that all access to my files over Samba will be done as the nobody user (and the group users - but this is usually not important).

 

Enabling this will probably break any existing share that is Secure, Private or even Public ones - if the files and directories have been created with the existing users you may have defined. (Running either Fix Permissions tools on the affected shares should fix the issue though)

 

You can turn this on and make some tests on a existing share so you understand what it does though, as reversing it is fairly easy by just removing the lines.

 

I was suggesting that Unraid enable this out of the box, but there's no way AFAIK to do it and not cause issues with users who do not want to enable this.

 

[darthdeus]

On 7/2/2020 at 1:45 PM, cinereus said:

The thing is I'd already restarted the container a bunch of times. If it's not in the logs is there a way to see how long the daemon has been running? 

 

The only thing I can think of is since I last posted I also rebooted the whole machine so could it be that's whst fixed it? I'll have to check in again about this frozen sync though. 

 

On 7/31/2020 at 4:57 AM, Grsh said:

Hi there!

So happy to get the Docker container working but I just realised the sync is not ptogressing for me either. Looks a bit like I have the same problem as @cinereus 

 

I got the dropbox folder structure on the array and some files are there. But realised that not all files are synced. I left it for around 2 night but the sync status has not changed yet.

The console says its running and syncing but nothing is happening.

If I create new folders they do get synced with some files in it. For example .txt files are getting synced. Most image files as well. 

One problem are After Effect files (.aep) and Photoshop files (.psd)

 

So the sync seems to work but not for all files.

Any help would be appriciated!

Hi everyone, I think I have the same issue as Grsh and cinereus. I've had my dropbox running for about 2 weeks now, tried restarting it a bunch of times, restarting the whole array and unraid, but it's stuck at the same spot for at least a week.

 

sh-4.3# su - nobody -c 'dropbox.py status'
Syncing 59,219 files
Downloading 59,219 files...

Status says it is syncing, running `top` shows CPU activity, but nothing is changing. I've checked the share disk usage and it's been the same for at least a week as well.

 

Initially I thought this could be because I had a lot of files on Dropbox (around 350GB with maybe a million files), but I've since tried reducing it significantly, but it doesn't seem to affect this in any way.

 

What are my options? Should I somehow delete the container and the share and try re-syncing all over again? As far as I know I didn't make any config changes

 

Screenshot 2020-11-14 at 17.26.14

 

 

edit: If I wanted to delete the whole thing and start over, I just need to stop & delete the container, it's config folder, and the directory on the share, right?

Edited November 14, 2020 by darthdeus

[ken-ji]

12 hours ago, darthdeus said:

edit: If I wanted to delete the whole thing and start over, I just need to stop & delete the container, it's config folder, and the directory on the share, right?

Correct
This whole stopping to sync is something I haven't encountered and I have no Idea what's causing it.

I only have 3.5G in my Dropbox account and I've never seen it stop syncing. Losing the linked account data yes, but never the hanging on the sync.

[darthdeus]

So after deleting all of the config and data and re-installing the container I linked it again, started sync, everything ran well, until it got stuck very close to the point where it was stuck before (previously was at 59219 files left, and after reinstall it's at 59206). I guess I'll try syncing my whole Dropbox to another device, archive some of the contents and try to sync again.

 

I'm not really sure how to debug this, it seems to be doing something, but network traffic is sitting at around 20-50kB/s. 

[zbarisopen]

Hello,

 

My Dropbox is about 1.5TB and the amount of data actually synced is less than half that. Here are my settings and my logs 

 

I have had DB running in docker for more than 1 week and still the files have not fully synced. 

 

Questions 

 

1. How do I know if DB is actually active and syncing? 

2. How can I get my entire DB to sync? I set it to disk 5 which has 4tb, plenty of space for DB.

 

Any help is much appreciated!

 

 

 

 

ErrorWarningSystemArrayLogin

dropbox: locating interpreter
dropbox: logging to /tmp/dropbox-antifreeze-GKc7Xa
dropbox: initializing
dropbox: initializing python 3.7.9
dropbox: setting program path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/dropbox'
dropbox: setting python path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517:/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/python-packages.zip'
dropbox: python initialized
dropbox: running dropbox
dropbox: setting args
dropbox: enabling allocator metrics
dropbox: applying overrides
dropbox: running main script
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._constant_time.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._openssl.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._padding.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/apex._apex.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/psutil._psutil_linux.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/psutil._psutil_posix.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/tornado.speedups.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/wrapt._wrappers.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtWidgets.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtCore.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtGui.cpython-37m-x86_64-linux-gnu.so'
dropbox: locating interpreter
dropbox: logging to /tmp/dropbox-antifreeze-4ERutJ
dropbox: initializing
dropbox: initializing python 3.7.9
dropbox: setting program path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/dropbox'
dropbox: setting python path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517:/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/python-packages.zip'
dropbox: python initialized
dropbox: running dropbox
dropbox: setting args
dropbox: enabling allocator metrics
dropbox: applying overrides
dropbox: running main script
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._constant_time.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._openssl.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._padding.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/apex._apex.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/psutil._psutil_linux.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/psutil._psutil_posix.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/tornado.speedups.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/wrapt._wrappers.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtWidgets.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtCore.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtGui.cpython-37m-x86_64-linux-gnu.so'
usermod: no changes
dropbox: locating interpreter
dropbox: logging to /tmp/dropbox-antifreeze-r1nZx8
dropbox: initializing
dropbox: initializing python 3.7.9
dropbox: setting program path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/dropbox'
dropbox: setting python path '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517:/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/python-packages.zip'
dropbox: python initialized
dropbox: running dropbox
dropbox: setting args
dropbox: enabling allocator metrics
dropbox: applying overrides
dropbox: running main script
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._constant_time.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._openssl.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/cryptography.hazmat.bindings._padding.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/apex._apex.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/psutil._psutil_linux.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/psutil._psutil_posix.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/tornado.speedups.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/wrapt._wrappers.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtWidgets.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtCore.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-109.4.517/PyQt5.QtGui.cpython-37m-x86_64-linux-gnu.so'
usermod: no changes

[ken-ji]

I'm afraid I have no idea what's going on here. and as you can see from your logs, it contains nothing useful. Only the Dropbox devs probably know what's going on and I don't think they are going to be helpful at all . This headless client is something they are still supporting but they seem to be veering people away from it as its not too easy to find on the site anymore.

[theruck]

hi ken-ji thanks for the docker image.

could you please summarize

1. what needs to be done so that the synced dropbox data can be shared over SMB ?

2. what needs to be done to allow autostart after unraid restart or array restart?

Edited December 11, 2020 by theruck

[ken-ji]

@theruck

for #1, by default the Dropbox data is shared over SMB. the defaults assume you are using Unraid in the default public share mode

If this is not the case (you are using user accounts, set User and User ID to the appropriate user)

refer to this for more details

 

For #2. Just set the autostart button to on on the Dockers page

 

[Struck]

Hi I experienced a problem after starting my dropbox container yesteday, and it ran overnight.

This morning i saw a lot of writes comming from the container, and it has been going on for the whole night, just since i started the container. The writes are increasing every little time. Any idea what is is?

I can say that during this time, it seems that the dropbox container was not linked to my account, though i had set it up once before, working fine.

 

I attached an image from my grafana-telegraf setup showing the writes to my cache drive.

In this time interval there was no activity on my Dropbox account.

Explanations:

23:30 i manually turned on Dropbox container

11:20 i shutdown the Dropbox Container because i saw all the writes going on.

12:00 i restarted the container and linked it to my account.

After 12:00 i have not seen any unexpected behaviour from the Dropbox Container.

All of this is done on Unraid 6.9.1

Any idea what happend?, it causes about 500GB wear on my new NVME SSD in about 12 hours.

Edited March 16, 2021 by Struck

[Struck]

7 hours ago, Struck said:

Hi I experienced a problem after starting my dropbox container yesteday, and it ran overnight.

This morning i saw a lot of writes comming from the container, and it has been going on for the whole night, just since i started the container. The writes are increasing every little time. Any idea what is is?

I can say that during this time, it seems that the dropbox container was not linked to my account, though i had set it up once before, working fine.

 

I attached an image from my grafana-telegraf setup showing the writes to my cache drive.

In this time interval there was no activity on my Dropbox account.

Explanations:

23:30 i manually turned on Dropbox container

11:20 i shutdown the Dropbox Container because i saw all the writes going on.

12:00 i restarted the container and linked it to my account.

After 12:00 i have not seen any unexpected behaviour from the Dropbox Container.

All of this is done on Unraid 6.9.1

Any idea what happend?, it causes about 500GB wear on my new NVME SSD in about 12 hours.

After a reboot, this seems to be happening again. and again the container is unlinked from my dropbox account. 

It is likely because i am using a basic plan, and have 7 devices connected to it, (max 3 allowed) but that does not explain why this container has excessive writes when unlinked.

Idea: Some write amplification? log file or anything else?

[ken-ji]

I am not sure about writes, but while it is not connected, it will definitely be writing out the connect to an account message to the docker log for the container.

[editedweb]

I have recently been experiencing this error:

 

RUST PANICKING -- "couldn't deserialize, panicking: Io(Error { kind: UnexpectedEof, message: \"failed to fill whole buffer\" })" at "app/lib/apex/rust/analytics/src/queue.rs":332

 

This has been happening on two seperate4 machines. Any ideas what this error means? It kills dropbox, and a restart works for a while before subsequently having the same error.

 

Anything else I should be looking at?

 

I should also add, that this happened also with the 'dropbox by otherguy' package as well.

Edited July 20, 2021 by editedweb

[ken-ji]

5 hours ago, editedweb said:

I have recently been experiencing this error:

 

RUST PANICKING -- "couldn't deserialize, panicking: Io(Error { kind: UnexpectedEof, message: \"failed to fill whole buffer\" })" at "app/lib/apex/rust/analytics/src/queue.rs":332

 

This has been happening on two seperate4 machines. Any ideas what this error means? It kills dropbox, and a restart works for a while before subsequently having the same error.

 

Anything else I should be looking at?

 

I should also add, that this happened also with the 'dropbox by otherguy' package as well.

 

Its probably related to the current state of the official dropbox headless client

I'm building a new version of the package and having the client update to the latest to see what's going on.

 

[ken-ji]

@editedweb
I've built a new image with the latest client (though my account auto updates the client to the latest beta) and I've had it running for a while without any noticeable issues.

I have not seen the error message about Rust panic though.

Edited July 21, 2021 by ken-ji

[editedweb]

Ok. I'll keep a watch and see if I can see any other errors or clues as to what's happening.

 

Edit: As soon as I had posted this, I checked the status using the dropbox.py tool in the console, and got this:

 

sh-4.3# su nobody -c 'dropbox.py status'
Traceback (most recent call last):
  File "/usr/local/bin/dropbox.py", line 1612, in <module>
    ret = main(sys.argv)
  File "/usr/local/bin/dropbox.py", line 1601, in main
    result = commands[argv[i]](argv[i+1:])
  File "/usr/local/bin/dropbox.py", line 786, in newmeth
    return meth(*n, **kw)
  File "/usr/local/bin/dropbox.py", line 1263, in status
    console_print(line)
  File "/usr/local/bin/dropbox.py", line 135, in console_print
    f.write(st.encode(enc))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2022' in position 21: ordinal not in range(128)

 

I'm not sure if it is related or not.

 

Edited July 22, 2021 by editedweb

[ken-ji]

I can't replicate it so maybe you have filenames with non-latin characters?
the dropbox.py in this container still runs on python 2.7 which is known to have some issues with string encoding

 

But I think that shouldn't cause any issue as the dropbox.py script is for interacting with with the headless client.

[mortenmoulder]

I don't think I've ever used a more buggy application before. It constantly tells me to reauthenticate/allow access to Dropbox. Sometimes it says "Dropbox isn't running", when I know for a fact it ran perfectly fine just a couple of hours ago.

 

If I restart the container, it literally takes hours for it to be done with syncing, because I have a lot of data in my Dropbox.

 

And yes, I did set it up correctly, by selecting a share with the cache set to Only or No.

 

I know some of the blame is on Dropbox' side, but man.. I wish this worked perfectly without any issues what so ever.

[ken-ji]

On 8/9/2021 at 5:15 PM, mortenmoulder said:

I don't think I've ever used a more buggy application before. It constantly tells me to reauthenticate/allow access to Dropbox. Sometimes it says "Dropbox isn't running", when I know for a fact it ran perfectly fine just a couple of hours ago.

 

If I restart the container, it literally takes hours for it to be done with syncing, because I have a lot of data in my Dropbox.

 

And yes, I did set it up correctly, by selecting a share with the cache set to Only or No.

 

I know some of the blame is on Dropbox' side, but man.. I wish this worked perfectly without any issues what so ever.

Yeah, it seems the headless version is not getting as much love from the team.

 

Have you considered enabling LanSync (I think it is by default), and ensuring the container is on its own IP address (or using host networking). This should help it to sync very fast against your PC (if you have any)

 

However, mine will pickup right away except for some odd corner cases where rebooting Unraid will cause the container to think its on a new PC and require linking again.

I don't have a lot of data as I only have a free account, and have moved most of stuff to One Drive, being 1TB storage is part of the family package for Office, and shared files don't eat into your quota unless you make copies of the shared files. I'm still supporting this container, but am considering a different solution using rclone given my current use case..

 

Sorry I can't be much help.

[mortenmoulder]

7 hours ago, ken-ji said:

Yeah, it seems the headless version is not getting as much love from the team.

 

Have you considered enabling LanSync (I think it is by default), and ensuring the container is on its own IP address (or using host networking). This should help it to sync very fast against your PC (if you have any)

 

However, mine will pickup right away except for some odd corner cases where rebooting Unraid will cause the container to think its on a new PC and require linking again.

I don't have a lot of data as I only have a free account, and have moved most of stuff to One Drive, being 1TB storage is part of the family package for Office, and shared files don't eat into your quota unless you make copies of the shared files. I'm still supporting this container, but am considering a different solution using rclone given my current use case..

 

Sorry I can't be much help.

 

Thanks for the reply. I have not tried LanSync, but I might give that a shot. Should it get its own LAN IP via DHCP then? Because that would be interesting indeed. I have a 10 Gigabit link between my server and PC, so that should go quite fast.

 

Makes sense you've moved to OneDrive. I'm considering the same, except maybe using Mega. Dropbox is quite expensive, but their desktop app and mobile app just works flawlessly for me (auto upload literally 5 seconds after I've taken a 30 MB photo).

 

Thanks for the support on this!

[Tom Roskilly]

Hi Ken-ji

 

What is the usual time-period for folders to start appearing from Dropbox?

 

I've been up and running for 30 mins now and all I am getting in the console is "Starting...", when I run this:

 

sh-4.3# su - nobody -c 'dropbox.py status'
Starting...

 

The logs show:

dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/cryptography.hazmat.bindings._openssl.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/cryptography.hazmat.bindings._padding.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/apex._apex.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/PyQt5.QtWidgets.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/PyQt5.QtCore.cpython-38-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-126.4.4618/PyQt5.QtGui.cpython-38-x86_64-linux-gnu.so'

[ken-ji]

Hmm. should be instant, but running `dropbox.py status` should be returning `Syncing...` not `Starting...`
`Starting...` means the daemon is not running correctly...

 

Can you try restarting the container, then running `ps xafu` as the root user inside the container?

Mine returns this

bash-4.3# ps xafu
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       243  0.2  0.0  18012  3064 pts/0    Ss   05:49   0:00 bash
root       251  0.0  0.0  17684  2216 pts/0    R+   05:49   0:00  \_ ps xafu
root         1  0.0  0.0  17880  2840 ?        Ss   05:43   0:00 /bin/bash /usr/local/bin/dockerinit.sh
nobody      20  5.5  1.3 4839120 444748 ?      Sl   05:43   0:19 /dropbox/.dropbox-dist/dropbox-lnx.x86_64-135.3.4177/dropbox
root        21  0.0  0.0   4376   664 ?        S    05:43   0:00 sleep 86400