Synology NAS共享文件夹创建与权限配置、跨设备自动挂载实战指南

做运维这些年，我经手的Synology NAS少说也有几十台，每次帮朋友或客户配置共享文件夹，看起来就是个点鼠标的活，但真正踩过坑才知道，权限模型、访问协议、自动挂载这些环节，任何一个没处理好，后面都会被不停地问“为什么我访问不了”“为什么我改了文件别人也能动”。这篇文章不打算讲什么高深原理，就按我实际操作的顺序，把从创建共享文件夹到权限设置、再到各设备访问挂载的完整流程拆开揉碎，每一步都有截图级的操作说明和踩坑记录。无论你是家里有一台DS920+想给家人分目录，还是公司里用RS系列给部门做文件隔离，按这个流程走一遍，基本不会再被权限问题折腾。

我默认你机器上已经装好了DSM系统，版本以DSM 7.x为准。如果你还在用DSM 6.x，菜单路径略有出入，但底层逻辑完全一致，照着找也能找到。

1. 动手之前：先搞懂这三件事

1.1 检查存储空间和卷状态

很多人一上来就点“新增共享文件夹”，结果到选位置那一步发现卷是只读的或者空间不够，又回头去折腾存储池。建议先打开“存储管理器”，确认以下几项：

• 卷状态显示“正常”，不是“降级”或“已损坏”
• 卷剩余容量够用，我一般会留10%到15%的余量，防止快照和回收站把空间撑爆
• 如果开了Btrfs文件系统，顺便看一眼快照有没有把容量占满，快照超过卷容量上限会直接影响写入

这一步花不了一分钟，却能避免后面一半的报错。我自己就遇到过客户把共享文件夹建在一个快要满的卷上，结果回收站一开，三天就把卷塞满了，整台NAS所有服务全部变慢。

1.2 规划共享文件夹结构

创建之前，先在纸上画一下目录结构，这比什么都重要。我见过太多人建了一堆共享文件夹，名字叫“新建文件夹”，里面全是一堆没有分类的文档，最后自己也找不到东西。

以一个十人小公司为例，我通常建议这种划分：

• 共享根目录或部门目录：按部门建共享文件夹，比如财务部、人事部、研发部，每个部门一个顶级共享文件夹，权限在共享文件夹级别就隔离掉
• 公共交换区：单独建一个Public，所有人可读写，但不做归档，只当临时交换用
• 个人目录：每个用户建一个home目录，确保只有本人和管理员能访问
• 归档目录：建成只读，配合回收站使用，防止有人手滑删库

这样划分的好处是，共享文件夹本身作为权限边界，子文件夹再按项目细分，权限模型清晰，排障的时候看一眼文件夹就知道问题出在哪一层。

1.3 理清Synology的权限三层结构

Synology NAS的权限体系，说起来其实就三层：用户、用户组、共享文件夹/文件。你创建用户时给一个初始密码，然后用户归属到某个组，组再对应共享文件夹的权限。这个模型跟Windows域环境很像，但有一个关键区别，Synology默认使用的是Windows ACL风格权限，而不是传统的POSIX权限。

Windows ACL的好处是权限粒度细，能设置读取、写入、遍历、删除、修改属性等几十种细分权限，而且界面是图形化的，鼠标勾选就能搞定。坏处是很多新手不理解“继承”和“优先级”，以为在共享文件夹设置里给了权限就万事大吉，结果进到子目录发现还是没权限——这就是文件级ACL把共享文件夹级的权限给覆盖掉了。

所以在动手之前，你脑子里必须清楚一件事：Synology的最终有效权限，是共享文件夹权限和文件/文件夹ACL权限取并集还是交集，取决于“允许”和“拒绝”的设置。一般来说，拒绝优先于允许，而且在Synology里，共享文件夹级别的权限和文件级别的权限必须同时满足，才能访问。这个逻辑后面我会详细拆。

2. 一步一步创建共享文件夹

2.1 进入共享文件夹管理界面

打开DSM桌面，进入“控制面板”，找到“共享文件夹”图标。DSM 7的界面里，控制面板在左侧大图标里，点进去之后“共享文件夹”在“文件共享”分类下面。如果在列表里看不到，检查一下登录账号是不是属于administrators组，普通用户默认只能看到权限内的文件夹。

点击“新增”按钮，会弹出创建向导。这里有几个字段要特别注意。

