Computer recognized as new device on restart AND 'nucleus_python.SyncEngineError: ... Filesystem is not supported: "FUSE"'

[D12EA177E12]

I've been a user of 'dropbox-filesystem-fix' since April 2019 and for the past two months the Dropbox client for Linux recognizes my computer as a new device on restart (more accurately, after a short period, say, a couple of hours). Since the limit on the number of synced devices is three, this effectively required me to unlink a device first before I could link my computer to Dropbox account.

In the latest stable release 90.4.307 (which gets pushed to the client) Dropbox has applied a new patch, making 'dropbox-filesystem-fix' unable to bypass their filesystem detection.

Sure enough, the generated debug/log file indicates that it had detected an unsupported filesystem:

Traceback (most recent call last):
File "dropbox/client/main.pyc", line 747, in wrapper
File "dropbox/client/main.pyc", line 6218, in finish_dropbox_boot
File "dropbox/client/main.pyc", line 5733, in _init_components_for_account
File "dropbox/sync_engine_boundary/factory.pyc", line 328, in make_sync_engine
File "dropbox/sync_engine/nucleus/classic_client/sync_engine.pyc", line 432, in init
File "dropbox/sync_engine/nucleus/classic_client/sync_engine.pyc", line 1827, in _init_new_engine_locked
File "dropbox/sync_engine/nucleus/thin_client/client.pyc", line 201, in init
File "nucleus_python.pyx", line 83, in nucleus_python.NucleusSyncEngine.cinit
nucleus_python.SyncEngineError: Initializing engine |>> Initializing platform |>> Checking if filesystem is supported |>> Filesystem is not supported: "FUSE"

Note: I've only included the "Traceback" portion of the debug file. If you require the entire content of the file I will update this bug report.

[dark]

Thanks for the report. I haven't had a chance to look at this behavior yet, since I'm still on a previous client release. I will try and force an update and see what happens.

In the meantime, it would be nice if you could upload the entire debug file. I am not sure if there's any useful information there, but it's worth a shot. You might want to look through the file first, just in case it contains private information.

[D12EA177E12]

since I'm still on a previous client release.

Yes. I should mention that the behavior I described above does not appear in previous client releases. For example, I tried switching back to version ̶7̶6̶.̶4̶.̶1̶2̶6̶ and dropbox-filesystem-fix worked as expected. The problem is that my client is configured to autoupdate. How did you disable autoupdate? Maybe this can be a temporary fix for me in the meantime.

[dark]

I used chmod a-w -R "${HOME}/.dropbox-dist/dropbox-lnx.x86_64-${VERSION}/" to disable write permissions and prevent autoupdates. This works well, until Dropbox decides that the old client needs to be retired, at which point the server will refuse connections. At that point re-add the write permission and the client will auto-update.

This has worked well for me for the last ~2 years; I had to allow an update manually maybe twice or three times.

[dark]

Back to the original topic, your report pushed me to try and find a permanent solution once again, and I am currently testing an alternative, open-source client for Dropbox: https://github.com/SamSchott/maestral-dropbox

It seems to work well, and if it continues this way I might stop using the official client. Hence, I might not have a chance to keep testing my fix anymore :)

[D12EA177E12]

Actually I needed to recursively disable write permission on "~/.dropbox-dist" because when the client finds that it can't write to "~/.dropbox-dist/dropbox-lnx.x86_64-${VERSION}" it deletes/overwrites it.

This works well, until Dropbox decides that the old client needs to be retired, at which point the server will refuse connections.

As it turns out, the server rejects client version 76.4.126.

Syncing 87,716 files
Uploading 87,716 files...
⋮
Connecting...
Syncing 87,716 files
Uploading 87,716 files..

and finally ...

🤦
I guess I'll give x86_64-89.4.278 a try since it is the latest version that you've tested dropbox-filesystem-fix against.

[D12EA177E12]

I might stop using the official client. Hence, I might not have a chance to keep testing my fix anymore :)

Marco, I have a simple/lightweight computer setup and really like how simply adding a /opt/dropbox-filesystem-fix/dropbox_start.py & line inside .bash_profile gets the job done. If you have time to update it, then I prefer not to look elsewhere. ^^;

[D12EA177E12]

I can verify with you that dropbox-fileystem-fix actually does not work with x86_64-89.4.278.

[cmalard]

Hey guys, I'm actually using the script with Dropbox v91.4.548 (latest) and everything looks fine 👍

[D12EA177E12]

Hey guys, I'm actually using the script with Dropbox v91.4.548 (latest) and everything looks fine👍

Where is your Dropbox folder located, is it a symlink, a bind mount, or something else?
What is the underlying filesystem type?

[cmalard]

It's a basic directory in the root of my home (~/Dropbox). The filesystem is Ext4 (v1) on Ubuntu 19.10 with eCryptfs encrypted home directory (which was not supported by Dropbox).

But... maybe something else is happening : to check, I stopped Dropbox and restarded it without using dropbox-filesystem-fix... it worked 🤨 Can't tell since when 🤨

[dark]

@cmalard It started working in July 2019 :)
https://www.dropboxforum.com/t5/Desktop-client-builds/Beta-Build-77-3-127/m-p/355527/highlight/true#M5361

