先把因果关系理清楚,这能帮你少走弯路:可道云(KodBox)部署在 /www/wwwroot/file-viewer,是宝塔原生的 Nginx + PHP-FPM 部署,不在 Docker 里。 所以你做的那一串 Docker 清理(prune、truncate 日志、rsync 迁移)跟可道云 404 基本上是两件独立的事——除非可道云连的 MySQL 恰好跑在某个被 volume prune 清掉的 docker 卷里(这点后面单独确认)。

404 的关键信息是你说的"重启 nginx 之后出现的"。404 意味着 Nginx 本身在跑、网站配置也在,但它按规则去找文件/路由时找不到。按这个思路排查最快。

排查步骤

1. 先确认磁盘真的清出来了,文件还在

df -h                              # 确认 / 和 /home 都有空间了
ls -la /www/wwwroot/file-viewer    # 确认 index.php 入口还在

如果 index.php 不见了或目录是空的,那是清理/迁移误伤,问题性质就变了。

2. 看 Nginx 错误日志——这是最直接的答案

tail -n 50 /www/wwwlogs/file-viewer.log
tail -n 50 /www/wwwlogs/file-viewer.error.log

(文件名以宝塔里你这个站点的实际名为准,在 /www/wwwlogs/ 下 ls 一下。)日志会直接告诉你它在找哪个路径、为什么 404——是入口文件找不到,还是 rewrite 把请求导到了不存在的地方。

3. 检查"运行目录"和网站根目录

宝塔面板 → 网站 → 该站点 → 设置 → 网站目录 / 运行目录。重点看"运行目录"是不是被改了。KodBox 解压后入口在根目录的话,运行目录应该是 /,指错子目录会直接 404。

4. 检查伪静态

宝塔 → 站点设置 → 伪静态。如果之前配过 KodBox 的伪静态而现在空了或乱了,先临时清空伪静态再访问一次,确认是不是 rewrite 规则的锅。KodBox 不强制伪静态也能跑,所以清空后能进就说明问题在这里。

5. 检查 PHP-FPM 是否正常

磁盘满的时候 PHP-FPM 的 socket/pid 可能没正常起来。你只重启了 nginx,把 PHP 也重启一下:

# 在宝塔里重启对应 PHP 版本,或者命令行(版本号按实际改)
/etc/init.d/php-fpm-74 restart

6. 权限

如果第 1 步发现文件还在但访问异常,顺手确认属主:

chown -R www:www /www/wwwroot/file-viewer

关于你的 Docker 操作,一个要提醒的隐患

你的迁移流程其实没真正完成:你 rsync 到了 /home/docker,但 truncate 清日志走的还是 /var/lib/docker/...,说明 Docker 当前仍在用 /var/lib/docker。也就是说 /home/docker 只是一份拷贝,磁盘并没有因为迁移而释放(释放是靠 prune)。

如果你接下来打算真正切到 /home/docker,正确顺序是:先 systemctl stop docker → 再 rsync → 改 /etc/docker/daemon.json 的 "data-root": "/home/docker" → systemctl restart docker → 验证容器都在 → 确认无误后才删 /var/lib/docker 旧数据。在 docker 运行时 rsync 的数据是不一致的,别直接拿来用。

另外 docker volume prune 这步,如果可道云、图纸知识库或别的服务的数据库是用 docker 卷存的,而当时容器恰好是停止状态,卷可能被当成"未引用"清掉了。先 docker volume ls 看看该在的卷还在不在。

先从第 2 步的错误日志开始,贴出来我能帮你定位到具体原因。你方便的话也确认一下:可道云的数据库是宝塔自带的 MySQL,还是跑在 Docker 里?

日志把整个故障链讲得很清楚了,我按时间顺序还原一下,你就明白发生了什么:

故障时间线(日志说了什么)

① 06/25 16:58 — 磁盘写满,这是病根

2026/06/25 16:58:28 [alert] write() to ".../172.16.1.5_7777.log" failed (28: No space left on device)

No space left on device —— 磁盘满了。在这之前可道云一直是正常的(200 响应、WebDAV 都通)。

② 06/26 08:40 — 你清磁盘 + 重启后,变成 502

2026/06/26 08:40:55 [crit] connect() to unix:/tmp/php-cgi-74.sock failed (2: No such file or directory)

Nginx 想连 PHP,但 /tmp/php-cgi-74.sock 这个套接字文件不存在 —— 说明 PHP-FPM 7.4 进程根本没起来。这就是那批 502 的原因。注意这个 sock 在 /tmp 下,后面有用。

③ 08:41 之后 — 又变成 404,这是关键

