Open DurhamDecLab opened 1 year ago
Tried removing .local/share/data/Mega Limited and logging back in, no change. Is there somewhere else that it saves config?
Hey @DurhamDecLab,
Do you have appropriate permisisons for /data?
What filesystem is /data using? :)
~Dave
Hi @dwmega , all synced folders are ext4 and my account owns them. This is weird, it only seems to occur on machines that have been running Megasync for a while and have been upgraded from an earlier version. I can literally have one folder synced on another drive (e.g. /data is mounted to /dev/sdb1 and root fs is /dev/sda1) and the client will hammer disk access on the root, even though there's nothing it should be scanning for there. It doesn't stop after a while either. Behaviour doesn't occur on a machine with a recent installation of Linux and Megasync.
OK, two different computers had this problem, one an old AMD and one a modern Intel. Both had been running Gentoo Linux and Megasync for some years. It turns out that the problem only occurs when they are configured to sync either of two particular shared folders; they set up the sync OK but then start constantly scanning root drive (although folders are NOT on this drive) and don't pick up any changes. These two shared folders have existed in my Mega account for years and other computers can see them fine. Creating new shared folders and simply moving the content to them seems to avoid the problem.
Upgraded to 4.8.1, add synced folders under e.g. /data, which is a mount to a different disk. Syncs, then after a few seconds comes up with "scanning" again and starts lots of I/O to root drive. Never completes, and fails to detect changes to actual synced folders.