QNAP QTS 故障排除

我所使用的 NAS 为 QNAP TS-551 @ J3355,文件系统采用 EXT4,与 Btrfs 相比具有更好的吞吐量与访问延迟。

今日在对文件进行归档操作时,NAS 出现无法访问的故障(见图一)。

刷新页面后,提示 Connection reset,而在此期间文件可以通过 Samba 正常访问,通过 SSH 查看到 CPU 与 IO 的各项指标都正常,执行 dmesg 查看内核消息缓冲区,也未发现异常情况。通过 vi 查看各应用日志时,终端出现 write error in swap file 报错,但检查发现 swap 分区基本是空的,内存也空闲 10G 以上,不该出现此错误。

1
2
3
4
5
6
7
8
9
10
11
[~] # uptime
21:28:37 up 26 min, load average: 5.32, 3.45, 2.81
[~] # iostat c
cpu
us sy wt id
28 13 4 54
[~] # free
total used free shared buffers cached
Mem: 10116140 4379452 5736688 289268 224628 2131248
-/+ buffers/cache: 2023576 8092564
Swap: 24542452 0 24542452

通过 CLI 执行 reboot 重启服务器后,访问 File Station 提示 System Message: network disconnected / Timeout。手动断开 HybridMount 中的云服务挂载后,在执行文件系统检查(基于 e2fsck)时发生错误(见图二)。

通过报错信息查询到一篇帮助文档:Examination Failed(Cannot unmount disk) Error,通过 CLI 进行文件系统检查的指令顺序摘录如下:

1
2
3
4
5
6
7
8
9
10
# 停止各项应用服务
/etc/init.d/services.sh stop
/etc/init.d/opentftp.sh stop
/etc/init.d/Qthttpd.sh stop

# 取消挂载并执行 fs 检查
umount /dev/mapper/cachedev1
e2fsck_64 -f -v -C 0 /dev/mapper/cachedev1
mount -t ext4 /dev/mapper/cachedev1 /share/CACHEDEV1_DATA
reboot

执行 umount 操作时,出现 error writing /etc/mtab.tmp: No space left on device 报错。由于存储池当前剩余空间超过 1TB,因此问题应该出现在系统挂载点上。使用 df 命令查看各挂载文件系统的使用状态,发现根目录使用率 100%。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[[email protected] ~]# df -h
Filesystem Size Used Available Use% Mounted on
none 400.0M 400.0M 0 100% /
devtmpfs 7.7G 8.0K 7.7G 0% /dev
tmpfs 64.0M 1.3M 62.7M 2% /tmp
tmpfs 7.8G 152.0K 7.8G 0% /dev/shm
tmpfs 16.0M 0 16.0M 0% /share
tmpfs 16.0M 0 16.0M 0% /mnt/snapshot/export
/dev/md9 493.5M 183.6M 309.9M 37% /mnt/HDA_ROOT
cgroup_root 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/cachedev1
6.8T 5.5T 1.3T 81% /share/CACHEDEV1_DATA
/dev/mapper/cachedev2
7.2T 2.2T 5.0T 30% /share/CACHEDEV2_DATA
/dev/mapper/cachedev3
98.7G 70.8M 98.1G 0% /share/CACHEDEV3_DATA
/dev/mapper/cachedev4
98.7G 60.3M 98.1G 0% /share/CACHEDEV4_DATA
...

参考 What do I do when my root filesystem is full?,使用 du 查看 / 下各目录的使用情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[~] # sudo du -hsx /*
0 /1
4.4M /bin
8.0K /dev
6.8M /etc
0 /flashfs_tmp
0 /hd_root_tmp
85M /home
58M /lib
0 /lib64
0 /linuxrc
0 /lost+found
60K /mnt
0 /new_root
8.0K /opt
0 /php.ini
0 /proc
132M /PT
4.0K /qumagiecore.log
0 /QVS
48K /root
0 /rpc
0 /run
21M /sbin
16K /share
0 /sys
1.1M /tmp
93M /usr
2.1M /var

发现问题所在:名为 PT 的目录应该位于 /share/PT 路径,而不该出现在 /。查看后发现目录存放有部分今天通过 QBittorrent 移动的数据文件,应该是对 Qbittorrent 的文件进行分类存放时,目标路径填写了 /PT 而非 /share/PT,导致 rootfs 被填满。手动删除目录后重启系统,发现 /share/PT 路径依然存在,推测原因是没有从 Qbittorrent WebUI 移除对应种子。手动移除后再次重启系统,成功完成文件系统检查,未见系统异常。至此问题得到解决,通过此事也发现 QTS 的一项安全性隐患:所有 QNAP App 都以 admin(在 QTS 中相当于 root)的最高权限运行。在此也警告各位用户:谨慎安装由第三方分发的 QPKG 应用,把控好供应链安全。