NAS 上 Docker 部署 FreeCut：浏览器剪辑视频实战

1. 为什么要在 NAS 上跑 FreeCut 而不是用电脑剪辑

很多人第一次听到“NAS 剪视频”这个说法，第一反应是：NAS 那点性能，能剪得动吗？我一开始也是这么想的。直到有一次出差，手头只有一台轻薄本，素材全在 NAS 上，临时要出一版粗剪给客户看，才真正被逼着去研究这条路。结果发现，FreeCut 这类基于 Web 的剪辑工具跑在 Docker 里，实际体验比想象中顺得多，尤其是做切片、拼接、加字幕、导出这些轻量级操作，完全够用。

先说清楚 FreeCut 是什么。它是一个开源的在线视频剪辑工具，界面类似简化版的桌面剪辑软件，支持多轨道、裁剪、拼接、转场、字幕、音频处理这些基础功能。它最大的特点是跑在浏览器里，你不需要在每台电脑上装客户端，只要 NAS 上的 Docker 容器活着，局域网内任何设备打开浏览器就能剪。这对家里有好几台设备、素材又集中存放在 NAS 上的人来说，省掉了“下载素材到本地—剪完再传回去”这一整套来回折腾。

那为什么非要放在 NAS 上，而不是直接装在自己主力电脑上？我总结了几个真实场景，你可以对照看看自己是不是也中招：

• 素材集中存放：家里所有视频素材都在 NAS 的共享文件夹里，电脑本地硬盘根本放不下。传统流程是先把素材拷到电脑，剪完再拷回去，一个 4K 项目动辄几十上百 GB，来回拷贝的时间比剪辑本身还长。
• 多设备切换：台式机剪一半，想换笔记本继续，传统软件得把工程文件和素材一起搬过去，路径一变就全乱。Web 版工具天然没有这个问题，工程存在服务端，换台设备打开浏览器接着剪。
• 给家人共享：家里老人想剪个旅行视频，你不可能给每台电脑都装一套专业软件。浏览器打开就能用，学习成本几乎为零。
• NAS 常年开机：NAS 本来就是 7×24 小时开着的，Docker 容器随 NAS 启动，随时可用，不用像电脑那样还得先开机、等软件加载。

这里有个关键点要提前说清楚：NAS 剪视频的瓶颈不在 CPU，而在网络和硬盘读写。FreeCut 本身的计算量并不大，真正吃资源的是视频解码和转码。如果你的 NAS 是那种带核显的型号（比如常见的 Intel 赛扬、奔腾系列），Docker 里可以调用硬件加速，导出速度会快很多。如果是纯 ARM 架构的入门 NAS，做 1080P 的轻量剪辑没问题，但别指望它流畅处理多轨 4K。

提示：在动手之前，先确认你的 NAS 支持 Docker。群晖、威联通、飞牛 NAS、绿联这些主流品牌基本都支持，部分入门型号可能需要手动开启或安装 Docker 套件。玩客云这类刷机设备也能跑，但性能有限，适合练手。

我自己的环境是一台群晖 DS920+，Intel 赛扬 J4125，8GB 内存，装了 Docker 之后跑 FreeCut，局域网内用台式机和笔记本同时访问，1080P 素材剪辑流畅，导出 5 分钟的视频大概 2 到 3 分钟。这个成绩对于家庭使用来说完全够用。下面我把整个部署和使用的过程拆开讲，包括我踩过的坑和后来总结出来的优化技巧。

2. 部署前的环境盘点与 Docker 安装确认

在真正敲命令之前，有几件事必须先确认清楚，否则后面会卡在各种莫名其妙的地方。我见过太多人一上来就复制粘贴命令，结果容器起不来，回头排查半天，其实问题出在最基础的环境上。

2.1 确认 NAS 的 Docker 支持情况

不同品牌的 NAS，Docker 的入口和叫法不太一样。群晖叫Container Manager（旧版叫 Docker），威联通叫Container Station，飞牛 NAS 和绿联一般在应用中心里能直接找到 Docker 套件。你需要先确认两件事：

第一，你的 NAS 型号是否支持 Docker。一般来说，x86 架构的型号都支持，ARM 架构的部分支持。可以在品牌官网的产品规格页查，或者直接在应用中心搜“Docker”，能搜到就说明支持。

第二，Docker 套件是否已经安装并启动。以群晖为例，打开套件中心，搜索 Container Manager，安装完成后在套件里能看到“容器”“映像”“注册表”这几个标签页，就说明环境正常。

2.2 内存和存储的最低要求

FreeCut 容器本身占用的资源不大，但视频剪辑对内存和临时存储有要求。我建议的最低配置是：

