I identified an issue where megasync doesn't like some (very reasonable) non-default sysctl settings
Version / Environment
I recently installed megasync from the megasync-Debian_11_amd64.deb package in a Debian 11 x86_64 VMWare Workstation VM. The version dpkg reports is 4.9.6-1.1.
This VM (as well as the host OS) is configured with a handful of sysctl settings that are non-default, including the following, which hard-disables IPv6 on the system. It's functionally equivalent to not having built IPv6 support into the kernel (or not having loaded IPv6 LKMs) as you can't assigned IPv6 address to interfaces or create IPv6 routes, etc...
net.ipv6.conf.all.disable_ipv6=1
Note that the IPv4 interfaces work fine both on the host and the guest VM
Reproducing
Download and install megasync for Debian
sysctl -w net.ipv6.conf.all.disable_ipv6=1
Open the megasync app
Observe it disappear upon clicking "Login"
Details
I attempted to download a large file from the Mega site using Chrome. That caused the newly installed megasync app to pop up as expected
The login / create account box popped up first as I'm a first time user. I had created an account on the website, so I chose "login" and the UI disappeared completely - poof. The app is effectively a brick in this situation as it can't get to the point where it would show you the rest of the UI, or start performing downloads
I thought it had crashed, but I saw the process still running in the background, with low/medium CPU usage - it was spinning, but not hard. It appeared to be polling but not actually sending or receiving any data or read/writing to the disk. I took note of that
Next, I did the same thing (clicked the large file download in the browser, causing megasync to pop up) but this time I chose "create account". This worked and did not cause the app to disappear for the create account process, but it disappeared after the create account process finished
Workaround / Temporary Fix: Set sysctl setting for ipv6 back to defaults
I tried sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0 - purely on a hunch that this may fix the weird "disappearing app" issue; in the past, this configuration has brought out all sorts of breaking behavior in other closed-source applications; at one point, this even had severe breakage of the system when it had Docker-CE installed (some years ago, I imagine this is fixed now ...)
After setting disable back to 0 (effectively "enabling" IPv6 networking) I didn't assign an IPv6 address to any interfaces, I only reset the sysctl option. The host and upstream WAN link do not have IPv6 interfaces, so this is really not necessary for any reason other than to work around this behavior
I then re-ran megasync and followed the same process as above. This time, with disable_ipv6 set to 0, the login step worked as expected and the app functioned correctly. The file downloaded successfully
Notes
The VM host and guest do not actually have IPv6 networking, nor does the upstream WAN link. However, my resolver will of course return answers to AAAA questions (they just won't be useful)
I suspect at least part of the issue is that AAAA records were being explicitly sent rather than A records, regardless of the fact that there was no IPv6 interface or routes (or support, at all) but I don't have time to look much more into this. There can't be a hard-requirement for IPv6 connectivity because the system and the WAN gateway don't have IPv6 interfaces anyway - it must be a superficial-ish issue, hopefully an easy fix
I'm not a big user of this tool and have already wiped the VM so I can't help troubleshoot unfortunately. But I figured I should be a good citizen and report the issue, especially since there seems to be a simple workaround for any users out there with configurations as odd as mine :)
Unfortunately I don't have the time to test outside of a VM, nor do I have an extra physical host to use for such a test, so did not attempt to reproduce it outside of a virtualized environment; however, I'm reasonably confident virtualization has nothing to do with it
Hello,
I identified an issue where
megasyncdoesn't like some (very reasonable) non-defaultsysctlsettingsVersion / Environment
I recently installed
megasyncfrom themegasync-Debian_11_amd64.debpackage in a Debian 11 x86_64 VMWare Workstation VM. The versiondpkgreports is 4.9.6-1.1.This VM (as well as the host OS) is configured with a handful of
sysctlsettings that are non-default, including the following, which hard-disables IPv6 on the system. It's functionally equivalent to not having built IPv6 support into the kernel (or not having loaded IPv6 LKMs) as you can't assigned IPv6 address to interfaces or create IPv6 routes, etc...Note that the IPv4 interfaces work fine both on the host and the guest VM
Reproducing
megasyncfor Debiansysctl -w net.ipv6.conf.all.disable_ipv6=1megasyncappDetails
I attempted to download a large file from the Mega site using Chrome. That caused the newly installed
megasyncapp to pop up as expectedThe login / create account box popped up first as I'm a first time user. I had created an account on the website, so I chose "login" and the UI disappeared completely - poof. The app is effectively a brick in this situation as it can't get to the point where it would show you the rest of the UI, or start performing downloads
I thought it had crashed, but I saw the process still running in the background, with low/medium CPU usage - it was spinning, but not hard. It appeared to be polling but not actually sending or receiving any data or read/writing to the disk. I took note of that
Next, I did the same thing (clicked the large file download in the browser, causing
megasyncto pop up) but this time I chose "create account". This worked and did not cause the app to disappear for the create account process, but it disappeared after the create account process finishedWorkaround / Temporary Fix: Set sysctl setting for ipv6 back to defaults
I tried
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0- purely on a hunch that this may fix the weird "disappearing app" issue; in the past, this configuration has brought out all sorts of breaking behavior in other closed-source applications; at one point, this even had severe breakage of the system when it had Docker-CE installed (some years ago, I imagine this is fixed now ...)After setting disable back to 0 (effectively "enabling" IPv6 networking) I didn't assign an IPv6 address to any interfaces, I only reset the
sysctloption. The host and upstream WAN link do not have IPv6 interfaces, so this is really not necessary for any reason other than to work around this behaviorI then re-ran
megasyncand followed the same process as above. This time, withdisable_ipv6set to0, the login step worked as expected and the app functioned correctly. The file downloaded successfullyNotes
Thanks, hope this is helpful to someone