双十一买的 DX4600 Pro，玩了两个星期，系统基本被我摸明白了，非常逆天

这世上基本很难再找到负责 UGNAS 这么低能的产品经理了，从系统底层到套件处处透露着反人类的设定

我真心推荐感兴趣想买的用户尽量降低自己的需求，像我这样做纯仓储+网络协议访问+Jellyfin+自动追番的人都踩了一堆坑

但是真心说实话，如果只想买个本地的百度网盘，那还是很合适的，国产 APP 的手机套件不说别的，随便把几个老牌厂商体验吊起来打

我打算围绕这台东西写两篇文章，一篇深入分析系统，另一篇通过我踩坑的经验教人部署一点东西，目前不知道投哪里比较好，官方论坛什么用都没有，考虑去 smzdm 、酷安、知乎、v2 这些地方投

另外，这牌子买的水文真的太多了，全都是什么上手轻度使用，挂个硬盘开个 app 就直接好好好，就连竞品对比文都是坑，我写的东西全是自己摸索出来的，在公网上搜都搜不到，简单放点预览

（非常重要）权限模式与用户隔离

UGOS 的权限模式非常的奇葩，我在一个正常的 Linux 系统上从来没有见过这样的用法，并且这个系统软件的很多功能缺陷都是由权限模式导致的。

我把 UGOS 面向用户的服务套件叫做nas_server，暂且把它当作一个 service 级别的东西，那么我们有以下几个结论：

1. 套件的所有用户事务（登录、权限管理、软件数据隔离、存储区区分等）全部交由 nas_server 托管，与 Linux 系统的 user-group 机制脱钩

2. nas_server 自始至终在 UGOS 中以 root 身份运行

3. 每个登录到绿联私有云 APP 、并且连接到某台 NAS 上面的用户，会被 nas_server 单独分配一个用户 uid 数字，nas_server 依据此数字来管理用户对应的物理存储、维护用户私有数据，并且这个 uid 对用户不可见

   （注意，这里说的 uid 和 Linux user 的 userid 没有任何关系，我们后续会将这个 id 称为 ug_uid ）

4. nas_server 在文件管理时，只负责目录级别的可见性，不会负责 rwx 权限。严格来说，整个系统都没有对 rwx 做任何管理，默认都是 777 。

   目录级别的可见性，指的是它只会把你用户在/mnt/dm-0 存储空间中对应的文件夹单独展示出来，而不管文件夹中是否有任何权限不对、owner 不匹配的内容

5. nas_server 对文件的错误权限有恢复机制，当用户尝试通过套件访问存储空间里不属于它/权限不足的文件时，文件的权限会被强行修改为 root 777

   测试样例：root 登录 ssh 创建一个文本文件，将其 owner 修改为某个别的用户，权限修改为 755 ，移动到某个共享成员的存储空间内。成员通过套件内置的金山 WPS 打开文本后在 ssh 窗口 ls -l ，会发现文件被重置为 root 777

（重要）为什么只有管理员能开 SMB ？

这个问题是从我邀请家庭成员进入 nas 后探索目录时发现的。一开始我以为 nas_server 管理/mnt/dm-0 是简单地把所有文件都设为 root777 ，却惊奇地发现好像其他成员的文件夹 owner 并不一样，他们与文件夹同名，对应一串长长的数字，具体而言是 ug_uid+0000 。凭借着我对 Linux 浅薄的经验，去/etc/passwd ，以及其他地方找了很久都没有找到 username ，经过了大量的实验和思考之后我认识到了一件事情：

只有管理员开设的“网络服务”中的“账户”在 Linux 下是真实存在的，其它用户在 Linux 系统中不存在！

当你开通网络服务的账户后，你自己的 ug_uid 才在 Linux 系统下有真正的实体 user 对应，uid 和其他用户一样，都是 ug_uid+0000 ，而包括 SMB 在内的大量功能，需要依赖 Linux 的实体用户运行。因此，只有管理员能够开设 SMB ，并且出于隐私原因 SMB 也只能提供管理员的私人空间和公共空间。

所有想要折腾绿联 NAS 的人都必须记住这个结论，这个结论可以解释后面非常多不合理的地方。

nas_server 会自动将其它用户创建的文件 owner 设置成一个没有实体用户对应的 ug_uid+0000，以区分存储区 owner ，因为 Linux 系统是可以强制用 id 数字指派文件 owner 的。然而对文件指派 owner 似乎没有任何用处，可能是给内部其它服务进行区分，因为上面提到了，“文件管理”APP 只根据目录提供内容，根本不管 owner 是谁，错了就重置成 root 777 。

这套容错机制可以保证用户通过套件使用绿联私有云的时候不会出现奇怪的权限问题，但是对于 SMB 等严格遵守 Linux 用户权限规范的服务来说并非如此。举个例子，我现在使用 root 在自己的存储空间里创建了一个文本并填充了内容，将其权限改写成 755 ，通过 SMB 访问文件，修改并保存，会发现没有保存权限，记事本弹出“另存为”窗口。

这种情况会更多出现在某些 docker 镜像中，他们支持通过 PGID 和 PUID 环境变量指定 bind volume 产生文件的用户映射，并且假设默认的 permission mask 是 022 的话，产生的数据和配置文件通过“网络账户”登录的 SMB 访问是没有修改权限（ 755 ）的。

很显然，这套权限模式经不起系统级的全面开放访问，所以聪明的绿联产品经理想出了一个解决方案，那就是：

禁止非管理员使用 docker 和 smb 就好了，再在 docker 镜像管理页面里加上一条免责声明，出了问题不怪我哦。