NAS 上的目录到底谁是谁

刚上手一台 NAS 时最容易迷糊的事：同一个东西，在命令行里和界面里叫两个名字。

界面里看到「存储空间 1 / 我的文件」，SSH 进去看到的是 /vol1/1000；应用管理界面点「打开文件夹」，弹出 /vol1/@appdata/xxx，而进程日志里写的又是 /var/apps/xxx。这些都是真路径，只是指向同一个地方。

这篇把常见家用 NAS（以 fnOS 系为例，群晖/Unraid 思路类似）的目录结构梳理一遍。知道谁是谁，能省掉一半"我文件放哪去了"的问题。

第一层：存储空间

/vol1    存储空间 1
/vol2    存储空间 2

这不是分区挂载点，是"存储空间"的逻辑名。 空间里再按用户分目录：

/vol1/1000     uid=1000 的用户（一般是第一个管理员）家目录
/vol1/1002     uid=1002 的用户家目录

⚠️ 关键点：/vol1/1000 不是你"共享文件夹的上级目录"，是某个用户的家目录。 界面里显示的「admin 的文件」就是它。别的用户在界面里看到的是自己的目录，看不到这个 —— 除非有共享权限。

我踩过一次：以为 /vol2/1000/xxx 是"存储空间 2 的公共目录"，其实是 uid 1000 那个用户的家目录。用别的账号操作时路径对、权限不对，报 Permission denied。

第二层：应用目录（`@` 开头）

/vol1/@appdata/<app>     应用的数据（配置、数据库、缓存）
/vol1/@appconf/<app>     应用的配置（有的系统只有这一层）
/vol1/@apphome/<app>     应用的工作目录/家目录
/vol1/@appmeta/<app>     应用元信息（图标、版本、权限声明）
/vol1/@appshare/<app>    应用对外共享的目录（下载器的下载目录常在这）

几个实际影响：

这些目录的属主是应用自己的用户（比如 OpenList:OpenList），不是你。所以你删不掉 —— 不是权限配错了，是设计如此
/var/apps/<app> 通常是 /vol1/@app*/<app> 的软链，两个路径等价。在日志里看到的 /var/apps/... 就是它
应用的下载目录经常在 @appshare：比如某个下载器界面显示「/downloads」，实际落地是 /vol1/@appshare/<app>/Download

删应用的残留时：@appdata/@appconf/@apphome/@appmeta 这套要一起处理，只删一个会留下空壳。有些系统提供了"以管理员身份操作文件"的服务，可以借它删（普通账号不行）。

第三层：云挂载点

/vol02/1000-1-<一串hex>    某个云盘/远程存储的挂载点

特征很明显：/vol02（两位数）而不是 /vol1，后面跟 用户uid-序号-十六进制。

这类目录有三个坑，全都是我实际撞过的：

1. 不能直写

> 重定向、dd、tar -f 直接写进去，会报 Bad file descriptor，或者更糟：不报错，但产物是 0 字节。

bash

# ❌ 看起来成功，实际 0 字节
tar czf /vol02/1000-1-xxxx/backup.tar.gz ./data

# ✅ 先本地打包，再 cp 过去，并核对 md5
tar czf /tmp/backup.tar.gz ./data
cp /tmp/backup.tar.gz /vol02/1000-1-xxxx/
md5sum /tmp/backup.tar.gz /vol02/1000-1-xxxx/backup.tar.gz

2. 卸载云存储之后，目录删不掉

残留目录会一直在，删的时候报一个奇怪的 errno（我这边是 65280）。原因是云存储管理器还持有这条挂载记录，不是文件权限问题。正确顺序：先在系统界面的「远程挂载 / 云存储」里删条目，目录才会消失。

3. 事件日志能看到别人动过什么

很多系统有一个全局事件日志库（sqlite 格式），普通用户可读，记录所有文件操作。想查「这个目录里的文件什么时候被谁删的」，它比应用自己的日志靠谱。

第四层：临时与日志

/tmp              重启清空，别放持久数据
/var/log/apps/    应用日志（属主常是 root，普通账号删不动）

日志目录删不动是正常的，不影响使用。但它有个用处：排查"服务到底有没有在处理请求"时，第一手证据通常在这里。

一张对照表

界面里叫	命令行是	属主
存储空间 1	`/vol1`	root
某某的文件	`/vol1/<uid>`	那个用户
应用数据	`/vol1/@appdata/<app>`	应用用户
应用共享目录	`/vol1/@appshare/<app>`	应用用户
云盘挂载	`/vol02/<uid>-<n>-<hex>`	云存储服务

教训

这些路径没有一个是有"文档错"的，问题在于它们同时存在于三套视角里：文件管理器的、应用的、以及命令行的。

现在我的习惯是：涉及删除、迁移、备份之前，先在三个视角里各确认一次——界面里看到什么、ls -l 的属主是谁、软链指向哪里。

bash

ls -ld /var/apps/<app>        # 看它是不是软链，指向哪
readlink -f /var/apps/<app>   # 解析成真实路径
stat -c '%U %G %a %n' <path>  # 属主/组/权限

一句话版本：/vol1/<uid> 是某个用户的家目录，@app* 是应用的地盘（你删不掉），/vol02/... 是云挂载（不能直写）。看清属主和软链，再动手。

NAS 上的目录到底谁是谁 ​

第一层：存储空间 ​

第二层：应用目录（@ 开头） ​

第三层：云挂载点 ​

第四层：临时与日志 ​

一张对照表 ​

教训 ​