2.2 填写名称和描述

名称是共享文件夹的“身份标识”，它会直接用于SMB路径和网络访问，所以规则比较严格：

• 只能使用字母、数字、下划线，不能有空格和特殊符号
• 建议全小写，因为某些老版本的SMB客户端对大小写敏感，全小写最省心
• 名称一旦创建，后面改起来很麻烦，客户端映射的路径都会变，所以取名要想好

描述字段是给人看的，想怎么填都行，但我会建议把用途写清楚，比如“人事部归档目录（2024-2025）”，不然过三个月你自己都忘了这个目录是干嘛的。

2.3 选择所在卷和启用回收站

接下来是选择所在卷，如果你的NAS只有一个卷，这里不用纠结，直接在列表里选中就行。如果像RS系列那样接了扩展柜，可能有好几个卷，那就按当前剩余容量来选。

然后会看到“启用回收站”的选项，这个我强烈建议勾上。Synology的回收站，在共享文件夹下面会生成一个#recycle目录，用户删除的文件先进那里，不会直接物理删除，能防手滑。回收站还附带一个“回收站有效期”功能，可以设置文件在回收站里保留多少天，到期自动清空，避免回收站把自己吃满。

2.4 协议、加密和高级设置

这一步选择该共享文件夹对外提供的访问协议，系统默认全选，我个人建议按需勾选即可：

• SMB：Windows和多数智能电视访问都用它，必开
• AFP：老款macOS还在用，新款也都支持SMB了，可以不开
• NFS：如果你有Linux服务器、虚拟机、或ESXi宿主要挂载，必须开
• FTP/WebDAV：外网远程访问才需要，纯内网环境可以不开
• 加密：基于卷级别的加密，如果创建卷时没启用加密，这里也选不了

高级设置里有两个值得注意的选项：一是“对共享文件夹启用访问时间记录”，会额外产生一些小文件，能帮你定位谁在什么时间打开了什么文件；二是“启用数据校验和”，会定期扫描文件完整性，对重要归档目录有用，但会增加一定系统负载。家用和小团队不建议全开，挑重要的目录开即可。

3. 权限设置的完整拆解

3.1 先建用户组还是先建用户

我的建议是：永远先建组，再建用户，最后给组分配共享文件夹权限。这个顺序，能让你的权限管理量从N个用户变成N个组。

具体操作是：打开“控制面板”的“用户组”，点击新增，输入组名，比如Finance。然后在“权限”页面会列出现有的所有共享文件夹，每个都可以勾选只读或可读写。这里注意看权限项，Synology提供“可读写”、“只读”、“禁止访问”三档，基本能满足大部分场景。

然后在“用户”里创建账号，创建时可以直接让用户加入一个或多个组，比如一个用户既属于人事部又属于管理层，那就勾选两个组。用户继承组的所有权限，再加上自己用户级有的权限，最终取并集。

3.2 共享文件夹权限的三档选择与拒绝优先

如果某个共享文件夹设置了“禁止访问”，那么这个组的所有人都进不去。哪怕你在文件夹级的ACL里单独给某个用户开了允许，最终结果依然是被拒绝。因为Synology的权限判定顺序是：先看共享文件夹层级的权限是否为“禁止访问”，如果是，直接拒绝，文件级ACL不参与后续判断。

所以建共享文件夹的时候，默认状态是“所有用户都不能访问自己没被分配权限的文件夹”，你只要在白名单里给对应组打勾即可。不要图省事把所有文件夹都设成“所有人可读”，后面隔离风险会很大。

3.3 文件级ACL：用File Station精确控制子目录

共享文件夹级别权限搞定了，接下来是文件级别的ACL。这个步骤很多人第一次会漏掉，或者搞反顺序。正确做法是：

1. 先打开File Station，进入共享文件夹
2. 右键点击子文件夹，选择“属性” > “权限”
3. 在这里添加用户或组，设置具体的Windows ACL权限
4. 关键一步：勾选“应用到所有子文件夹和文件”

如果不勾选“应用”，那么你设置的这个权限只对这个文件夹本身生效，里面的子目录和文件继承的还是上一级的权限。很多挂载SMB后“能进根目录但打不开子目录”的问题，都是因为没勾这个。

3.4 解析Synology组合权限的判定规则

这里我再用一个例子说明Synology最终有效权限到底怎么算。

