[Support] Dropbox by otherguy


Recommended Posts

8 hours ago, hernandito said:

Is there a way to setup this client so that files will never get removed?

I don't know any option, but you could add an additional unRAID share like dropbox_backup on the SAME disk and then do this:

cp -a --reflink=always /mnt/disk3/dropbox/. /mnt/disk3/dropbox_backup/

 

By that it copies all files to the backup dir without deleting files which were removed from the source and those copied files do not occupy extra storage space as they are only reflinks (snapshots).

Link to comment
On 4/6/2022 at 3:15 PM, Teknishun said:

My logs are full of this

 

You're using an old version of Dropbox. Please update to the latest version to continue using Dropbox.

https://www.dropbox.com/downloading?from_client=True

 

I'm not getting any files synced

 

delete docker Container Variable  vaule    DROPBOX_SKIP_UPDATE 

 

Screenshot from 2022-04-09 13-25-12.png

  • Thanks 1
Link to comment
  • 2 weeks later...

Everytime I restart the container or server I have to manually add the installation to dropbox again

Please visit https://www.dropbox.com/cli_link_nonce?nonce=0ed8743549234234324657193423fce840c91 to link this device.

 

How can I do this automatically or make sure the link does not change?

Link to comment

Hi i'm trying out this docker too.. 

 

I have 1 text file and 1 sub directory in my dropbox account, but the file is not being synced/sent into the docker container "client". 

 

the logs just shows a series of lines of "Syncing... " any advice? 

 

EDIT: so i had to remove the value for the last property dropbox_skip_update, and tried the "No" Cache for the dropbox Shares setting, and the logs is now showing "Up to date" and plenty of it.


Checking the share directory has reflected my filed already. just circling back for the update

Edited by baby0nboardInSg
Link to comment
  • 1 month later...
On 10/6/2021 at 6:03 PM, muttly.irl said:

I'm having a small issue with this. I'm logged in but its been stuck on indexing files. I know I have a lot of files in my dropbox, 300,000appx. It's stuck indexing at the same number with 24 hours.

 

It eventually stops with this error:
 

RUST PANICKING -- "queue became corrupt while running: Custom { kind: Other, error: \"io error: failed to fill whole buffer\" }" at "desktop/app/lib/apex/rust/analytics/src/queue.rs":284

 

Got exactly the same issues pretty much.. got it set to auto restart and never stop but all that does is keep filling up the cache folder Dropbox creates and is filling the drive up. 

  • Like 1
Link to comment
  • 1 month later...
On 6/6/2022 at 3:05 PM, joethomasld said:

 

Got exactly the same issues pretty much.. got it set to auto restart and never stop but all that does is keep filling up the cache folder Dropbox creates and is filling the drive up. 

I gave up on it. I never got it working. I now have a windows VM that's sole job is to sync dropbox.

Link to comment
On 8/6/2022 at 12:55 AM, mgutt said:

I think another option could be the Debian Docker Container and trying to install the Linux Version of Dropbox inside this container.

I also give up. Always having issues with Dropbox out of date, logfile permissions or re-adding the machine to the account. 

It is not a problem of your container mgutt, it is how Dropbox handles things.

 

So if you can create a debian container with a dropbox solution inside that would be wonderful ;-)

Link to comment

try this,

open dropbox web on the same browser first without clicking the link,

after logging into dropbox,

make sure you have enough links available,

dropbox free allows only 3 devices. 

delete obsolete ones to make room. 

now goto dropbox log file and click the link to activate.

 

worked for me

 

  • Like 1
Link to comment
  • 1 month later...
  • 1 month later...
  • 1 month later...
On 8/11/2022 at 10:51 PM, jluerken said:

I also give up. Always having issues with Dropbox out of date, logfile permissions or re-adding the machine to the account. 

It is not a problem of your container mgutt, it is how Dropbox handles things.

 

So if you can create a debian container with a dropbox solution inside that would be wonderful ;-)

 

I echo the much thanks to mgutt for spending his effort in putting this together.

 

I've also been having issues with this image for about a month now with it crashing every 5 to 60 minutes and taking ~48 hours to get from "410k files left to index" down to "370k files left to index."

 

Given mgutt's suggestion of trying a debian container, I looked to the image he forked from, which is 'janeczku/dropbox' which is based on debian.

 