2026/06/26 08:41:20 [error] "/www/wwwroot/file-viewer/www/server/stop/index.php" is not found

请求被导到了 .../www/server/stop/ 这个路径。/www/server/stop 是宝塔的"站点已停止"页面目录 —— 这意味着这个站点要么被置成了"停止"状态,要么它的 Nginx vhost 配置在磁盘满的那一刻被写坏了(磁盘满时正在写入的配置文件会被截断/损坏)。所以 root 指向了一个拼接出来的、根本不存在的 stop 路径,自然全是 404。

顺带说一句:那些 PROPFIND /index.php/dav/desktop.ini ... 404.html failed 是 Windows WebDAV 客户端在探测 desktop.ini 的正常噪音,可道云本来就没有 404.html,跟这次故障无关,忽略即可。

现在按顺序修

第一步:确认磁盘真的腾出来了(尤其是 /tmp 所在分区)

df -h

PHP-FPM 的 sock 建在 /tmp,如果根分区/或 /tmp 还是满的,PHP 永远起不来。先确认 / 有空间。你之前 docker system prune -a + truncate 清的是 /var/lib/docker,如果 docker 数据在根分区上,这步应该已经释放了——但还是看一眼确认。

第二步:把 PHP-FPM 7.4 拉起来

宝塔面板 → 软件商店 → PHP 7.4 → 重启(或先停再启)。然后验证 sock 出来了:

ls -l /tmp/php-cgi-74.sock
ps aux | grep php-fpm | grep 74

看到 sock 文件存在、有 php-fpm 进程,502 就解决了。

第三步:解决 404 —— 检查站点状态和配置

1. 宝塔 → 网站,看 file-viewer 这个站是不是显示"已停止"。如果是,直接启动。
2. 如果显示运行中但还是 404,说明 vhost 配置坏了。最稳的修法:进站点 → 设置 → 配置文件,确认 root 指向的是 /www/wwwroot/file-viewer、location / 里没有指向 /www/server/stop 的残留。看一眼这个文件有没有被截断:

cat /www/server/panel/vhost/nginx/file-viewer.conf

如果内容明显残缺或里面有 stop 路径,最省事的办法是在面板里把站点设置随便改一下再保存(比如改一下运行目录再改回 /),宝塔会重新生成一份干净的 vhost。

第四步:重载 nginx

nginx -t && nginx -s reload

nginx -t 先验证配置没语法错,再 reload。

小结

根因是磁盘写满这一个事件,引发了两个连锁后果:PHP-FPM 没自启(502)+ 站点配置被写坏或被置停(404)。修复就是:腾空间 → 起 PHP 7.4 → 启动/重建站点配置 → reload nginx,基本就回来了。

你先跑一下 df -h 和 ls -l /tmp/php-cgi-74.sock,把结果贴出来,我能帮你确认卡在哪一步。另外提醒一句:你那个 docker 迁移其实没真正生效(data-root 还在 /var/lib/docker,/home/docker 只是个拷贝),这次磁盘满八成跟它有关,等可道云恢复了建议把迁移正经做完,不然过阵子还会再满一次。

好消息:502 已经解决了,PHP-FPM 7.4 现在跑起来了(sock 文件在,master + pool 进程都在),磁盘也腾空了(/ 用了 57%,/home 才 3%)。剩下的纯粹是 404 —— 站点配置/状态的问题,跟我上一条判断的第三步一致。

而且我注意到几个有用的信息:

• //172.16.1.3/kodbox_data 挂载正常,你的可道云数据是在 NAS(SMB)上的,没丢,放心。
• Docker 现在确实在用 /home/docker/overlay2 了 —— 说明你这次是真把 data-root 切过去了,迁移生效了,这点比我以为的好。

现在定位 404 的根因

从上一条日志看,Nginx 把请求导到了 /www/wwwroot/file-viewer/www/server/stop/ —— 这是宝塔的"站点已停止"目录。所以基本可以确定:这个站点在面板里被置成了"停止"状态,或者它的 vhost 配置里被写入了 stop 规则。

先看一眼当前实际的 vhost 配置长什么样:

cat /www/server/panel/vhost/nginx/file-viewer.conf

重点看两处:

• root 是不是 /www/wwwroot/file-viewer(正常),还是被改成了 .../www/server/stop(被停了)。
• 文件内容是否完整,有没有因为磁盘满那一刻被截断。

修复

最省事、最稳的办法——在宝塔面板里操作:

1. 网站列表里找到 file-viewer 这个站,看状态。如果显示"已停止",点启动。
2. 如果显示运行中但仍 404,进站点 → 设置,把运行目录确认为 /(KodBox 入口 index.php 在根目录),保存。哪怕看起来已经是 /,也随便改一下别的设置再保存一次,强制宝塔重新生成一份干净的 vhost(覆盖掉磁盘满时可能写坏的那份)。

