QNAP QTS 故障排除

QNAP QTS 故障排除

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

今日在对文件进行归档操作时，NAS 警告 “The server is busy or the network is disconnected”.

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

[~] # 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）时发生错误 “Unmounting volume failed”。

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

# 停止各项应用服务
/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%。

[admin@nonPointer ~]# 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 查看 / 下各目录的使用情况。

[~] # 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 应用，把控好供应链安全。