Web 文件入口很方便，但挂载范围越大，误操作影响越大。

\n
FileBrowser 的优点很直接：不用给每台电脑都配置共享挂载，也不用临时开远程桌面，浏览器里就能上传、下载、改名、移动文件。也正因为太方便，它不应该被当成“整个 NAS 的万能入口”。在 HomeLab 里，我更愿意把它当作一个受限文件柜，只给固定目录、固定账号和固定操作范围。

只挂载需要暴露的目录

部署 FileBrowser 时最危险的写法，是把宿主机根目录、整个存储池或所有共享文件夹直接挂进去。页面上多一个目录，误删和误移动的半径就多一圈。更稳的方式是按用途准备一个入口目录，例如 /srv/filebrowser/share，里面再放 upload、exchange、family-docs 之类的子目录。真正长期保存的核心资料，可以通过后台任务整理进去，而不是让所有人直接在 Web 页面里操作。

如果只是给家人传文件，我会单独建一个交换区，容量有限、可清理、可快照。这样即使有人上传了错误文件或删除了目录，也不会影响其他服务的数据目录。FileBrowser 的便利性应该停在“文件流转”，不要直接伸到数据库、配置、证书、备份仓库这些位置。

权限要按账号分层

FileBrowser 自带账号和权限控制，但前提是宿主机挂载权限也要配合。容器内能看到的目录，应用账号不一定都应该能写。管理员用于维护目录结构，普通家庭成员只需要上传、下载、预览，某些账号只给只读访问。对外临时分享更要谨慎，最好使用有有效期和明确目录边界的分享方式。

宿主机层面我会避免用宽松权限解决问题。遇到无法上传或无法删除，先看容器运行用户、目录属主和实际挂载点，不急着把目录改成任何人可写。文件服务一旦被多个工具共用，权限会变成长期成本，第一天省掉的检查，后面常常会变成谁都说不清的访问异常。

上传下载边界要写清楚

上传不是越自由越好。家庭成员上传照片、文档、报销材料，和管理员上传服务配置，是完全不同的风险等级。我会把 FileBrowser 的上传目录设计成临时区，再通过人工或脚本移动到正式位置。下载同样要设边界：能下载共享材料，不代表能下载所有配置包和历史备份。

大文件上传还要考虑浏览器超时、反向入口限制和磁盘余量。页面显示上传完成，不代表后续整理流程已经跑完。我的做法是给交换区设置容量提醒，并定期清理过期文件；需要长期保留的资料，进入正式目录后再由备份系统覆盖。FileBrowser 负责入口体验，不能替代资料分层。

审计记录比页面好看更重要

多人使用时，审计能力会变得很实际：谁在什么时候上传了什么，谁删除了哪个目录，失败操作是权限问题还是空间问题。FileBrowser 的数据库保存账号、设置和部分状态，容器日志记录启动和请求异常，两者都要纳入维护范围。至少要知道数据库文件放在哪里，升级前能不能复制出来，恢复后账号和权限是否还在。

如果前面有反向入口，也应保留访问日志。不是为了盯人，而是在误删、异常下载、账号泄露怀疑出现时能还原时间线。没有日志的文件入口，出了问题只能靠记忆问人，最后常常变成“可能是谁点错了”。

Docker 目录和备份

FileBrowser 至少有两类目录：应用数据库目录和被管理的文件目录。前者小但关键，保存用户、设置和权限；后者大且变化频繁，应该按资料属性纳入独立备份。不要只备份容器 compose 文件，也不要只备份共享文件而漏掉数据库。恢复时页面能打开但账号和权限丢失，也是一种失败。

验收时我会做四个动作：用普通账号上传一个小文件，用只读账号确认不能写入，用管理员账号检查回收或删除策略，再从日志里找到对应操作。最后检查宿主机实际文件属主是否符合预期。FileBrowser 上线后，最好的状态不是功能很多，而是每个账号都只能做它应该做的事。

还有一个容易忽略的点是分享链接。临时分享应有过期时间，目录也要限制在交换区或公开资料区。不要为了省事把长期资料目录整块分享出去。分享结束后，最好能在审计记录里确认访问时间和下载范围，并把不再需要的链接清掉。

如果前面接了统一入口，还要单独测试大文件上传。很多问题不在 FileBrowser 本身，而在入口层的请求大小、超时和断开重试。测试时用一个小文件和一个接近日常上限的大文件各传一次，再确认失败时不会留下半截文件或错误权限。

目录配额也值得提前设。交换区没有容量边界，迟早会被临时文件塞满。