Question

56

How do I fix a "Can't access Dropbox folder" error?

rated 0 times [ 56] [ 0] / answers: 1 / hits: 19331 / 3 Years ago, fri, june 11, 2021, 10:34:06

I'm having a rather strange problem with Dropbox that started a few weeks ago.

Dropbox will stop syncing with the message "Can't access Dropbox folder", and refuse to sync until I reboot.

I've tried restarting Dropbox and logging out, but nothing I seem to do will allow it to sync again short of a reboot.

This is not a permissions problem, as the permissions don't change when I suddenly lose access.

I've checked lsof for anything related to dropbox that might still be hanging on when I stop it. As far as I can tell nothing else other than Dropbox is accessing it's folders when this happens.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

ettorina

Add To Favorites

Follow

Total Points: 439

Total Questions: 99

Total Answers: 131

Location: Vanuatu

Member since Wed, Oct 14, 2020

4 Years ago

ettorina questions

1 If I upgrade my 16.04 to 22.04 Mate, does it affect my git files?

Tue, Mar 14, 23, 03:20, 1 Year ago

1 is Firefox .deb package in ubuntu 22.04 in beta?

Thu, Sep 1, 22, 15:28, 2 Years ago

1 Where can I download dpkg .deb?

Mon, Mar 14, 22, 06:04, 2 Years ago

1 How to turn a PDF grayscale in Ubuntu?

Sun, Jul 24, 22, 13:31, 2 Years ago

1 Keyboard layout English UK international "with" AltGr for typing Ñ does not exist in Ubuntu 20.04

Sun, Nov 28, 21, 13:31, 2 Years ago

View All

answered 3 Years ago raldership · Accepted Answer

if you put these in /etc/sysctl.conf:

fs.inotify.max_user_watches = 1048576

fs.inotify.max_user_instances = 256

it will fix the issue. You may have to run sudo sysctl -p for these settings to take effect.

Alternatively, if you are not interested in making these settings permanent, you may try the following commands...

sudo sysctl fs.inotify.max_user_instances=256

sudo sysctl fs.inotify.max_user_watches=1048576

In this case the settings will be lost after a reboot.

The problem is that the system has run out of inotify instances. You can check your syslog (e.g. by using tail -f /var/log/syslog) and if you see...

tail: inotify cannot be used, reverting to polling: Too many open file

then you know this is your issue. For me it was nepomuk.