然后命令行重载:

nginx -t && nginx -s reload

nginx -t 通过再 reload。

验证伪静态(KodBox 需要):

站点 → 伪静态,确认里面是 KodBox 的规则。如果空了,贴一段标准的:

location / {
    if (!-e $request_filename) {
        rewrite ^/(.*)$ /index.php?s=/$1 last;
    }
}

(其实 KodBox 不强制伪静态也能跑首页,但补上更稳。)

先把 cat /www/server/panel/vhost/nginx/file-viewer.conf 的内容贴出来,我帮你确认是不是 root 被指到 stop 目录了——这是现在唯一需要确认的点,配置一对,reload 完就回来了。

配置文件不在那个名字下,很正常——宝塔的 vhost 文件名是按站点域名命名的,不一定叫 file-viewer.conf。先列出来看看真实文件名:

ls -l /www/server/panel/vhost/nginx/

你这个站是用 IP 访问的(http://172.16.1.5/),所以文件名很可能是 172.16.1.5.conf 之类。找到对应的那个,再 cat:

cat /www/server/panel/vhost/nginx/172.16.1.5.conf

（文件名以上一条 ls 的实际结果为准。）

同时确认一下站点是不是真被"停止"了

/www/server/stop 那个路径是宝塔的停止页占位目录。直接搜一下哪个配置文件里引用了它,能立刻定位问题站点:

grep -rl "server/stop" /www/server/panel/vhost/nginx/

如果某个 .conf 被 grep 出来了,说明这个站的 root 被改成了 stop 目录 —— 也就是它在面板里处于停止状态。

修复方向不变

定位到文件后,两种走法:

走法一(推荐,最稳):宝塔面板里操作 网站列表找到这个站 → 如果显示"已停止"就点启动;如果运行中,进设置把运行目录确认为 / 再保存一次,强制重新生成 vhost。这样不用手改文件。

走法二:命令行直接看 + 重载 先 cat 出真实配置确认 root 指向,如果发现指到了 stop 目录,在面板里启动站点后再:

nginx -t && nginx -s reload

先把这两条的结果贴出来:

ls -l /www/server/panel/vhost/nginx/
grep -rl "server/stop" /www/server/panel/vhost/nginx/

我就能确认是不是站点被置停了,以及对应哪个配置文件。

找到了,问题就在这张截图里——"运行目录"被设成了 /www/server/stop。

看截图:网站目录是对的(/www/wwwroot/file-viewer),但下面的运行目录写的是 /www/server/stop。宝塔把请求的实际根目录定在运行目录上,所以 Nginx 一直去 /www/wwwroot/file-viewer/www/server/stop/ 找入口文件,当然全是 404。grep 也印证了:只有 172.16.1.5_7777.conf 这一个站引用了 server/stop,就是它。

这通常是磁盘满或站点被异常置停时,宝塔把运行目录改成停止页留下的残留,后来没改回来。

修复(直接在这个弹窗里改)

把运行目录那一栏的 /www/server/stop 删掉,改成:

/

(就是一个斜杠,表示运行目录=网站根目录。KodBox 的入口 index.php 在根目录,所以运行目录必须是 /。)

然后点运行目录那一行右边的保存绿色按钮。保存后宝塔会自动重写 vhost 并 reload nginx,通常立刻就好。

验证

保存完刷新可道云页面。如果还想从命令行确认,看一眼配置里 root 是否回正:

grep -n "root" /www/server/panel/vhost/nginx/172.16.1.5_7777.conf

正常应该看到 root /www/wwwroot/file-viewer; 而不再出现 server/stop。

改完就应该恢复了。这一处是整个 404 的最后一环——前面 502 是 PHP 没起(已解决),这里 404 是运行目录被指到了停止页。两个都源于那次磁盘写满,修完就完整闭环了。

root 已经回正了（/www/wwwroot/file-viewer/，不再指向 stop），这一步对了。但还是 404，说明问题在配置的别处——很可能是 KodBox 的伪静态/rewrite 规则在磁盘满那次被写坏或丢了。

先把整个配置看一遍，重点看 location 段和 fastcgi 部分：

cat /www/server/panel/vhost/nginx/172.16.1.5_7777.conf

把内容贴出来，我帮你看 location 是怎么写的。同时确认几件事：

① 入口文件还在不在（磁盘满那阵可能被误伤）

ls -l /www/wwwroot/file-viewer/index.php

如果 index.php 不见了，那 404 就是文件本身丢了，性质就变了（需要从 NAS 或备份找回 KodBox 程序文件——注意 data/files 是数据在 NAS 上，但程序本体在本地 /www/wwwroot/file-viewer/）。

② 直接点名访问入口，绕开 rewrite

浏览器里访问 http://172.16.1.5:7777/index.php（注意端口是 7777，从配置文件名看出来的）。

• 如果 /index.php 能进、只有 / 进不去 → 确定是伪静态/rewrite 的锅，去站点设置补伪静态规则。
• 如果 /index.php 也 404 → 要么是文件丢了（看第①步），要么 location 配置坏了（看 cat 结果）。

先跑这两条，把 cat 配置内容和 ls index.php 的结果贴出来，基本就能锁定最后这一下了。

这下真相清楚了，问题有两个，缺一不可：

问题一：root 还是指向 stop（刚才那次保存没生效）

配置第 6 行实际是：

root /www/wwwroot/file-viewer/www/server/stop;

你之前 grep root 看到的是对的那行，但当前文件里 root 仍然指向 stop 目录。说明在面板里把运行目录改回 / 那一步没保存成功（或者保存后又被覆盖了）。

问题二：整个 PHP 引用被注释掉了，这是 index.php 打不开的根因

注意这一行：

#include enable-php-74.conf;

前面有 #，被注释了。这意味着 Nginx 根本没加载 PHP 处理规则——没有 location ~ \.php$ 把请求交给 PHP-FPM。所以你访问 /index.php 时，Nginx 不知道该把它交给 PHP 执行，直接当静态文件找，找不到就 404。这也是为什么 /index.php 同样打不开。

同理，伪静态那行也被注释了：

#include /www/server/panel/vhost/rewrite/172.16.1.5_7777.conf;

这整个配置基本就是宝塔"停止站点"时生成的残废版本——它故意去掉 PHP、去掉伪静态、把 root 指向 stop，目的就是让站点不工作。现在需要把它恢复成正常运行的配置。

修复（最稳的办法：让宝塔重新生成正常配置）

不建议手改这个文件，因为面板可能会再覆盖你。正确做法是在面板里把站点从"停止"状态正常化：

第一步：确认站点运行状态 看网站列表里 Kodbox 那行的状态。截图里显示"运行中▶"，但配置却是停止版——这种状态和配置不一致，往往是磁盘满时卡住了。处理办法：在列表里点状态那里，先停止、再启动这个站点（让它重新走一遍生成配置的流程）。

第二步：如果停启后还不行，改运行目录强制重写 进站点设置 → 网站目录 → 把运行目录从 /www/server/stop 改成 / → 点保存。保存后立刻验证文件是否真的变了：

grep -n "root\|enable-php\|rewrite" /www/server/panel/vhost/nginx/172.16.1.5_7777.conf

正常修好后这三行应该是：

root /www/wwwroot/file-viewer;          # 不再有 /www/server/stop
include enable-php-74.conf;             # 前面没有 #
include /www/server/panel/vhost/rewrite/172.16.1.5_7777.conf;   # 前面没有 #

第三步：确认入口文件在

ls -l /www/wwwroot/file-viewer/index.php

如果面板怎么改都改不动（保险方案）

万一面板操作一直无效（有时磁盘满会让面板数据库状态卡死），可以手动改配置救急：

# 先备份
cp /www/server/panel/vhost/nginx/172.16.1.5_7777.conf /tmp/7777.conf.bak

然后手动改三处：root 改成 /www/wwwroot/file-viewer、去掉 #include enable-php-74.conf; 的 #、去掉 rewrite 那行的 #。改完：

nginx -t && nginx -s reload

但优先用面板，手改后面板再保存还是会覆盖，治标不治本。

先试第一步「停止→启动站点」，再 grep 看那三行变没变，把结果发我。核心就是让那个 #include enable-php-74.conf; 的井号消失、root 不再指 stop——这俩一好，可道云立刻就回来。

好消息：站点配置完全修好了——你现在能看到 KodBox 的 PHP 报错，说明 root、PHP 引用、伪静态都对了，Nginx 已经成功把请求交给 PHP 执行、PHP 也找到并运行了 index.php。404 这一整条链彻底解决了。

现在这个是新的、独立的问题：KodBox 自己的配置文件 config/setting.php 内容被损坏了。

syntax error, unexpected ''add,edit,status,sort,remove,s' (T_ENCAPSED_AND_WHITESPACE)
config/setting.php[638]

T_ENCAPSED_AND_WHITESPACE 是 PHP 在解析字符串时遇到了语法错误——第 638 行附近有个字符串的引号/拼接坏了。这几乎可以肯定是磁盘写满那一刻，KodBox 正在写 setting.php，结果写了一半被截断，文件损坏了。

先看损坏现场

sed -n '630,645p' /www/wwwroot/file-viewer/config/setting.php

看 638 行那一段长什么样，多半能看到一个字符串没闭合（缺引号、缺逗号、或半行截断）。把这十几行贴出来我帮你判断。

修复思路（按优先级）

① 优先：从备份还原这个文件 这是最干净的办法。你之前 rsync -aP /var/lib/docker/ /home/docker/ 那次拷的是 docker，不含这个；但确认下有没有别的备份。另外 KodBox 通常有配置缓存，看看同目录或 config/ 下有没有 .bak 之类：

ls -la /www/wwwroot/file-viewer/config/

② 手动修复 638 行 如果只是单行截断，按 sed 看到的内容补好引号/分号就行。setting.php 一般是 return [ ... ]; 的数组结构，结尾必须闭合。看到内容才能给准确改法。

③ 兜底：重置 setting.php setting.php 主要存的是后台可改的系统设置（站点名、上传限制等），不含你的文件数据（数据都在 NAS 172.16.1.3/kodbox_data 上，安全）。实在修不好，可以参考 KodBox 默认的 setting.php 结构重建一份，损失的只是几项后台设置，重新在后台配一下即可。但先别急着重置，多半单行就能补好。

先跑 sed -n '630,645p' ... 把那段贴出来，我看一眼就能告诉你具体哪个字符坏了、怎么补。

确认了，文件就是被截断了。第 638 行停在半句上：

'admin.member.groupEdit'=> array('admin.group'=>'add,edit,status,sort,remove,switc

这一行没写完——字符串 'add,edit,status,sort,remove,switc 没有闭合引号，后面整个文件（数组剩余部分 + 闭合的 ); + 后续内容）全没了。文件大小正好是 32768 = 32KB，这是个非常典型的"写到一个块边界就被磁盘满掐断"的特征。所以这不是单行能补的，是从 638 行往后整段都丢了。

有几个关键的好消息：

• 你的文件数据在 NAS 上，完全没事。
• setting_user.php 这个文件还在、是好的（6/18 修改，365 字节），用户自定义设置在这里。
• setting.php 本质上是 KodBox 的权限/角色定义表（admin.xxx => array(...) 这种），属于程序自带的固定内容，不是你后台改出来的数据。所以最干净的修法是用一份完好的 setting.php 覆盖回去。

推荐方案：从 KodBox 源码取回完好的 setting.php

setting.php 在 KodBox 同版本里内容是固定的（你版本是 7.4 环境跑的 KodBox，version.php 里有具体版本号）。先确认版本：

cat /www/wwwroot/file-viewer/config/version.php

把版本号发我。然后两条路：

路径 A（最稳）：你手上有没有 KodBox 安装包/压缩包？ 当初宝塔部署时下载的 zip，或者从可道云官网下同版本包，解压后里面有完好的 config/setting.php，直接覆盖：

# 先备份损坏的
cp /www/wwwroot/file-viewer/config/setting.php /tmp/setting.php.broken

# 用完好的覆盖（路径替换成你解压出来的）
cp /解压目录/config/setting.php /www/wwwroot/file-viewer/config/setting.php
chown www:www /www/wwwroot/file-viewer/config/setting.php
chmod 755 /www/wwwroot/file-viewer/config/setting.php

路径 B：让 KodBox 自动重建 KodBox 的机制是——如果 config/setting.php 不存在，它会从内置默认模板自动生成一份新的。所以可以把损坏的文件改名让它"消失"：

# 备份损坏文件并移走（不是删除，留着保险）
mv /www/wwwroot/file-viewer/config/setting.php /tmp/setting.php.broken

然后刷新可道云页面。如果 KodBox 自动生成了新的 setting.php，问题就解决了。这是最省事的，先试这个。 注意生成后修一下属主：

ls -l /www/wwwroot/file-viewer/config/setting.php   # 看有没有自动生成
chown www:www /www/wwwroot/file-viewer/config/setting.php

我的建议

先走路径 B（mv 走损坏文件 → 刷新页面），最简单。如果 KodBox 没自动生成、报别的错，再走路径 A 从安装包覆盖。

不管哪条，损坏的原文件我都让你 mv 到 /tmp 而不是 rm，万一里面有你后台调过的个别设置（如站点名、上传大小限制），新文件生成后到后台重新配一下即可——但这些都是小事，数据本体一点没动。

先把 version.php 的内容发我，再试路径 B，告诉我刷新后是什么结果。