前两天帮别人处理了一个问题，环境是CentOS，在更新时出了一点小问题，虽然Nextcloud升级到了13.01，访问登录页面时显示正常，但是登录后却显示“服务器内部错误”。查看日志，发现记录“JSCombiner:can not cache Merge.js”
解决方法
解决方法很简单，Nextcloud在更新时会在数据库中的oc_storages表中写入oc_filecache一行，如果由于某些原因，这一行未能移除，那么FilesAPP在读取用户文件信息时就会报错。
将数据库中的这一行的内容移除即可，步骤如下：
（在操作数据库前最好备份一下，以防万一）
1.登录数据库
mysql -u root -p
只要能读写Nextcloud所使用的数据库即可，不一定必须是root用户。
2.删除oc_filecache
切换到Nextcloud数据库：
mysql> Use nextcloud
选择oc_storages表：
mysql> select * from oc_storages;
清空oc_filecache一行：
mysql> TRUNCATE TABLE oc_filecache;
解决过程
因为之前CentOS报出这个中类似的问题往往是因为权限不对，按照解决CentOS中安装Nextcloud出现“内部服务器错误”里的做多半就好了。但是这次有所不同，之前是连登录页面都看不到，只要访问就报错，而这次只有登录后才会报错。
Nextcloud是模块化设计，登录后由Files这个APP负责目录的呈现，而登录后一般是直接跳到Files页面。而且虽然Web界面报错，但是WebDav和客户端仍然工作正常，所以在了解了一些情况后，我怀疑是Files出了问题，遂检查其目录权限。
然而鼓捣了半天，报错犹在，似乎已成疑难杂症。转念一想，在更新之前这个Nextcloud实例是没有问题的，因为更新导致权限错误的可能性很小。那么，会不会是Files在更新时出现文件损坏呢？
OCC中有一个app:check-code命令，用它检查Files app，列出了一堆错误：
刚开始十分欣喜，以为找到了问题的根源，赶紧向对方报告了这一情况。不过仔细看一下，这些错误是由PHP报出的而不是来自Nextcloud自检，尚不能认为这些错误与故障是否直接相关。作为对比，我在官方Docker镜像上进行了同样操作，结果同样看到了类似的输出。
因为时间很晚了，难以细究，我仍然认为文件受损的可能性最大，建议重装。Nextcloud重装还是比较简单的，然而夜里一点钟发来消息：重装后依然报错。其实在这里，应该想到可能和数据库有关。
本来打算在Nextcloud社区和Github Issues发个Issue求助，有没有人回应就听天由命了。第二天中午发Issue时偶然看到Nextcloud社区的一篇求助：[Solved] NC12 - Internal Server Error after login。
真的是山重水复疑无路，柳暗花明又一村。
按照4楼的办法尝试之，问题解决。
问题起因
Nextcloud的oc_filecache没有正常运作，无法再缓存新的数据。这一问题可能是更新导致的。Nextcloud也没有针对这一问题的预防方案。
解决过程中的障碍
最大的障碍是Nextcloud的日志中的内容：“JSCombiner:can not cache Merge.js”，这个记录与故障直接相关是没错，却将我误导进了权限的深坑，现在看来，还是斗争经验不足啊。
还有是这个问题低频性，很难复现，可以查到的资料也寥寥无几。 |