假设共享文件夹HR的共享级权限里，用户小明属于HRGroup组，HRGroup被设置为“可读写”。HR的根目录下有个子文件夹“薪资表”，通过ACL单独设置了只有财务组可读写，并取消了HRGroup的继承权限。那么小明双击“薪资表”时，系统会先通过共享级权限判断，小明有进入HR的资格，然后进入子目录时，ACL会再判断一次，发现HRGroup没有这个目录的权限，所以最终被拒。

也就是说，共享文件夹级和文件级ACL是叠加生效的，两边都必须允许才能访问。这种设计一开始会觉得绕，但用久了反而放心，因为它提供了两道保险。

3.5 设置应用程序权限和家目录

DSM 7的权限设置里还有一个“应用程序权限”页面，简单来说就是控制某个用户或组能不能用File Station、能不能用Download Station、能不能用Synology Drive。如果你的共享文件夹给客户端通过Drive同步，需要确保用户的应用程序权限里勾选了Synology Drive，否则客户端能挂载SMB却同步不了。

家目录也要顺手开启。“用户家目录”功能开启后，每个用户登录DSM会自动得到一个以用户名命名的home目录，只有自己和管理员能进去，非常适合给每个人一个私网盘，配合Drive做个人文件同步很方便。

4. 不同设备的访问与自动挂载

4.1 Windows挂载SMB共享文件夹的正确姿势

Windows访问Synology共享文件夹，最常见的是映射网络驱动器。我的建议是不要用“网上邻居”去翻来找去，直接按下Win+R，输入完整路径然后勾选“使用其他凭据连接”再点击登录。

映射网络驱动器时，注意这一项：“登录时重新连接”，一定要勾上。不然重启电脑后，驱动器会变成红色的断开状态，每次都要手动重新连。如果你有多个共享文件夹要映射，建议单独建一个没有空格和符号的本地盘符来对应，比如Z映射给根目录，Y映射给财务目录。

4.2 macOS连接SMB和AFP的差异

macOS连接Synology相对简单：打开Finder，按Cmd+K，输入smb://NAS的IP地址，比如smb://192.168.1.100，然后选择要挂载的共享文件夹即可。如果找不到，检查一下NAS和Mac是不是在同一网段，或者防火墙有没有把SMB流量拦掉。

macOS这边有个小坑：如果你在DSM里只开启了AFP，那么Mac连上去默认用AFP协议，它支持的功能更多一些，但性能不如SMB 3稳定。2020年以后的新款macOS已经默认偏重用SMB，所以建议在Synology的“文件服务”里把AFP关闭，只保留SMB，这样能减少一些奇怪的连接掉线问题。

4.3 Linux下通过CIFS挂载并处理重启失效

Linux环境访问Synology共享文件夹，最常用的是mount -t cifs挂载。举个例子，我想把192.168.1.100上的backup目录挂载到本机的/mnt/nasbackup：

sudo apt install cifs-utils sudo mkdir -p /mnt/nasbackup sudo mount -t cifs //192.168.1.100/backup /mnt/nasbackup \ -o username=backupuser,password=YourPassword,uid=1000,gid=1000,file_mode=0750,dir_mode=0750,vers=3.0

其中vers=3.0很关键，因为老款NAS默认可能协商到SMB1，而SMB1既慢又存在严重安全问题。uid和gid参数决定挂载后文件在Linux本地显示的所有者，如果你用宿主机上的某个普通用户去写，uid要写成那个用户的ID。

但很多人在这一步会遇到一个经典问题：cifs挂载共享文件夹重启后失效。原因很简单，mount命令只是临时的，重启后需要重新执行。解决办法是把它写进/etc/fstab：

//192.168.1.100/backup /mnt/nasbackup cifs credentials=/etc/nasbackup.cred,uid=1000,gid=1000,file_mode=0750,dir_mode=0750,vers=3.0,_netdev 0 0

注意credentials参数指向一个单独保存凭据的文件，别在fstab里直接写明文密码，不然任何人cat /etc/fstab都能看到。凭据文件格式为两行：

username=backupuser password=YourPassword

写完把权限收紧：

sudo chmod 600 /etc/nasbackup.cred sudo systemctl daemon-reload sudo mount -a

如果fstab配置正确，mount -a会直接挂上，后续重启也会自动挂载。还有一点，如果网络初始化比挂载晚，可以加_netdev参数，让系统在网络就绪后再尝试挂载，否则开机时会因为网络还没通导致挂载失败。