这里重点说存储。FreeCut 在工作时会产生临时文件，如果 NAS 的系统盘空间紧张，建议把容器的数据目录映射到容量更大的存储池上。我一开始没注意这点，默认映射到了系统盘，剪一个 10 分钟的视频，临时文件把系统盘塞满了，NAS 直接报警。后来改成映射到大容量存储池，问题解决。

2.3 开启 SSH 并确认 Docker 命令可用

虽然群晖、威联通这些都有图形化的 Docker 管理界面，但用命令行部署更灵活，也方便后续排查问题。你需要先在 NAS 的控制面板里开启 SSH 服务。

以群晖为例：控制面板 → 终端机和 SNMP → 勾选“启动 SSH 功能”，端口默认 22。然后用电脑上的终端工具（Windows 用 PowerShell 或 PuTTY，Mac 用自带终端）连接 NAS：

ssh 你的用户名@NAS的IP地址

输入密码后登录成功，再确认 Docker 命令是否可用：

docker --version docker compose version

如果两条命令都能输出版本号，说明环境没问题。如果提示command not found，可能是 Docker 没装好，或者当前用户没有权限。群晖上需要用sudo提权：

sudo docker --version

注意：群晖的 Docker 命令路径可能不在默认 PATH 里，如果直接敲docker没反应，试试完整路径/usr/local/bin/docker，或者用sudo执行。

2.4 规划目录结构

在部署之前，先在 NAS 上规划好目录。我习惯在存储池的根目录下建一个docker文件夹，里面再按应用分：

/volume1/docker/freecut/ ├── data/ # FreeCut 的数据目录 ├── projects/ # 工程文件 └── media/ # 素材和导出视频

这样做的目的是让数据持久化。Docker 容器本身是无状态的，删掉重建很容易，但里面的数据如果没映射出来，就全丢了。把数据目录映射到 NAS 的物理路径上，容器升级、重建都不影响已有工程。

3. FreeCut 容器的拉取与启动配置

环境确认完毕，接下来就是核心的部署环节。FreeCut 官方提供了 Docker 镜像，我们可以直接用docker run或者docker compose来启动。我更推荐用docker compose，因为配置文件写一次，以后管理起来方便，改端口、加环境变量都直观。

3.1 用 docker compose 编写配置文件

在/volume1/docker/freecut/目录下新建一个docker-compose.yml文件，内容如下：

version: '3.8' services: freecut: image: freecut/freecut:latest container_name: freecut restart: unless-stopped ports: - "8080:8080" volumes: - ./data:/app/data - ./projects:/app/projects - ./media:/app/media environment: - TZ=Asia/Shanghai - PUID=1000 - PGID=1000 devices: - /dev/dri:/dev/dri

逐行解释一下关键配置：

• image：指定镜像名和标签，latest表示最新版。如果你追求稳定，可以指定具体版本号。
• restart: unless-stopped：容器意外退出时自动重启，除非你手动停止它。NAS 场景下这个很重要，保证服务常驻。
• ports：把容器的 8080 端口映射到 NAS 的 8080 端口。如果 8080 被占用了，改成其他端口，比如"8090:8080"。
• volumes：三个目录映射，分别对应数据、工程和素材。冒号左边是 NAS 上的物理路径，右边是容器内的路径。
• environment：TZ设置时区，PUID和PGID设置容器内运行用户的 ID，避免权限问题。
• devices：把 NAS 的核显设备映射进容器，用于硬件加速转码。如果你的 NAS 没有核显，或者不需要硬件加速，这一行可以删掉。

3.2 启动容器并验证

配置文件写好后，在同一个目录下执行：

sudo docker compose up -d

-d表示后台运行。执行完会看到类似这样的输出：

[+] Running 2/2 ✔ Network freecut_default Created ✔ Container freecut Started

然后用docker ps确认容器状态：

sudo docker ps | grep freecut

如果看到Up状态，说明启动成功。接下来在浏览器里访问http://NAS的IP地址:8080，应该能看到 FreeCut 的界面。

3.3 权限问题的排查与修复

我第一次启动的时候，容器是起来了，但访问界面报错，日志里提示“Permission denied”。这是 Docker 部署中最常见的问题，根源在于容器内用户和 NAS 上文件的所有者不匹配。

排查步骤是这样的：

先看容器日志：

sudo docker logs freecut

如果看到类似cannot write to /app/data的错误，就是权限问题。解决办法有两种：

第一种，确认 NAS 上映射目录的所有者。用ls -ln查看目录的 UID 和 GID：

ls -ln /volume1/docker/freecut/

