[Support] ken-ji - Dropbox


Recommended Posts

  • 4 weeks later...

I've just updated this container and I now get the following appearing in the log:

dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-94.4.384/apex._apex.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-94.4.384/tornado.speedups.cpython-37m-x86_64-linux-gnu.so'
dropbox: load fq extension '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-94.4.384/PyQt5.QtWidgets.cpython-37m-x86_64-linux-gnu.so'
Traceback (most recent call last):
File "dropbox/client/main.pyc", line 262, in <module>
File "dropbox/foundation/navigation_service/factory.pyc", line 19, in <module>
File "dropbox/foundation/navigation_service/navigation_service_impl.pyc", line 57, in <module>
File "dropbox/foundation/html_views/electron/manager_factory.pyc", line 13, in <module>
File "dropbox/foundation/html_views/local/common/manager.pyc", line 33, in <module>
File "dropbox/client/features/model_registry.pyc", line 13, in <module>
File "dropbox/client/features/generated_models.pyc", line 279, in <module>
File "dropbox/client/features/previews/view_anchor.pyc", line 104, in <module>
File "<_bootstrap_overrides>", line 153, in load_module
ImportError: libglapi.so.0: cannot open shared object file: No such file or directory
!! dropbox: fatal python exception:
File "<_bootstrap_overrides>", line 153, in load_module
ImportError: libglapi.so.0: cannot open shared object file: No such file or directory
!! dropbox: fatal python exception:
['Traceback (most recent call last):\n', ' File "dropbox/client/main.pyc", line 262, in <module>\n', ' File "dropbox/foundation/navigation_service/factory.pyc", line 19, in <module>\n', ' File "dropbox/foundation/navigation_service/navigation_service_impl.pyc", line 57, in <module>\n', ' File "dropbox/foundation/html_views/electron/manager_factory.pyc", line 13, in <module>\n', ' File "dropbox/foundation/html_views/local/common/manager.pyc", line 33, in <module>\n', ' File "dropbox/client/features/model_registry.pyc", line 13, in <module>\n', ' File "dropbox/client/features/generated_models.pyc", line 279, in <module>\n', ' File "dropbox/client/features/previews/view_anchor.pyc", line 104, in <module>\n', ' File "<_bootstrap_overrides>", line 153, in load_module\n', 'ImportError: libglapi.so.0: cannot open shared object file: No such file or directory\n'] (error 3)

Any thoughts on how to fix this?

Link to comment

Seems I triggered the automated build on the master branch by mistake.

I re uploaded my last working version as the freeze tag and the latest tag.

So you can edit the template to use the freeze tag (or just delete the current image and try again)

 

This is what I don't like about the automated docker build system, there's no going back unless you built it into your workflow.

Link to comment

This means you need to revert your dropbox application version which is cache in your appdata to allow the application to update itself

this would be /mnt/user/appdata/dropbox/.dropbox-dist (or your equivalent) folder

This folder contains your current version of the Dropbox app

You can stop the container, then proceed to delete the folder /mnt/user/appdata/dropbox/.dropbox-dist, then restart the container.

 

I am working on fixing the image as it seems fixable (by adding the missing X11 libraries - why a headless app needs X11 libraries is beyond me)

 

Edited by ken-ji
Link to comment
18 hours ago, ken-ji said:

This means you need to revert your dropbox application version which is cache in your appdata to allow the application to update itself

this would be /mnt/user/appdata/dropbox/.dropbox-dist (or your equivalent) folder

This folder contains your current version of the Dropbox app

You can stop the container, then proceed to delete the folder /mnt/user/appdata/dropbox/.dropbox-dist, then restart the container.

 

I am working on fixing the image as it seems fixable (by adding the missing X11 libraries - why a headless app needs X11 libraries is beyond me)

 

Thanks for the feedback.   Deleting just the /mnt/user/appdata/dropbox/.dropbox-dist folder did not work, but deleting /mnt/user/appdata/dropbox/ and then relinking my Unraid server to my Dropbox account works fine and I am back in operation.

 

EDIT:  Looks like I spoke too soon as after running for a few minutes after linking the Unraid server to my Dropbox account the same error occurred.   It would be great if you could produce an image that fixes this issue.

Link to comment
8 hours ago, ken-ji said:

