March 10, 20206 yr Author Sorry for not answering your PM, but the container does have the dropbox.py script which can be used to check the status of the sync
March 10, 20206 yr 1 hour ago, ken-ji said: Sorry for not answering your PM, but the container does have the dropbox.py script which can be used to check the status of the sync How do we access and run the script? Edited March 10, 20206 yr by CyberMew
March 10, 20206 yr Author Click on the container icon and select >_ Console This will open a terminal inside the container, then run the following commands first su - nobody cd Dropbox then you can run the dropbox.py command for the various commands to see the sync status
April 6, 20206 yr 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?
April 6, 20206 yr Author 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.
April 7, 20206 yr I tried deleting the image and then redownloading it but I get the same error. I also tried using the freeze tag but that did not change things. Is there sokething else I can try?
April 7, 20206 yr Author 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 April 7, 20206 yr by ken-ji
April 8, 20206 yr 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.
April 8, 20206 yr Author I've built the image with the necessary X11 libraries installed. I've started it up without errors and worked on my local instance
April 9, 20206 yr 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 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.
May 3, 20206 yr 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 May 3, 20206 yr by cinereus
May 6, 20206 yr Author 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
May 6, 20206 yr 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.
May 6, 20206 yr Author 1 hour ago, cinereus said: (how is the user supposed to know to check logs for a link URL?): Not picking a fight, but it is discussed on post #2, page #1 of this support thread.
May 6, 20206 yr 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 May 6, 20206 yr by cinereus
May 6, 20206 yr 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 May 6, 20206 yr by cinereus
May 8, 20206 yr On 5/6/2020 at 11:02 PM, ken-ji said: Could you post a screenshot of your dropbox container mount mappings? All kept as default apart from /mnt/user/Dropbox share
May 9, 20206 yr Author 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. This is my setup, with the Config folder stored in a Unassigned Cache SSD
May 9, 20206 yr 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. 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.
May 10, 20206 yr Author 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).
May 10, 20206 yr 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 May 10, 20206 yr by cinereus
May 10, 20206 yr Author 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
May 11, 20206 yr 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.
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.