用 NC 客户端同步文件，1G 左右的文件同步报错，修改 apache 的 php.ini 和 NC 的.user.ini 文件解决了。我把 upload_max_filesize ，post_max_size 和 memory_limit 都修改为 16G 了，连一个 3.6G 的文件都同步不了。请问有遇到过类似问题的筒子吗？
报错：Class 'OC\Log\ExceptionSerializer' not found at ./nextcloud/web/lib/private/Log.php＃318
搜索过这个问题，github 上也没看出一个明确的解决方案。

实在解决不了，怕是还得折腾 seafile ，悲催……

apache 的 LimitRequestBody 也要提高

1.传输文件的大小，与 upload_max_filesize 、post_max_size 、memory_limit 这些参数，其实都没什么关联。无论分时还是切片，都可以绕过这些东西。

2.我很怀疑，NextCloud 连个传输文件都做不好，checksum 这种事情，它更不可能做了吧？

3.搜了一下，隔壁 ownCloud 也有这个问题。

4.不过回头想想，这种开源软件开发商，本质上其实就是个前端公司，技术实力并不是他们的强项，他们的主要任务是，提供一个罗永浩式的可用的功能，然后主要精力是美化软件。几年前 syncthing 连文件同步逻辑都没做好。真要技术强了，早就去做商业化了，干嘛还开源。

5.所以，不建议用这些玩意同步你的重要数据。如果一定要，外面打个包，zip 都行，这样自己还可以检查数据的正确性，或者在解压时被动检查。另外自己还要再搞一套文件备份机制，别拿它当做备份。

我主流的 self-hosting 網盤基本都用過，最後還是得群暉 + Seafile ，Seafile 拿來掛載使用非常 nice ，群暉則拿來同步檔案。

nextcloud 传大文件的时候, 是有点折腾, 一个是 httpd 的一些设置, 你已经改了.

另一个可能是: nextcloud 默认分片传输, 所有分片传完后, 后台会执行复制来合并分片, NVMe 这种还好, HDD 容易超时... 可以关闭分片试试.

最后: nextcloud 的核心功能有大问题, 慎用... 不知道现在解决动不动读取整个文件内容这个 bug 没有.

nextcloud 最大的问题是大版本升级很容易升挂,不能跨版本升级,如果跨了大版本,不会有提示然后系统就挂了

如果你走的是 CF ，你可以直连试试

说下我的经历，我最大上传过 12 G 的文件没出现问题，你可以先看下官方指导里说的一些设置对不对。 docs.nextcloud.com/server/latest/admin_manual/configuration_files/big_file_upload_configuration.html

还有看下 Nextcloud 的后台检测结果，是不是什么配置没弄好？如果没弄好的话它会有提示的。

＃1 seafile 客户端传输文件时候需要提前切片，web 传输文件需要服务器切片，多人同时在 web 端传输大文件的话，会耗尽服务器 CPU 资源。

seafile 还是适合做文本文档小文件备份，大量大文件（如视频、照片）没有极致的版本管理需求的，不太合适。

我用了 3 年 seafile 社区版，最终还是换回群辉。手机客户端找文件比 seafile 方便（企业版才能搜索）。

我也是同步大文件出错，我按照这个修改了的
www.wuwenlong.net/archives/220
看起来是比你的多改了一行：

max_execution_time=0＃默认是 30 秒，改为 0 ，表示没有上传时间限制

我用 NC 这种的原因就是出问题自己能修，而且能直接在线调。NC 这种算是最简单的架构。有一些基础，很多问题可以自己处理。数据也容易恢复。

类似 seafile 这种直接用 C 实现的，反正我是不会用的，因为不想花时间去看代码。

要防止文件损坏，建议用 raid 或者支持类似功能的文件系统，比如说 btrfs, zfs 这种。这个其实和同步是两个问题。