Switching to 'janeczku/dropbox' allowed the dropbox daemon to index my 410k files in about 15 minutes and then it finished syncing about 10 minutes later (but that is a function of how "out of date" the local version is with the online version).

 

I know its not super popular 'round here, but here is my docker compose file in case it can help someone else:

version: "3.8"
services:
  dropbox:
    image: janeczku/dropbox:latest
    environment:
      DBOX_UID: 99
      DBOX_GID: 100
      #DBOX_SKIP_UPDATE: true
    volumes:
      - /mnt/cache/dropbox:/dbox/Dropbox
      - /mnt/cache/dockerdata/dropbox:/dbox/.dropbox

 

This has so far been working well enough for syncing purposes. But one thing that didn't work "out of the box" was checking on the dropbox daemon status, which can be done like this from an unraid shell:

docker exec container_name dropbox status

 

Unfortunately, once the daemon was done indexing and started actually downloading/syncing files then checking the status resulted in a python error. This was caused by a bug with the 'dropbox-cli' script in the container that caused it to fail due to a text encoding issue. Luckily, its easy enough to fix by hand, at least partially, by changing line 67 of '/usr/bin/dropbox-cli' from this

enc = locale.getpreferredencoding()

to this

enc = "utf-8"

 

I'm not super docker savvy so I wasn't able to figure out how to edit the file in the container, so I just moved '/usr/bin/dropbox-cli' to '/dbox/.dropbox/dropbox-cli' (which is mounted outside the container), edited with vim from the unraid web shell, and then copied the file back. Now 'docker status' works as expected. I don't suspect the above fix will work for everything because the docker-cli script is a bit of a hot mess. There are other places in the script that are still directly pulling from 'locale.getpreferredencoding()' instead of reading the 'enc' value, so those places may still fail. I also first tried just pulling in the latest official script from here (which appears to have fixed the bug) but found that it requires python3 which isn't available in the container and I didn't want to muck with that when I could just change a few lines of python.

Link to comment
On 11/14/2022 at 8:44 PM, JustinRSharp said:

Has anyone had this issue:

 

Please visit https://www.dropbox.com/cli_link_nonce?nonce=716006b069262d54bbc79ec32c8a1a2 to link this device.
This computer is now linked to Dropbox. Welcome P
[ALERT]: Your Dropbox folder is on a file system that is no longer supported.

I had this same issue when I mounted '/mnt/user/dropbox' into the container instead of '/mnt/cache/dropbox'. Changing to all my mounted volumes were on '/mnt/cache' instead of '/mnt/user' fixed this for me. You can also pick a specific array disk as well: '/mnt/diskX' if you want your dropbox data to be on the array. Search this thread more for more info, as this info has already been posted earlier.

  • Like 1
Link to comment

@Anticast I wish I knew what you did to get even janeczku image to work. No docker images work for me. Every single one of them I get authenticated, but then it throws an error of 

 

[ALERT]: Dropbox needs to rename your existing folder or file named Dropbox to finish installing. Please close any open documents and try again.

 

I mounted /dbox in the container to /mnt/disk1/dbox rather than the /dbox/Dropbox folder. By doing this, it creates the Dropbox folder, but then updates the client, and hits the same error.

 

I finally fixed that by deleting /mnt/disk1/dbox/Dropbox right as the udpate begins. It sucessfully starts dropboxd, loads the plugins, and then... dies. No errors, nothing. 

 

Checking for latest Dropbox version...
Latest   : 163.4.5456
Installed: 94.4.384
Downloading Dropbox v163.4.5456...
Installing new version...
Dropbox updated to v163.4.5456
Starting dropboxd (163.4.5456)...
This computer isn't linked to any Dropbox account...
Please visit https://www.dropbox.com/cli_link_nonce?nonce=abc to link this device.
This computer isn't linked to any Dropbox account...
Please visit https://www.dropbox.com/cli_link_nonce?nonce=abc to link this device.
This computer isn't linked to any Dropbox account...
Please visit https://www.dropbox.com/cli_link_nonce?nonce=abc to link this device.
This computer is now linked to Dropbox. Welcome rayzor

 

That's all the logs show and then the container exits.

Link to comment
  • 2 weeks later...

@rayzor

 

I don't know anything about the folder renaming error, so I can't help there. The best I can think to do is show you my full compose file and container logs just so you can compare and maybe get some ideas...

 

