如何解决“无法访问Dropbox文件夹”错误？

我在几周前开始的Dropbox遇到了一个很奇怪的问题。

Dropbox将停止与消息“无法访问Dropbox文件夹”同步，并在我重新启动之前拒绝同步。

我已经尝试过重新启动Dropbox并注销，但是我似乎没有做任何事情将允许它在重新启动后再次同步。

这不是权限问题，因为当我突然失去访问权限时，权限不会更改。

我检查了lsof中是否有与保管箱相关的任何内容，但当我停止它时，这些保管箱可能仍然挂起。据我所知，除此以外，Dropbox都无法访问它的文件夹。

如果把这些放进去/etc/sysctl.conf：

fs.inotify.max_user_watches = 1048576
fs.inotify.max_user_instances = 256

它将解决此问题。您可能需要运行sudo sysctl -p才能使这些设置生效。

另外，如果您不希望永久保留这些设置，则可以尝试以下命令...

sudo sysctl fs.inotify.max_user_instances=256
sudo sysctl fs.inotify.max_user_watches=1048576

在这种情况下，重新启动后设置将丢失。

问题在于系统已用完inotify实例。您可以检查系统日志（例如使用tail -f /var/log/syslog），如果看到...

尾部：无法使用inotify，恢复为轮询：打开文件过多

那么您知道这是您的问题。对我来说是nepomuk。

fs.inotify.max_user_instances = 256解决了我当前的“无法访问保管箱文件夹”问题（Ubuntu 12.04）。

它还清除了我注意到的奇怪行为，其中保管箱系统托盘图标持续指示文件活动：箭头不断循环，尽管保管箱中没有任何变化，并且“最近更改的文件”列表保持不变。

更改fs.inotify.max_user_instances = 256后不久，无意义的循环停止了。

在其中一个论坛中，有人提到这是由于inotify。他们有此解决方案/解决方法。

• 禁用桌面搜索（在kde nepomuk + tracker中，在gnome tracker中）
• 重新启动（注销无济于事）

这通常是因为sysctrl的inotify实例用完了。以下2条命令通常可以解决该问题。

sudo sysctl fs.inotify.max_user_watches=1048576
sudo sysctl fs.inotify.max_user_instances=256