4.4 虚拟机共享文件夹与物理机互访

虚拟机场景下，很多朋友会把NAS共享文件夹直接挂给VMware虚拟机用。常见做法有两种：

第一种是通过VMware共享文件夹功能：在VMware Workstation或ESXi里，先保证客户机里装了VMware Tools，然后在虚拟机设置里找到“共享文件夹”，添加一个主机目录或NAS挂载点，再设置“启用此共享文件夹”。这样在客户机系统里，会多出一个/host或/mnt/hgfs的路径，可以直接读写。但这本质上是VMware的翻译层，性能一般，不适合数据库等IO密集型任务。

第二种是直接在虚拟机里用CIFS/SMB挂载NAS共享，这在Linux虚拟机里很常见，方式跟上一节linux挂载基本一样。如果你要让物理机和虚拟机共用同一份数据，比如开发环境，我更推荐这一种，延迟和性能都比VMware共享文件夹好。另外，如果Windows虚拟机访问NAS共享提示“找不到网络路径”，第一反应不是去看NAS，而是先确认虚拟机的网络类型是不是NAT，NAT模式下SMB广播经常不通，改成桥接模式就能解决。

5. 常见故障与排查技巧实录

5.1 故障速查表

下面这个表是我在实际排障中整理的高频问题，基本覆盖了90%的共享文件夹访问异常：

5.2 运维中最容易翻车的权限细节

第一个坑是“给用户单独分配了文件夹权限，但用户还是访问不了”。这大概率是因为用户的组权限里把这个共享文件夹设置成了“禁止访问”。组级禁止优先于用户级允许，所以哪怕你单独在用户里勾了可读写，也进不去。解决办法是把组权限改成“无”而不是“禁止访问”，再按需分配用户权限。

第二个坑是“明明设置了只读，用户还能删文件”。Synology的共享文件夹级“只读”，并不等于万无一失，因为你可以通过Windows ACL修改文件属性，甚至通过回收站间接删除。如果真要做严格只读归档，建议在共享文件夹层勾选“只读”，同时在该目录的ACL里不要给该用户“删除”权限和“修改属性”权限，双管齐下才保险。

第三个坑是“回收站文件不占用户配额”。很多人以为删掉的文件在回收站里无所谓，但它是实实在在占用卷空间的。如果开了用户配额，回收站里的文件也计算在配额中。我建议定期用计划任务清理过期回收站内容，或者直接开启回收站有效期。

5.3 权限设置失败的玄学问题

有时候在权限设置时，会看到类似“应用程序特定权限设置并未向在应用程序容器不可用SID中运行的地址”这种报错。这通常是因为ACL里残留了已删除用户的SID，或者来自域控/虚拟化环境迁移产生的旧安全标识符。你可以先用File Station把该目录的权限全部重置为“继承父级”，再重新添加用户和组，一般就能清掉。

5.4 我从一次生产环境事故里学到的

最后说一段真实经历。有一次客户反馈财务部目录里的报表被人改了，我登上去一看，发现销售组的组权限里，共享文件夹财务目录被设成了“可读写”，但在子目录ACL里又只给了销售组“读取”。看起来好像没问题，问题出在财务目录的上级部门目录上：财务目录虽然是独立共享文件夹，但客户把它建在了另一个共享文件夹下面，然后父级共享文件夹设置了“所有人可读写”，导致子文件夹ACL的仅读限制被继承逻辑给绕过了。

那次之后，我给自己定了一条铁律：所有部门级目录，一律建为顶级共享文件夹，不要嵌套在其他共享文件夹里，父级不留人，所有权限只在自己这一层和文件级ACL里设置。从那以后，再也没出现过类似的越权问题。

根据我个人经验，Synology共享文件夹的权限管理，真正要花时间的不是点那几个按钮，而是前期规划和遇到权限冲突时的排查思路。按我上面的流程，先建组、再建用户、共享文件夹层面隔离、文件级ACL精确控制、最后配合fstab和回收站，一套下来，不管是家用还是小团队都够用了。最后再分享一个小技巧：每次大改动前，去“控制面板-更新和还原”里把配置备份一下，改坏了能一键还原配置，不用重新配一遍用户和权限，省下的时间够你喝好几杯咖啡了。