强调分布式都有这个问题，tidb 一开始的实现也是 QPS 因为 CPU 限制上不去，这个是很要命的。没有现成方案，要优化需要相当的技术，不是堆工时可以解决的事情。

我用的是基于 debian 的 UNAS ，一个国产 NAS 软件。挂载我用的 UNAS 自带的，之前也用它自带的同步，一直没有问题，但是这个同步软件没有移动端，所以才开始折腾

我看了一下，我的 php.ini 和.htaccess 文件里都没有这个选项，请问这个选项是在哪个文件的设置里？

看来要做好同步盘不容易啊。我之前用的 UNAS 自带的同步，用了几年，倒是没出问题，只是这玩意儿没有移动端

调稳定，就没打算升级，哈哈

不是的，我的测试都是在内网 ip 直连的

好的，谢谢，我确认一下。Nextcloud 小白，请问后台检测结果要在哪里看？

这个链接我打不开。但是这个应该不是问题，我内网测试的，max_execution_time=3600 ，这里不会超时。对了，请问您用得 NC 是哪个版本的？我的是 20.0.0 ，不止是不是后续版本解决了这个问题。我搜索报错信息，github 上有讨论过：
github.com/nextcloud/server/issues/24558

感谢大家的回复，我的问题解决了。最终的问题其实很简单。
官方文档里关于 output_buffering 的修改陈述是这样的：
Output Buffering must be turned off in .htaccess or .user.ini or php.ini
我之前看.htaccess 和.user.ini 里都已经设置为 output_buffering = 0 了，就没有在 php.ini 里设置，今天才发现其实不行。把 php.ini 里的相应项设置为 output_buffering = OFF 就正常工作了。目前测试过 7.3GB 的文件同步，没有发现问题。
再次感谢大家。

＃12 ＃14 是這樣的，Seafile 最大的問題我覺得倒不是 ＃9 所說的性能問題，畢竟以我的帶寬（ 1Gbps/1Gbps ）及樹莓派 4B 4G 的弱雞性能條件下，多人（ 5 人）使用的時候，CPU 也沒有超過 50%，一般都在 5~15%徘迴，系統是官方 64bit 。

Seafile 最大的問題是，它的手機 App 非常難用，特別是當打開一個存滿了照片或影片的資料夾，就會出現瀕臨卡死的狀態，得等到整個資料夾都 cache 下來以後才會恢復正常，這個沒辦法忍受，太難用了。

但是電腦的 App 我覺得算是目前同步盤中的佼佼者，速度快（ Seafile 同步完 5 萬個檔案細小零碎檔案以後，Synology Drive 才同步了 4000 多個檔案），穩定不吃性能（相較與 PHP 的 NextCloud 及 Synology Drive ，C 寫的 Seafile 完勝 ）。

特別是 SeaDrive ，緩存式的掛載非常舒服，我都拿來存截圖，永遠用不完的截圖空間（檔案會先存在本地，後臺上傳至 Server 後，且超過 Cache 留存條件，就會從本地刪除），哈哈哈。下面這張圖就是通過 Seafile 分享的。

結論，如果需要一個好用的手機 App ，還是乖乖買群暉比較好，Seafile 和 Synology Drive 配合使用。

附上我使用的 Seafile Image ⬇️ （純 Docker 容器）

github.com/ggogel/seafile-containerized

seafile 客户端是本地客户端切片再上传。如果你试过同步多个 超过 6G 的单文件的话，同步速度是没有 nextcloud 或者群晖快。这不是性能局限了，是他存储模式必须切块，小文件切块很快，大文件就得等等了。
web 端因为没有程序 必须服务器切块，所以就更局限了。
但我是因为手机端实在受不住才放弃它的。

您这个体验很细致。我的要求其实不高，只要同步稳定，不出错就行。负载的话，我的 NAS 是 8100CPU 和 16G 内存，就家人使用，客户端数量不超过 5 个，也基本不会同时同步大文件，所以不会有问题。要求很简单，但是要求部署好以后可以稳定运行。