SFTPGo 权限模型与核心概念
重要提示：这一章只讲"这是怎么一回事"，不写操作步骤。如果你是第一次接触这套系统，先看完这一章再去看具体的操作文档。
为什么要先理解概念？
SFTPGo 的权限管理看起来复杂，但实际上它的逻辑是很清晰的。如果你不理解核心概念就直接去操作，很容易踩坑。花 5 分钟看完这一章，能帮你少走很多弯路。
核心认知：SFTPGo 的权限有两套体系
这是最容易混淆的地方，但也是最重要的认知：
Linux 文件系统权限 ≠ SFTPGo 权限
SFTPGo 不能绕过 Linux 文件系统权限。即使你在 SFTPGo 后台配置得再完美，如果 Linux 系统层面不允许访问，用户还是会被拒绝。
这两套权限是"且"的关系，不是"或"的关系：
- Linux 允许 且 SFTPGo 允许 = 用户能访问 ✅
- Linux 允许但 SFTPGo 不允许 = 用户不能访问 ❌
- Linux 不允许但 SFTPGo 允许 = 用户不能访问 ❌
打个比方：
- Linux 权限就像"大门的钥匙"，决定你能不能进这栋楼
- SFTPGo 权限就像"房间的门禁卡"，决定你能进哪些房间
如果你连楼都进不了，有门禁卡也没用。但即使你进了楼，没有门禁卡也去不了特定房间。
Virtual Folder：它是个"映射"，不是真正的目录
Virtual Folder 到底是什么？
Virtual Folder 不会创建真实的目录，它只是把服务器上的真实路径，"映射"成用户看到的一个虚拟路径。
举个例子：
- 服务器真实路径：
/srv/sftpgo/data/departments/tech/shared - 你创建一个 Virtual Folder，Virtual Path 设置为
/tech/shared - 用户登录后，看到的路径是
/tech/shared，但实际上访问的是服务器上的/srv/sftpgo/data/departments/tech/shared
Virtual Folder 不会做什么？
很多人会误以为 Virtual Folder 能自动创建目录，这是不对的：
- ❌ Virtual Folder 不会创建目录（需要在服务器层面先创建）
- ❌ Virtual Folder 不会修改服务器权限（这是 Linux 层面的工作）
- ❌ Virtual Folder 不会自动让用户看到（必须绑定到 Group 或 User）
Virtual Folder 的作用
Virtual Folder 的核心作用是"解耦"：
- 让用户看到的路径和服务器真实路径分离
- 方便未来调整服务器目录结构，而不影响用户的访问路径
- 一个服务器路径可以被多个 Virtual Folder 映射（虽然不常用）
Group：权限管理的核心载体
为什么 Group 这么重要？
Group 是权限管理的唯一推荐入口。你可以把它理解成一个"部门"或"权限集合"。
推荐的关系结构：
Virtual Folder → Group → User
为什么不直接 Virtual Folder → User？
虽然技术上可以，但不推荐，原因很简单：
- 难以批量管理：如果部门有 20 个人，你就要给 20 个用户分别配置。万一要改权限，你得改 20 次。
- 容易出错：人工操作多了，漏掉谁、加错权限都是常见的事。
- 不好扩展：新人加入部门，还要记得给他单独配置。万一忘了，他就有问题。
用 Group 的好处：
- 一次配置，自动继承：Virtual Folder 绑定到 Group，用户加入 Group，自动获得权限
- 批量管理：改一个 Group 的权限，所有成员都生效
- 清晰的结构：一个 Group = 一个部门，一目了然
Group 的权限优先级
重要：Group 的权限优先级高于 Virtual Folder。
这是什么意思？
- Virtual Folder 可能允许
upload（上传） - 但 Group 可以覆盖这个权限，设置为"只读"
- 最终用户受到的限制，以 Group 的配置为准
这个设计很合理：Virtual Folder 定义"这个目录能做什么"，Group 决定"这个部门在这个目录能做什么"。
User：永远不应该直接拿资源
User 的正确使用方式
User 应该通过加入 Group 来获得权限，而不是直接绑定 Virtual Folder。
推荐的流程：
- 创建 Virtual Folder（映射服务器路径）
- 创建 Group（部门）
- 将 Virtual Folder 绑定到 Group
- 将 User 加入 Group
User 会自动继承 Group 的所有 Virtual Folder 权限。
User 自己的 home_dir
User 有自己的 home_dir（个人目录），这个是例外。个人目录直接属于用户，不需要通过 Group。
但是共享目录，都应该通过 Group 来管理。
三层权限模型详解
SFTPGo 的权限实际上有三层检查，每一层都要通过，用户才能访问：
第一层：Linux 文件系统权限
检查者：Linux 操作系统
检查内容：
- 目录是否存在？
- SFTPGo 运行用户是否有权限访问？
- 文件/目录的读写权限是否正确？
这一层的责任人：服务器运维人员（System）
第二层：SFTPGo Virtual Folder 配置
检查者：SFTPGo 系统
检查内容：
- Virtual Folder 是否允许这个操作？（list、upload、download 等）
- Virtual Folder 的 Mapped Path 是否正确？
这一层的责任人：Admin（网盘管理员）
第三层：Group 权限
检查者：SFTPGo 系统（Group 级别）
检查内容：
- User 是否属于能访问这个 Virtual Folder 的 Group？
- Group 对这个 Virtual Folder 的权限设置是什么？
- Group 的权限是否覆盖了 Virtual Folder 的设置？
这一层的责任人：Admin（网盘管理员）
三层权限的检查顺序
用户请求访问文件
↓
【第一层】Linux 文件系统权限检查
↓ 通过
【第二层】Virtual Folder 配置检查
↓ 通过
【第三层】Group 权限检查
↓ 通过
允许访问 ✅
任意一层不通过，就会拒绝访问。
一个实际例子
假设用户要上传文件到 /tech/shared：
-
Linux 层检查：
/srv/sftpgo/data/departments/tech/shared这个目录是否存在？SFTPGo 运行用户能写吗？→ 如果不行，直接拒绝 ❌ -
Virtual Folder 层检查：Virtual Folder
/tech/shared是否配置了upload权限？→ 如果没有，拒绝 ❌ -
Group 层检查：用户是否属于能访问这个 Virtual Folder 的 Group？Group 是否限制了写权限？→ 如果没有加入 Group，或者 Group 设置为只读，拒绝 ❌
只有三层都通过，用户才能上传文件 ✅
一句话记住这套系统
服务器管「能不能」，Group 管「该不该」，User 只负责「用」。
- 服务器（Linux）：决定文件/目录是否"真实存在"且"可访问"
- Group（SFTPGo 中的权限组）：决定用户"是否应该"有权限
- User（最终用户）：只负责使用，不直接配置权限
常见误解澄清
❌ 误解 1："Virtual Folder 创建了，用户就能看到"
不对。Virtual Folder 只是定义了一个映射关系，必须绑定到 Group 或 User，用户才能看到。
❌ 误解 2："Linux 权限配置好就够了"
不对。Linux 权限只是第一层，还要配置 SFTPGo 的 Virtual Folder 和 Group。
❌ 误解 3："直接给 User 绑定 Virtual Folder 更方便"
不对。短期看可能快一点，但长期维护会很麻烦。用 Group 管理才是正确的方式。
❌ 误解 4："Group 权限和 Virtual Folder 权限是分开的"
不对。Group 的权限是覆盖 Virtual Folder 的。如果 Virtual Folder 允许 upload，但 Group 设置为只读，最终用户就是只读。
接下来该看什么？
理解完这些概念后，你可以根据你的角色去看相应的操作文档：
- 如果你是服务器运维人员 → 看 服务器层面 SOP
- 如果你是网盘管理员 → 看 Admin 管理 SOP
- 如果你需要使用 System 用户 → 看 System 用户指南
如果你遇到问题，可以查看 故障排查速查表。