输出里的第三列和第四列就是 UID 和 GID。把这两个数字填到docker-compose.yml的PUID和PGID里，然后重启容器：

sudo docker compose down sudo docker compose up -d

第二种，直接给目录放宽权限（不推荐，但省事）：

sudo chmod -R 777 /volume1/docker/freecut/

提示：chmod 777会让所有用户都有读写执行权限，安全性差，只建议在测试环境用。生产环境还是老老实实配 PUID 和 PGID。

3.4 硬件加速的开启与验证

如果你的 NAS 有 Intel 核显，开启硬件加速能显著提升视频导出速度。上面配置文件里的devices: - /dev/dri:/dev/dri就是把核显映射进容器。

验证是否生效的方法：进入容器内部，查看/dev/dri是否存在：

sudo docker exec -it freecut ls -la /dev/dri

如果看到renderD128这样的设备节点，说明核显已经映射成功。然后在 FreeCut 的设置里，把转码引擎选成硬件加速（如果有这个选项）。

我实测下来，开启硬件加速后，导出一段 5 分钟的 1080P 视频，时间从 4 分钟缩短到 2 分钟左右，提升接近一倍。这个差距在批量处理素材的时候非常明显。

4. 素材管理与剪辑工作流的实际搭建

容器跑起来只是第一步，真正决定体验的是你怎么组织素材和工程。NAS 剪视频和本地剪视频最大的区别在于，素材不在本地，所有读写都走网络。如果目录结构乱、网络不稳定，剪辑过程会非常难受。

4.1 素材目录的规划原则

我在media目录下按项目分文件夹，每个项目里再分raw（原始素材）、audio（音频）、output（导出）三个子目录：

media/ ├── 2024-旅行vlog/ │ ├── raw/ │ ├── audio/ │ └── output/ ├── 2024-产品宣传/ │ ├── raw/ │ ├── audio/ │ └── output/

这样分的好处是，FreeCut 里导入素材时，直接定位到对应项目的raw目录，不会在一堆杂乱文件里翻找。导出的时候也直接存到output，方便后续整理。

另外，素材文件名尽量用英文和数字，避免中文和特殊字符。我遇到过中文文件名在 Web 界面里显示乱码的情况，虽然不影响使用，但看着别扭，排查起来也麻烦。

4.2 在 FreeCut 中导入素材的正确姿势

打开 FreeCut 界面后，第一步是创建工程。点击“新建项目”，输入项目名称，选择保存位置（对应projects目录）。然后进入剪辑界面，点击“导入媒体”，会弹出文件浏览器。

这里有个细节：FreeCut 的文件浏览器默认从容器内的/app/media开始，也就是你映射的media目录。如果你把素材放在其他位置，需要先在docker-compose.yml里增加映射。

导入素材时，建议一次性导入整个项目的素材，而不是剪一段导一段。因为每次导入都会触发一次目录扫描，素材多的时候等待时间不短。我一般是在项目开始前，把所有要用的素材先拷到raw目录，然后一次性导入。

4.3 剪辑过程中的性能观察

剪辑过程中，你可以通过 NAS 的资源监控页面观察 CPU、内存和网络占用。以群晖为例，打开“资源监控”，看几个关键指标：

• CPU 占用：剪辑时一般在 20% 到 50% 之间，导出时会飙到 80% 以上。
• 内存占用：FreeCut 容器大概占 500MB 到 1GB，加上系统和其他服务，8GB 内存的 NAS 够用。
• 网络吞吐：拖动时间轴预览时，网络会有突发流量，千兆局域网下基本感觉不到卡顿。

如果发现预览卡顿严重，先检查是不是网络问题。用iperf3或者 NAS 自带的网络测试工具，测一下电脑到 NAS 的实际带宽。如果只有百兆，那卡顿是必然的，升级到千兆交换机就能解决。

4.4 多轨剪辑的注意事项

FreeCut 支持多轨道，但 NAS 的性能有限，轨道越多，预览越吃力。我的经验是：

• 1080P 项目：同时开 3 到 4 条视频轨没问题，再多就卡。
• 4K 项目：建议只开 1 到 2 条视频轨，而且素材码率不要太高。
• 音频轨：对性能影响很小，可以多开几条。

如果确实需要复杂多轨剪辑，建议先用 FreeCut 做粗剪，导出成中间文件，再用桌面软件做精剪。这样分工，既利用了 NAS 的集中存储优势，又避开了性能瓶颈。

5. 导出、转码与常见故障的排查链路

剪辑完成后的导出环节，是 NAS 剪视频最容易出问题的地方。导出涉及大量的 CPU 计算和磁盘写入，如果配置不当，要么速度慢得让人抓狂，要么直接失败。