I've built the image with the necessary X11 libraries installed. I've started it up without errors and worked on my local instance :D

Just tried it here and it seems to be working great.   No errors now being logged and files seem to be syncing fine.  Thanks for your efforts in fixing this.

 

Link to comment
  • 4 weeks later...
On 5/1/2018 at 3:12 PM, emmcee said:

From the Dashboard, click the Dropbox docker icon. From the menu select "Logs"

Thanks - this took me ages. Why is there no access to logs from the Docker tab only Dashboard?

 

This version of dropbox doesn't seem to like XFS. Is there no solution to have Dropbox and Drive sync to XFS on unRAID at the moment?

Edited by cinereus
Link to comment
On 5/4/2020 at 1:56 AM, cinereus said:

Why is there no access to logs from the Docker tab only Dashboard?

Because at the right most column of the Docker tab/page says LOG, and in basic its a picture of a log file

On 5/4/2020 at 1:56 AM, cinereus said:

This version of dropbox doesn't seem to like XFS. Is there no solution to have Dropbox and Drive sync to XFS on unRAID at the moment?

I don't know what you meant by this, since accdg to Docker: https://help.dropbox.com/installs-integrations/desktop/system-requirements#desktop

A Dropbox folder on a hard drive or partition formatted with one the following file system types:

    ext4
    zfs (on 64-bit systems only)
    eCryptFS (back by ext4)
    xfs (on 64-bit systems only)
    btrfs

 

