最近在使用群晖的时候遇到了一点困难，解决过程耗费了不少精力，但也有所得，记录一下，也许对有类似经历的人会有所帮助。
1、事情的起因
前段时间，看到群晖提醒有DSM7.0更新，很多人都不建议升级，特别是dcoker不兼容，考虑docker一旦出问题，它上面运行的大量服务都有麻烦，这个处理过程会累死人的，所以选择忽视，但群晖每天提醒，强迫症犯了，选择更新，有几个套件有点问题，按网络上的方法基本解决了，docker各项服务运行正常并没有报错，但在启动nextcloud用onlyoffice编辑文章时，出现以前编辑文章无法保存的问题，表现为文件的打开、关闭、保存动作一切过程都能进行，且没有报错，但将保存过的文件重新打开，发现新写入的数据并没有真正保存下来，新建文章却正常，反复确认系统各方面功能设置都没有问题，网络上找了半天也没有相关资料，初步认为是DSM造成的。
没有其它解决办法，想到的唯一方法就是先onlyoffice升级，升级过程正常，但升级后仍然有该问题，再考虑是nextcloud的问题，选择nextcloud升级，但进行升级后系统提示版本跨度太大，无法升级，也无法进入nextcloud工作界面。
2、重装nextcloud
2.1 利用最新的镜像重新建立nextcloud容器，始终无法连接MD10数据库，折腾了一天被迫改用sqlite数据库，系统正常安装完成。
2.2 重新集成onlyoffice，系统正常运行，不能保存问题解决。
3、恢复以前数据，问题重现
3.1 考虑到以前较长时间使用nextcloud，有不少老数据，尝试如何恢复，中间经历了无数次挫折，终于找到恢复数据的关键所在。
a 关闭容器，进入nextcloud的映射数据文件夹，删除除config文件夹和单个文件外的所有文件夹
b 用Hyperback从以前备份的数据中还原以上删除的文件夹
c 启动容器，进入系统，相关文件和组件基本都恢复，可能有的组件因版本升级无法兼容，如果用以前相同版本的镜像进行恢复，效果会非常好。
3.2 重新进入系统，编辑以前的文件，不能保存的问题重新出现。
这说明，恢复的文件中有限制onlyoffice的相关数据。
4、解决onlyoffice不能保存问题
这个问题网络上没有任何相关资料，只能自己研究nextcloud的相关配置和文件，经过摸索，找到解决办法。
在映射文件data/user项下的数据文件：
其中的onlyoffice、files_versions、files_trashbin中都有以前工作中保留的数据，files_versions大概就是历史版本信息，把这几个文件夹中的数据全部删除。
其中files_versions中保留了以前编辑文章的所有历史版本。
可能是nextcloud内部存在文件安全机制，DSM系统更新后新生成的数据写入请求不能被以前编辑的文章认可，禁止写入。
5、完整恢复nextcloud
虽然以上简单恢复了数据，但整个nextcloud并没有完全安装好，一是数据库没有恢复，以前的配置没有了，二是一直有报警，使用sqlite数据库不合适，三是用最新的镜像建立容器，很多组件无法运行。
5.1 重新下载以前版本的镜像，并建立容器，连接好MD10 数据库，按上述方法恢复运行。
5.2 关闭容器
a 按上述方法将映射数据中的相关文件夹删除，并按上述方法从备份中还原被删除的文件。
b 打开数据库，将nextcloud数据库导出为sql文件。
c 将nextcloud的数据库删除，再新建同名空数据，导入以上备份的数据库。
5.3 运行容器，基本除邮件外所有帐户信息均保留下来，问题最终解决。
小结：
1、DSM7.0 总体上没有大的问题，除了两个github上的专门应用无法更新，各项应用均较好运行，但似乎系统消耗比6.2版本要大一些。
2、 onlyoffice文件编辑中的不能保存问题由系统不兼容和文件写入权限造成，nextcloud的写保护问题只需要删除nextcloud保存的部分历史信息，解除系统对已经编辑过的文件的封锁。如果遇到文件写入权限问题在filestation中解决，升级DSM7.0后，权限管理与前版不同，这个也是造成这次困难的一个重要因素，解决问题大家多试试可以找出答案，因为不能写入的文件全部位于外挂存储中，以文件服务形式接入群晖就存在权限管理问题。
其实根本没有必要升级和重装onlyoffice及nextcloud，浪费了大量的时间和精力。
3、nextcloud安装中几个问题的解决
3.1 提示没有安装SMB，无法挂载SMB/CIFS外部存储，进入nextcloud系统后台，安装samba客户端，网络上有教程。
3.2 编辑文章时提示没有正确的解密文件私钥，原因是启用了客户端的文件解密，进入设置、应用，禁用系统默认的文件加密模块组件。
根据自己的理解，nextcloud有两套文件数据保护措施，一套是加密和解密机制，系统中启用加密服务器，在终端上利用私钥进行解密，这样编辑过的文件在系统外是不能打开的。另一套措施是系统内保护，在编辑文章时，系统记录了版本信息，也记录了系统和客户端的特有信息，当系统升级破坏了这些信息的认证，就表现为锁定原有文件，起到保护作用，如果将文件拷贝到系统外，能够被任何终端修改。
3.3 尝试过用nextcloud21、22等版本建立容器，各种方法都无法连接MD10数据库，但更早的版本很容易连接数据库，所以最后是利用原镜像恢复了系统，再升级到更新的版本。
3.4 建议升级新版本的onlyoffice，新版本对中文的支持很好，同时集成了相关插件，其中的google翻译是神器。
3.5 新版的nextcloud网络方面可能存在问题，外挂存储非常困难，原来SFTP可以用局域网地址连接，现在无法使用，外网用域名很难连接，偶尔网络可以通，基本连不上，只好改用IP地址，但公网IP几天就变一次很麻烦。另外用SMB连接出现dcoker莫名高负荷运行、提示网络连接不上，虽然外挂是正常的，但体验感觉非常不好。
追加记录
又经过了大概一个月的使用，期间做了大量的优化配置，回过头来再试一试上述遇到的问题，特别是SFTP的挂载问题，经过比较发现，可能以前的一些判断和结论是错误的，这里就不修改以前写的东西了，虽然是错误但这是一次值得记忆的经验。
升级以后，系统共享连接和外部挂载出现严重问题，一方面是群晖DSM进行了安全升级，SMB共享接入要求提高，很多以前的应用都反应连接不上。另一方面是nextcloud与DSM之间网络连接稳定性下降。所以基本上可以判断，nextcloud挂载连接不上和onlyoffice编辑中经常出现更名、保存时好时坏的原因是网络问题。
解决这个问题的思路不是改变两个系统的网络连接，而是要从nextcloud工作的基本原理上去改进。因为两个系统网络连接遵守基本的协议，如果不从底层进行重新配置是无法改变两者的基本连接，显然这个解决方案是不可行。
nextcloud工作基本原理与本地应用不同，它是基于网络和web的技术，从终端接受内容后先将数据写入缓存，然后再写入存储和变更数据库，读取内容也是通过网络协议请求读取数据存储并读取数据库中记录的状态。而本地应用工作时是通过操作系统直接写入存储。也就是说nextcloud的写入和读取都是间接的，中间要通过网络进行数据缓存和协议转发，如果网络出问题则读写操作会出问题，同时如果缓存出问题也会导致读写失败，或者两者配合不好也不行。
经过了系统优化后成功用SFTP进行外部存储挂载，并且工作稳定，期间的主要改变就是给nextcloud连接了redis缓存数据库，不但实现了稳定连接，且文件读取反应迅速，远程编辑时几乎接近了本地读写的速度，体验大幅提高。
这里也想到为什么独立的公有云办公体验是可以的，而个人搭建的云办公一般效果不太好，最主要是硬件、软件和系统配套都要跟上，个人很难在预算和知识有限的条件下建立一个保证性能的系统。