5.1 导出参数的合理设置

FreeCut 导出时可以选择分辨率、码率、编码格式这些参数。我的建议是：

如果 NAS 支持硬件加速，编码选 H.264 能吃到核显的加速。H.265 虽然压缩率更高，但硬件加速支持不如 H.264 广泛，导出速度可能反而更慢。

5.2 导出失败的排查链路

导出失败是常见问题，我遇到过好几次，总结出一套排查顺序：

第一步，看容器日志：

sudo docker logs --tail 100 freecut

日志里通常会明确告诉你失败原因，比如“磁盘空间不足”“编码器初始化失败”“文件写入权限错误”。

第二步，检查磁盘空间：

df -h

导出过程中会产生临时文件，如果目标分区空间不足，导出会中断。我建议导出前确保至少有源素材两倍大小的可用空间。

第三步，检查权限：

ls -ln /volume1/docker/freecut/media/output/

确认容器内用户对输出目录有写权限。如果没有，参考第 3.3 节的方法修复。

第四步，检查硬件加速：

如果开启了硬件加速但导出失败，先临时关掉硬件加速，用软件编码试试。如果软件编码能成功，说明是核显驱动或映射的问题。可以尝试更新 NAS 的核显驱动，或者调整devices映射。

5.3 导出速度的优化技巧

导出速度受多个因素影响，我实测下来，按优先级排序是这样的：

1. 硬件加速：开启后速度提升最明显，能快一倍左右。
2. 素材码率：源素材码率越高，解码越慢。如果源素材是 50Mbps 的高码率文件，导出时间会明显增加。
3. NAS CPU 性能：这是硬瓶颈，J4125 和 N100 的导出速度差距很明显。
4. 磁盘写入速度：如果导出到机械硬盘，写入速度可能成为瓶颈。导出到 SSD 缓存盘会快很多。

我的做法是，把output目录映射到 NAS 的 SSD 缓存盘上，导出完成后再手动移到机械硬盘归档。这样导出速度能提升 30% 左右。

5.4 容器升级与数据备份

FreeCut 更新版本后，你可能想升级容器。升级前一定要备份数据目录：

sudo tar -czvf freecut-backup.tar.gz /volume1/docker/freecut/data /volume1/docker/freecut/projects

然后拉取新镜像并重建容器：

sudo docker compose pull sudo docker compose up -d

docker compose会自动检测镜像变化，重建容器。因为数据目录是映射出来的，工程文件不会丢。

注意：升级前最好先停掉容器，避免升级过程中有写入操作导致数据损坏。命令是sudo docker compose down，升级完再up -d。

6. 我踩过的几个坑和最后想说的

部署和使用 FreeCut 的过程中，我踩过几个坑，有些是配置问题，有些是认知偏差，分享出来希望能帮你少走弯路。

第一个坑：以为 NAS 性能不够，结果发现是网络拖后腿。一开始预览卡顿，我以为是 NAS CPU 太弱，差点放弃。后来测了一下网络，发现电脑到 NAS 的实际带宽只有 300Mbps 左右，原因是中间接了一个百兆交换机。换成千兆交换机后，预览立刻流畅了。所以遇到卡顿，先测网络，再怀疑性能。

第二个坑：容器重启后工程丢失。早期我没做目录映射，数据存在容器内部，结果一次 NAS 重启，容器重建，所有工程都没了。后来老老实实把data和projects映射到物理路径，再也没丢过。

第三个坑：中文文件名导致导入失败。有一次导入一批素材，FreeCut 界面里显示不出来，排查半天发现是文件名里有特殊字符。改成英文名后正常。虽然是小问题，但很耽误时间。

第四个坑：硬件加速没生效，白高兴一场。配置里加了devices映射，以为就开启了硬件加速，结果导出速度没变化。进容器一查，/dev/dri是空的，说明核显没映射成功。后来发现是 NAS 的 BIOS 里核显被禁用了，进 BIOS 开启后才正常。

最后分享一个实用技巧：如果你经常需要给视频加字幕，可以先用 FreeCut 导出无字幕版本，然后用 NAS 上的其他工具（比如 ffmpeg 容器）批量压制字幕。这样分工，FreeCut 负责剪辑，ffmpeg 负责批处理，效率比在 FreeCut 里一条条加字幕高得多。

NAS 剪视频这条路，适合的是素材集中存放、多设备切换、轻量剪辑这些场景。如果你追求极致的剪辑体验和复杂特效，桌面专业软件依然是更好的选择。但如果你想要一个随时可用、家人共享、不用来回拷素材的方案，FreeCut 加 Docker 这套组合，值得一试。