What is not supported is the shfs (User Share filesystem) exclusive to Unraid, so you can no longer run the Dropbox container on a user share (/mnt/user/*), but needs to be on either the cache drive (/mnt/cache) , a physical array drive (/mnt/diskX) or an Unassigned Drive (/mnt/disks). As I've discussed above, placing the Dropbox sync folder on a user share was never a good idea due to mover moving files between the cache and the array, effectively making the files disappear from Dropbox's point of view, causing files to be deleted and reuploaded/downloaded

Link to comment
4 hours ago, ken-ji said:

Because at the right most column of the Docker tab/page says LOG, and in basic its a picture of a log file

I don't know what you meant by this, since accdg to Docker: https://help.dropbox.com/installs-integrations/desktop/system-requirements#desktop

A Dropbox folder on a hard drive or partition formatted with one the following file system types:

    ext4
    zfs (on 64-bit systems only)
    eCryptFS (back by ext4)
    xfs (on 64-bit systems only)
    btrfs

 

What is not supported is the shfs (User Share filesystem) exclusive to Unraid, so you can no longer run the Dropbox container on a user share (/mnt/user/*), but needs to be on either the cache drive (/mnt/cache) , a physical array drive (/mnt/diskX) or an Unassigned Drive (/mnt/disks). As I've discussed above, placing the Dropbox sync folder on a user share was never a good idea due to mover moving files between the cache and the array, effectively making the files disappear from Dropbox's point of view, causing files to be deleted and reuploaded/downloaded

The logs were cut off on my screen and for some reason everywhere else in the interface you use the drop down menu by clicking on the docker icon.

 

My Dropbox log had the following after linking (how is the user supposed to know to check logs for a link URL?):

 

[ALERT]: So your files continue to sync, sign in to your Dropbox account and move Dropbox to a supported file system.

I see now this is not an issue.

Link to comment

Am now getting this:

 

Couldn't start Dropbox.
This is usually because of a permissions error. 

 

What permissions should the Dropbox share have?

 

I have read the posts of page 5 but you said you'd pushed some changes since then.

 

I accidentally changed the user of the Dropbox fold but I've changed it back and still can't get it started let alone working any more.

Edited by cinereus
Link to comment
bn.BUILD_KEY: Dropbox
bn.VERSION: 97.3.451
bn.constants.WINDOWS_SHELL_EXT_VERSION: 37
bn.is_frozen: True
machine_id: 00000000-0000-0000-0000-000000000000
pid: 15
ppid: 1
ppid exe: failed
uid: 1000
user_info: pwd.struct_passwd(pw_name='cinereus', pw_passwd='x', pw_uid=1000, pw_gid=100, pw_gecos='', pw_dir='/dropbox', pw_shell='/bin/bash')
effective_user_info: pwd.struct_passwd(pw_name='cinereus', pw_passwd='x', pw_uid=1000, pw_gid=100, pw_gecos='', pw_dir='/dropbox', pw_shell='/bin/bash')
euid: 1000
gid: 100
egid: 100
group_info: grp.struct_group(gr_name='users', gr_passwd='x', gr_gid=100, gr_mem=['cinereus'])
effective_group_info: grp.struct_group(gr_name='users', gr_passwd='x', gr_gid=100, gr_mem=['cinereus'])
LD_LIBRARY_PATH: None
cwd: '/dropbox'
     real_path='/dropbox'
                mode=0o40777    uid=1000        gid=100
sh-4.3# cat dropbox_errorm6s1zhwe.txt 
bn.BUILD_KEY: Dropbox
bn.VERSION: 97.3.451
bn.constants.WINDOWS_SHELL_EXT_VERSION: 37
bn.is_frozen: True
machine_id: 00000000-0000-0000-0000-000000000000
pid: 15
ppid: 1
ppid exe: failed
uid: 1000
user_info: pwd.struct_passwd(pw_name='cinereus', pw_passwd='x', pw_uid=1000, pw_gid=100, pw_gecos='', pw_dir='/dropbox', 
pw_shell='/bin/bash')
effective_user_info: pwd.struct_passwd(pw_name='cinereus', pw_passwd='x', pw_uid=1000, pw_gid=100, pw_gecos='', pw_dir='/
dropbox', pw_shell='/bin/bash')
euid: 1000
gid: 100
egid: 100
group_info: grp.struct_group(gr_name='users', gr_passwd='x', gr_gid=100, gr_mem=['cinereus'])
effective_group_info: grp.struct_group(gr_name='users', gr_passwd='x', gr_gid=100, gr_mem=['cinereus'])
LD_LIBRARY_PATH: None
cwd: '/dropbox'
     real_path='/dropbox'
                mode=0o40777    uid=1000        gid=100
     parent     mode=0o40755    uid=0   gid=0
HOME: '/dropbox'
appdata: '/dropbox/.dropbox/instance1'
         real_path='/dropbox/.dropbox/instance1'
                mode=0o40700    uid=1000        gid=100
         parent mode=0o40700    uid=1000        gid=100
dropbox_path: '/dropbox/Dropbox'
              real_path='/dropbox/Dropbox'
                        mode=0o40700    uid=1000        gid=100
              parent    mode=0o40777    uid=1000        gid=100
sys_executable: '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-97.3.451/dropbox'
                real_path='/dropbox/.dropbox-dist/dropbox-lnx.x86_64-97.3.451/dropbox'
                        mode=0o100755   uid=1000        gid=100
                parent  mode=0o40775    uid=1000        gid=100
trace.__file__: '/dropbox/.dropbox-dist/dropbox-lnx.x86_64-97.3.451/python-packages.zip/dropbox/client/ui/common/boot_error.
pyc'
                real_path='/dropbox/.dropbox-dist/dropbox-lnx.x86_64-97.3.451/python-packages.zip/dropbox/client/ui/common/boot_error.pyc'
                        not found
                parent  not found
tempdir: '/tmp'
         real_path='/tmp'
                mode=0o41777    uid=0   gid=0

 

I've tried starting a completely fresh Docker with user 99 and user 1000. And making the Dropbox share either 99 or 1000 too.

Edited by cinereus
Link to comment

So, since there seems to be a problem with shfs, please change the location of the mounts to /mnt/cache/appdata/dropbox and /mnt/cache/Dropbox (and keep that Dropbox share cache only) - This is the new default as pointed out by the other Community maintainers.

I assume the cinereus user name is a user you created in the Unraid Users settings. I also assume this user has access to the Dropbox share?

Otherwise I don't see what the problem is.

 

image.png.689a5db47b92912fab13713397fb8f37.png

This is my setup, with the Config folder stored in a Unassigned Cache SSD

Link to comment
22 hours ago, ken-ji said:

So, since there seems to be a problem with shfs, please change the location of the mounts to /mnt/cache/appdata/dropbox and /mnt/cache/Dropbox (and keep that Dropbox share cache only) - This is the new default as pointed out by the other Community maintainers.

I assume the cinereus user name is a user you created in the Unraid Users settings. I also assume this user has access to the Dropbox share?

Otherwise I don't see what the problem is.

 

image.png.689a5db47b92912fab13713397fb8f37.png

This is my setup, with the Config folder stored in a Unassigned Cache SSD

Why do you say there's a problem with shfs? It was working fine before.

 

And I can't change to any cache locations since I don't have a cache drive. How can it possibly be the default?!

 

Your assumptions about cinereis are correct. The only issue right now is the permissions issue which I posted the error for but I don't understand why that's the case as the permissions seem fine.

Link to comment
1 hour ago, cinereus said:

Why do you say there's a problem with shfs? It was working fine before.

 

And I can't change to any cache locations since I don't have a cache drive. How can it possibly be the default?!

 

Your assumptions about cinereis are correct. The only issue right now is the permissions issue which I posted the error for but I don't understand why that's the case as the permissions seem fine.

Because Dropbox did a very dick move sometime back and artificially (as far as it seems on the user end) limited the client to run on only the Ext4 FS. This has been slightly amended to include "Mainstream" ones like as I listed previously. So the client refuses to run on a shfs mount ie the /mnt/user location.

 

/mnt/user contains all the disks in your array plus the optional cache drive. So, in your case /mnt/user/appdata/dropbox would probably fall under /mnt/disk1/appdata/dropbox unless some of the disk allocation rules come into effect.

 

I'm thinking your app data folder is partially corrupt, since the error mentions some missing files from the application zip archive, so you can try removing both the appdata and Dropbox mount points in Unraid (so that you really start afresh).

Link to comment
14 hours ago, ken-ji said:

Because Dropbox did a very dick move sometime back and artificially (as far as it seems on the user end) limited the client to run on only the Ext4 FS. This has been slightly amended to include "Mainstream" ones like as I listed previously. So the client refuses to run on a shfs mount ie the /mnt/user location.

 

/mnt/user contains all the disks in your array plus the optional cache drive. So, in your case /mnt/user/appdata/dropbox would probably fall under /mnt/disk1/appdata/dropbox unless some of the disk allocation rules come into effect.

 

I'm thinking your app data folder is partially corrupt, since the error mentions some missing files from the application zip archive, so you can try removing both the appdata and Dropbox mount points in Unraid (so that you really start afresh).

Thanks. So I understand what I need to do correctly...

 

Delete the Dropbox share and reinstate it?

 

How exactly do I "remove the appdata mount point in unraid" without affecting all my other apps?

Edited by cinereus
Link to comment

Stop the container. Very important. A running container will probably delete all your Dropbox files.

Open the terminal to Unraid >_ on the upper right of your screen.

run

root@tower:~# rm -r /mnt/user/appdata/dropbox /mnt/user/Dropbox

this will nuke Dropbox share (which will be regenerated when the container is started up) and the appdata for the Dropbox container

When you restart the container, it will run from scratch, so you will need to link it again. Warning, this might cause you to go over the 3 devices limit for Free accounts, so make sure to go your Dropbox account and unlink the previous container. It will be a linux client with a hexadecimal name like abc12458efd

  • Like 2
Link to comment
19 hours ago, ken-ji said:

Stop the container. Very important. A running container will probably delete all your Dropbox files.

Open the terminal to Unraid >_ on the upper right of your screen.

run


root@tower:~# rm -r /mnt/user/appdata/dropbox /mnt/user/Dropbox

this will nuke Dropbox share (which will be regenerated when the container is started up) and the appdata for the Dropbox container

When you restart the container, it will run from scratch, so you will need to link it again. Warning, this might cause you to go over the 3 devices limit for Free accounts, so make sure to go your Dropbox account and unlink the previous container. It will be a linux client with a hexadecimal name like abc12458efd

Thanks. I think we're getting somewhere. I relinked about 12 hours ago and it said:

 

This computer is now linked to Dropbox. Welcome cinereus
[ALERT]: So your files continue to sync, sign in to your Dropbox account and move Dropbox to a supported file system

 

It's now made a .dropbox_cache with prefetch_cache and temp_dirs directories and the temp_dir has lot of copies of a 0 KB dropbox-upgrade-97.3.460.tar.gz but no files have been synced yet.

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.