[D12EA177E12]

@dark
Are you able to reproduce the problem I've described?

@cmalard
Your underlying filesystem is still Ext4. OTOH, my Dropbox folder is NTFS (FUSE-implemented).

[dark]

@D12EA177E12 (un)fortunately I wasn't. I have been using Maestral only for the last 10 days or so, I haven't booted the official client at all.

[D12EA177E12]

@dark

In the meantime, it would be nice if you could upload the entire debug file. I

Here it is:

bn.BUILD_KEY: Dropbox
bn.VERSION: 81.3.183
bn.DROPBOXEXT_VERSION: failed
bn.is_frozen: True
machine_id: 5fdd0685-6eac-4f0c-bc39-874623c76939
pid: 1803
ppid: 1
ppid exe: failed
uid: 1000
user_info: pwd.struct_passwd(pw_name='fkl', pw_passwd='x', pw_uid=1000, pw_gid=1000, pw_gecos='', pw_dir='/home/fkl', pw_shell='/bin/bash')
effective_user_info: pwd.struct_passwd(pw_name='fkl', pw_passwd='x', pw_uid=1000, pw_gid=1000, pw_gecos='', pw_dir='/home/fkl', pw_shell='/bin/bash')
euid: 1000
gid: 1000
egid: 1000
group_info: grp.struct_group(gr_name='fkl', gr_passwd='x', gr_gid=1000, gr_mem=[])
effective_group_info: grp.struct_group(gr_name='fkl', gr_passwd='x', gr_gid=1000, gr_mem=[])
LD_LIBRARY_PATH: None
cwd: '/mnt/Dragon/home/fkl.current'
real_path='/mnt/Dragon/home/fkl.current'
mode=0o40755 uid=1000 gid=1000
parent mode=0o40755 uid=1000 gid=1000
HOME: '/home/fkl'
appdata: '/home/fkl/.dropbox/instance1'
real_path='/mnt/Dragon/home/fkl.current/.dropbox/instance1'
mode=0o40700 uid=1000 gid=1000
parent mode=0o40755 uid=1000 gid=1000
dropbox_path: '/home/fkl/Dropbox'
real_path='/mnt/Dragon/home/fkl.current/Dropbox'
mode=0o40755 uid=1000 gid=1000
parent mode=0o40755 uid=1000 gid=1000
sys_executable: '/mnt/Dragon/home/fkl.current/.dropbox-dist/dropbox-lnx.x86_64-81.3.183/dropbox'
real_path='/mnt/Dragon/home/fkl.current/.dropbox-dist/dropbox-lnx.x86_64-81.3.183/dropbox'
mode=0o100555 uid=1000 gid=1000
parent mode=0o40555 uid=1000 gid=1000
trace.file: '/mnt/Dragon/home/fkl.current/.dropbox-dist/dropbox-lnx.x86_64-81.3.183/python-packages-37.zip/dropbox/client/ui/common/boot_error.pyc'
real_path='/mnt/Dragon/home/fkl.current/.dropbox-dist/dropbox-lnx.x86_64-81.3.183/python-packages-37.zip/dropbox/client/ui/common/boot_error.pyc'
not found
parent not found
tempdir: '/tmp'
real_path='/tmp'
mode=0o41777 uid=0 gid=0
parent mode=0o40755 uid=0 gid=0
Traceback (most recent call last):
File "dropbox/client/main.pyc", line 784, in wrapper
File "dropbox/client/main.pyc", line 6257, in finish_dropbox_boot
File "dropbox/client/main.pyc", line 5761, in _init_components_for_account
File "dropbox/sync_engine_boundary/factory.pyc", line 328, in make_sync_engine
File "dropbox/sync_engine/nucleus/classic_client/sync_engine.pyc", line 391, in init
File "dropbox/sync_engine/nucleus/classic_client/thin_adapter/in_proc.pyc", line 208, in init
File "dropbox/sync_engine/nucleus/classic_client/thin_adapter/in_proc.pyc", line 569, in _init_new_engine_locked
File "dropbox/sync_engine/nucleus/thin_client/client.pyc", line 129, in init
File "nucleus_python.pyx", line 85, in nucleus_python.NucleusSyncEngine.cinit
nucleus_python.SyncEngineError: Initializing engine |>> Initializing platform |>> Checking if filesystem is supported |>> Filesystem is not supported: "FUSE"

[D12EA177E12]

After hours of testing, it appears that version 81.3.183 is the first version (that I've tested) which dropbox-fileystem-fix is unable get past the official client's detection, but any version before it the server will reject.

As you can see in the debug file the real paths got exposed. I've tried both bind mounts and symlinks.

[D12EA177E12]

I've also switched over to Maestral. It does the job, but in comparison to the native client it seems like there's a ̶s̶l̶i̶g̶h̶t̶ ̶(̶y̶e̶t̶ ̶n̶o̶t̶i̶c̶e̶a̶b̶l̶e̶)̶ sychronization delay.

[dark]

Given the last update, and since this project is now in maintenance mode, I am going to close this issue.

[otherguy]

@dark can you add the information that this no longer works to the README and maybe archive the GitHub repo?