将 Nextcloud 与 Storage Server 连接：容量、配额与共享

Nextcloud 能做到 Storage Server 做不到的一切：管理用户、给每个人分配单独的额度、共享文件夹、生成带密码和有效期的链接，并通过 HTTPS 把文件送到浏览器。而让 Nextcloud 变贵的是容量，因为容量在服务器的 NVMe SSD 上。

把两者放在一起，就是实践中最终胜出的那种架构：Nextcloud 跑在一台小服务器上，文件放在 Storage Server 上。本文介绍两种配置方法，说明哪一种在什么情况下更好，并指出过程中一定会遇到的那些坑。

为什么这个组合这么合适

对很多项目来说决定性的一点是：Storage Server 没有按子账户划分的配额。子账户虽然只待在自己的目录里，但在那里面可以把整个套餐塞满。Nextcloud 解决的正是这一点，因为在那里每个用户都会得到一个硬性额度。

两种方法，以及哪一种更好

方法 A：Nextcloud 自己通过内置的 SMB 或 SFTP 驱动访问存储。不需要动操作系统。

方法 B：您在操作系统里把存储挂载成一个目录，然后在 Nextcloud 中为这个目录建立一个类型为“本地”的外部存储。

如果您有 root 权限，就选方法 B。绕道文件系统明显比 Nextcloud 的 SFTP 驱动更快，在小文件很多时尤其如此，而且它更能挺过网络波动。方法 A 适用于您不能或不想改动操作系统的情况。

准备工作：一个专用的子账户

请在客户中心为 Nextcloud 单独建一个子账户，并给它自己的起始目录，例如 /nextcloud。只开放您真正会用到的那一个协议。此外请在“访问设置”里确认外部可访问性已开启，否则服务器访问不到存储。

本文的示例使用下面这些值，请替换成您自己的：

方法 B：挂载后作为本地存储使用

先说挂载。在 Debian 和 Ubuntu 下：

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=YOUR_PASSWORD\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

接着是写入 /etc/fstab 的条目，这样它能挺过重启：

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

三个重要的选项：uid=www-data 让 Web 服务器有写入权限，seal 用 SMB 3 加密传输，而 _netdev 加上 nofail 可以防止存储正好没有响应时服务器卡在启动过程中。

mount -a
sudo -u www-data touch /mnt/storage/test && echo "写入权限正常"

之后在 Nextcloud 中启用应用“外部存储支持”，并登记这个存储，既可以在界面中经由“管理”下的“外部存储”完成，也可以在命令行完成：

sudo -u www-data php occ app:enable files_external
sudo -u www-data php occ files_external:create 数据 local null::null -c datadir=/mnt/storage
sudo -u www-data php occ files_external:list

现在“数据”文件夹会出现在您为其开放的用户那里。开放范围按用户或按组控制，这样不是每个人都能看到所有东西。

方法 A：直接在 Nextcloud 里配置外部存储

没有 root 权限时，不挂载也能做到。使用 SMB 需要对应的 PHP 扩展：

apt install -y smbclient php-smbclient
systemctl restart php8.3-fpm

然后在“管理”下的“外部存储”里新建一个条目：

如果用 SFTP，就改选类型“SFTP”，主机填 u123456.storage.kernelhost.net，端口填 23。这是这种方法里最常见的出错原因：Nextcloud 建议 22，而我们的存储监听的是 23。

为每个用户分配配额

接下来是让整个架构站得住脚的部分。在“管理”下的“用户”里为每个账户填一个额度，例如 50 GB。或者用命令行：

sudo -u www-data php occ user:setting fotograf1 files quota "50 GB"

Nextcloud 在计算时会把版本和回收站一并算进去。这样做是对的，但常常让人意外：拿到 50 GB 又上传了 50 GB 的人，会因为旧版本很快占用得比预想的更多。对那些经常替换而不是不断新增的账户，限制版本的保留时间是值得的。

给自己网站用的共享链接

在 Nextcloud 看来，外部存储和其他文件夹没有区别，所以共享照样可用。带密码和有效期的链接三次点击就能生成，而文件是通过 Nextcloud 送出的，不是直接从存储上送出。也就是说，您的存储凭据永远不会离开服务器。

这正是单靠一台 Storage Server 所缺的那块拼图。如果您运营的网站带下载区，这里一次就能得到用户管理、权限和文件分发，而且不用自己写程序。不用 Nextcloud 的替代方案是什么样，可以看 把 Storage Server 用在自己的网站上。

一定会遇到的四个坑

• 数据目录不该放在存储上。技术上可行，实践中却很危险：Nextcloud 也会在那里写入锁文件和中间状态，网络短暂中断一次就会让整个实例瘫痪。作为外部存储时，故障只影响那一个文件夹。
• 数据库留在本地。永远如此。存储上只放文件，别的都不放。
• 配置 Redis。没有用于文件锁的缓存，带外部存储的 Nextcloud 会明显变慢，因为每个锁都要经过数据库。
• 端口是 23，不是 22。用 SFTP 时 Nextcloud 建议 22。我们的存储监听的是 23，而相应的错误提示帮助不大。

选哪台服务器、选哪个套餐

Nextcloud 本身用一台小机器就够了。文件反正在别处，服务器只负责管理：从几个人到几十个活跃用户，只要 Redis 在跑、后台任务也配置好了，4 到 8 GB 内存就够。相关教程见 在自己的服务器上安装 Nextcloud。

存储的选择取决于容量需求：

所有 Storage Server 都在德国，支持 SMB、SFTP、WebDAV 等协议，最多可建 100 个子账户，并自带快照。免安装费、预付、无最低合约期。容量需求增长时，您可以直接换到更大的套餐，不用动数据。