My `docker-compose.yml`:

version: "3.8"
services:
  dropbox:
    image: janeczku/dropbox:latest
    environment:
      DBOX_UID: 99
      DBOX_GID: 100
    volumes:
      - /mnt/cache/dropbox:/dbox/Dropbox
      - /mnt/cache/dockerdata/dropbox:/dbox/.dropbox

 

Here are my container logs, pulled for Portainer, after the last two restarts (containers are restarted as part of a backup I run). As you can see, I don't get any interesting info from the logs:

2022-12-29T11:08:21.531538010Z Checking for latest Dropbox version...
2022-12-29T11:08:27.338688852Z Latest   : 163.4.5456
2022-12-29T11:08:27.338715502Z Installed: 163.4.5456
2022-12-29T11:08:27.338721952Z Dropbox is up-to-date
2022-12-29T11:08:27.339702163Z Starting dropboxd (163.4.5456)...
2022-12-29T11:08:28.040850317Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/cryptography.hazmat.bindings._openssl.cpython-38-x86_64-linux-gnu.so'
2022-12-29T11:08:28.076813609Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/cryptography.hazmat.bindings._padding.cpython-38-x86_64-linux-gnu.so'
2022-12-29T11:08:28.116893534Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/apex._apex.cpython-38-x86_64-linux-gnu.so'
2022-12-29T11:08:28.242098016Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
2022-12-29T11:08:28.246191719Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
2022-12-29T11:08:29.502305456Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
2022-12-29T11:08:32.567984571Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'
2023-01-02T11:00:35.478754170Z 
2023-01-02T11:00:35.608528761Z Session terminated, terminating shell... ...terminated.
2023-01-02T11:08:47.893458300Z Checking for latest Dropbox version...
2023-01-02T11:08:53.778131711Z Latest   : 163.4.5456
2023-01-02T11:08:53.778158271Z Installed: 163.4.5456
2023-01-02T11:08:53.778164171Z Dropbox is up-to-date
2023-01-02T11:08:53.779235301Z Starting dropboxd (163.4.5456)...
2023-01-02T11:08:54.319299271Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/cryptography.hazmat.bindings._openssl.cpython-38-x86_64-linux-gnu.so'
2023-01-02T11:08:54.353710302Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/cryptography.hazmat.bindings._padding.cpython-38-x86_64-linux-gnu.so'
2023-01-02T11:08:54.380142041Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/apex._apex.cpython-38-x86_64-linux-gnu.so'
2023-01-02T11:08:54.489037207Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/psutil._psutil_linux.cpython-38-x86_64-linux-gnu.so'
2023-01-02T11:08:54.490007007Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/psutil._psutil_posix.cpython-38-x86_64-linux-gnu.so'
2023-01-02T11:08:55.723200077Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/tornado.speedups.cpython-38-x86_64-linux-gnu.so'
2023-01-02T11:08:58.516284166Z dropbox: load fq extension '/opt/dropbox/dropbox-lnx.x86_64-163.4.5456/wrapt._wrappers.cpython-38-x86_64-linux-gnu.so'

 

Link to comment

Other things to try...

 

Try making sure 'nobody' owns the dropbox folder (User 99) by running: 

chown -R nobody /mnt/disk1/dbox

IIRC, this is one of the things that mgutt's version does on startup, and I did this as well to my dropbox folder.

 

Also, another nice thing that mgutt's version has is that it spams the current dropbox status to the log on an interval. This version doesn't do that. Once the daemon starts, its all quiet. I had to execute the following command in the container to monitor my first-run sync status to make sure it was making progress (which it did, it took about 15 minutes to index my 410k files):

dropbox status

or if your container is named 'dropbox_dropbox_1' (if you launched it via docker compose from a folder called 'dropbox') then you can check the status from outside the container in the unraid web shell like this:

docker exec dropbox_dropbox_1 dropbox status

 

Edited by Anticast
Link to comment
  • 1 month later...

I get this same error message after linking my account

[ALERT]: Dropbox needs to rename your existing folder or file named Dropbox to finish installing. Please close any open documents and try again.

I tried the above tricks that some have suggested, but either they no longer work or I'm doing something wrong. Is there another Dropbox container that exists and works? Maybe a lil more simply..?

Link to comment
  • 3 weeks later...

@rayzor i had the same issue where after linking my device it just said:

[ALERT]: Dropbox needs to rename your existing folder or file named Dropbox to finish installing. Please close any open documents and try again.

 

And if i restarted the container it would have to reconnect again. The way i resolved this was by specifying v1.9.0 of the image which is apparently before the dropbox update that causes the above alert.

  dropbox:
    image: otherguy/dropbox:1.9.0
    container_name: dropbox
    network_mode: host
    restart: unless-stopped
    environment:
      - DROPBOX_UID=$PUID
      - DROPBOX_GID=$PGID
      - POLLING_INTERVAL=20
      - DROPBOX_SKIP_UPDATE=true
    volumes:
      - $USERDIR/dropbox/config:/opt/dropbox/.dropbox
      - $USERDIR/dropbox/data:/opt/dropbox/Dropbox

 

This would start and i could use the link from the logs to successfully link the account and then the logs would just show "Syncing..." over and over but no files would sync. You'll notice that the version of dropbox is very out of date. Stop the container and change the  image to be the latest and remove the DROPBOX_SKIP_UPDATE param

 

  dropbox:
    image: otherguy/dropbox:latest
    container_name: dropbox
    network_mode: host
    restart: unless-stopped
    environment:
      - DROPBOX_UID=$PUID
      - DROPBOX_GID=$PGID
      - POLLING_INTERVAL=20
    volumes:
      - $USERDIR/dropbox/config:/opt/dropbox/.dropbox
      - $USERDIR/dropbox/data:/opt/dropbox/Dropbox

 

Dropbox should update to the latest version, skip the alert about needing to rename the existing folder, and start syncing

  • Like 1
Link to comment
  • 1 month later...
  • 3 months later...
On 2/26/2023 at 11:42 PM, dangerpigeon said:

@rayzor i had the same issue where after linking my device it just said:

[ALERT]: Dropbox needs to rename your existing folder or file named Dropbox to finish installing. Please close any open documents and try again.

 

And if i restarted the container it would have to reconnect again. The way i resolved this was by specifying v1.9.0 of the image which is apparently before the dropbox update that causes the above alert.

  dropbox:
    image: otherguy/dropbox:1.9.0
    container_name: dropbox
    network_mode: host
    restart: unless-stopped
    environment:
      - DROPBOX_UID=$PUID
      - DROPBOX_GID=$PGID
      - POLLING_INTERVAL=20
      - DROPBOX_SKIP_UPDATE=true
    volumes:
      - $USERDIR/dropbox/config:/opt/dropbox/.dropbox
      - $USERDIR/dropbox/data:/opt/dropbox/Dropbox

 

This would start and i could use the link from the logs to successfully link the account and then the logs would just show "Syncing..." over and over but no files would sync. You'll notice that the version of dropbox is very out of date. Stop the container and change the  image to be the latest and remove the DROPBOX_SKIP_UPDATE param

 

  dropbox:
    image: otherguy/dropbox:latest
    container_name: dropbox
    network_mode: host
    restart: unless-stopped
    environment:
      - DROPBOX_UID=$PUID
      - DROPBOX_GID=$PGID
      - POLLING_INTERVAL=20
    volumes:
      - $USERDIR/dropbox/config:/opt/dropbox/.dropbox
      - $USERDIR/dropbox/data:/opt/dropbox/Dropbox

 

Dropbox should update to the latest version, skip the alert about needing to rename the existing folder, and start syncing

 

I'm new to Unraid (Day 3 lol)...and I just wanted to add my current experience.

Using the docker as it came off the App page from otherguy...I got the "

[ALERT]: Dropbox needs to rename your existing folder or file named Dropbox to finish installing. Please close any open documents and try again." error.

 

Following the above - it now appears to be working. It's currently syncing the files. It's nearly 200,000 files so it's going to take some time but the files it has synced already seem to be correct.

 

Was surprised it work to be honest lol. Will update if anything goes arwy!. Thanks!

 

EDIT: Spoke too soon - see next post.

Edited by Stupot
Link to comment

Spoke to soon. Seems to be syncing fine but the container keeps stopping/crashing after a few minutes with no reason stated.  I can restart it without issue and it continues where it left off.  I've added the restart if not stopped extra parameter so it always restarts when it crashes - I guess it would be a satisfactory solution but would love to be able to find out why it's crashing.

 

Like I said, new to Unraid and containers/dockers - so any advice? Thanks 

Edited by Stupot
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.