Drive 里少了文件、File Station 里明明还在：列表不一致先重建索引

文件「消失」，但只在一个入口里消失

员工来报：共享盘里上个季度的图纸在 Drive 里翻不到了。管理员打开 File Station 一看，文件都在原位，SMB 映射进去也一清二楚。两边对不上的名单，问题基本可以定性——不在数据层，而在 Drive 的索引层：团队文件夹的目录台账与实际存储脱节了。

动手前先排除一种正常现象：Synology Drive 对文件类型有自己的支持范围，不在收录范围内的类型本来就不会出现在它的列表里。确认文件类型在支持范围之内、却依旧缺失，才轮到重建索引登场。

用任务计划跑一次官方重扫

重扫不需要装额外工具，用 DSM 自带的任务计划程序执行官方命令即可：

• 用 admin 账户登录 DSM，进入控制面板、任务计划程序、创建、计划任务、用户定义的脚本；
• 常规页给任务起名，账户选当前登录的 admin；
• 计划页选在以下日期运行，从当天开始、不要重复；
• 任务设置页把重扫命令贴进用户定义的脚本字段：

sqlite3 --json /var/packages/SynologyDrive/etc/repo/user-db.sqlite 'select view_id from user_table' | jq .[].view_id | xargs -I {} /var/packages/SynologyDrive/target/bin/cloud-control synotifyd-rescan --view_id {} --path /

保存后在任务列表里选中它，点运行，手动触发一次。这条命令会把所有团队文件夹挨个过一遍，扫描量随数据规模浮动。

配一个进度查询任务，盯到队列归零

扫描要跑多久取决于数据多少，官方建议再建一个查询任务来盯进度。同样在任务计划程序里再建一个用户定义的脚本任务（设置口径与上面相同），脚本字段贴这条：

/var/packages/SynologyDrive/target/bin/cloud-control synotifyd-status | grep -E 'Queue:|Total events in queue files'

跑完点操作、查看结果：队列文件总数后面显示 0，说明重扫已全部完成；不是 0 就过一会儿再跑一次查询，直到归零。归零之后回 Drive 里刷新，缺失的文件就该回来了。

一条纪律

重扫任务别设置成周期性自动运行——反复全量扫描会让 NAS 长时间高负载。按需手动跑，用完把两个任务删掉，需要时再建，这才是它的正确打开方式。

诚鑫致达科技接到「文件不见了」的工单，先问一句是在哪儿看的——Drive 里翻不到不等于盘上没有，两个入口对过再下结论，数据多半安好，乱的只是台账。