贴一下最近使用homemanager的rclone遇到的小问题|快乐幸运的万事屋

先放链接：

rc都知道config,为什么你mount不知道？还只有挂载根时有问题？

先在discourse上搞出的复现报告

https://discourse.nixos.org/t/rclone-mount-almost-identical-service-files-produce-different-auth-behavior-depending-on-unit-name/77405

当时我还没意识到是config读取的问题，只会用rc debug发现了一个挺让人无语的地方。哥们儿你rc都知道config了为什么不用，而且我就只有在根目录会出问题。

半角.和全角.意外发现的bug

经过测试，在vfs-cache-mode 不影响write时，完全正常，但是加上write就会爆炸

中间改过

rclone/vfs/nixnasoplst 
❯ ls -al                     
总计 12
drwx------ 1 hkl hkl  70  5月16日 22:27 .
drwx------ 1 hkl hkl  58  5月 4日 18:59 ..
drwx------ 1 hkl hkl 134  5月16日 22:10 ．

这已经不是一般的配置问题了，必须出重拳，挖开你代码库看看。

于是直接fork然后让LLM帮我看看代码库结构定位大概问题，结果发现只要改一行，就直接提交PR了

https://github.com/rclone/rclone/pull/9439

先让deepseek复现bug喊出WTF

被合并了开心捏

真相浮出水面

然后我死不悔改继续看看/到底有什么问题，rc时有一行引起我注意

那时候没截图，但大概是rc告诉我reload config xxx.

于是秉持着大胆怀疑的精神，设计一个config.right和config.wrong，然后在运行中途替换，当然，也得让opencode复现，的确是这样，rc重载显示正常，但是ls就I/O error

（中间又踩坑--daemon和--rc的冲突问题了，早知道该装一个opencode-pty）

接着觉得可以提一个issue了

https://github.com/rclone/rclone/issues/9441

然后，确定是时序问题后，

我原本以为oneshot和simple差不多，问了deepseek，又get一个知识点，oneshot真会等你返回的。原本还想改notify现在看来是不必了。

那么就看看是不是依赖的问题

systemctl list-dependencies后，发现惊人一幕

没有依赖rclone-config.service

于是继续扫最新home-manager,想着又能赚一个pr，blame一下发现Mar就修了

只是为什么%C/rclone能backport,这个不backport一下啊，

不过令人激动的NixOS release 26.05就要release了，我可以再等会然后让我直接flake更新过去，好耶。

这段时间，要么改ref要么就自己注意在ls前注意下restart一下吧。原以为自己又能拿下一个pr,不过感觉意外收获rclone的这个.的pr也不错。

最后让deepseek总结收尾吧

这个“神人问题”之所以如此曲折，根源在于一个极度隐蔽的bug组合，而你的理解恰恰点出了其中最精妙、最反直觉的一环。问题的核心确实不在于密码没有被读取，而在于 rclone 的内部缓存机制导致旧的错误凭证被“冻结”在内存里，无法被新的配置更新。

整个事件的完整时间线如下，它完美解释了为什么“rc config/dump”能看到新密码，但实际请求中却不见踪影。

📅 完整时间线

2026年5月4日 - 迷雾初现：用户在NixOS论坛报告，Home Manager生成的rclone挂载服务在挂载根路径 / 时认证失败，日志显示发送的请求中只有用户名，密码【完全丢失】。一个关键的细节是，密码是通过secrets.pass从外部文件加载的，且手动执行命令一切正常。
2026年5月17日 - 深入探索：用户在GitHub上提交了Issue #9441。问题的焦点开始从“密码丢失”转向 rclone配置热加载的深层Bug。核心开发人员ncw确认了问题的复杂性：
- 当配置文件外部改变时，rclone会重新加载，但负责实际请求的VFS层和文件系统缓存仍持有旧的Fs对象。
- 这意味着，即使rclone rc config/dump已返回新密码，mount进程的内存里依然是旧凭证。ncw坦言，要完全修复这个问题会面临巨大的并发控制挑战，是一个“locking nightmare”。
2026年5月19日 - 真相大白：
1. 第一层真相（时序问题）：用户在论坛更新了调查结果，指出根本原因在于 Home Manager的时序缺陷。旧版本的Home Manager在为rclone生成systemd服务时，没有设置对rclone-config.service的依赖，导致mount服务可能在配置文件（特别是从sops等外部源解密生成）准备就绪前就已经启动。
2. 为何/挂载如此特殊？ 这正是理解问题的关键。如果挂载的是子路径（如/test），rclone在启动时就会尝试访问该目录，因凭证无效而立即报错并重启。重启时配置文件已经就绪，因此问题被“绕过”了。但挂载根路径 / 时，rclone在启动初期不会立即访问远端，会一直等到第一次ls或读取操作时才发起请求。此时，即使配置文件后写入，rclone内存中的错误凭证也已固化，导致出现这种“明明配置对了，却始终认旧密码”的诡异现象。
3. 修复：Home Manager通过commit 3cea83b 修复了时序问题，为mount服务显式添加了Requires和After依赖。
2026年5月16日 - 环环相扣的另一个Bug：用户尝试用.（代表当前目录）作为绕过路径时，触发了另一个独立Bug（PR #9439）。该Bug会导致某些写入操作静默失败。这个修复也在此后被合并。