mergerfs预加载库在Docker环境中导致文件权限异常问题分析

问题背景

在使用mergerfs文件系统时，用户发现当通过LD_PRELOAD方式加载mergerfs的preload.so库时，在Docker容器中运行的qBit应用会出现文件权限异常问题。具体表现为某些配置文件被创建时权限位被清零（000），导致应用后续功能异常。

问题现象

在Arch Linux（包括aarch64和x86_64架构）环境下，当通过Docker运行qBit并预加载mergerfs的preload库时，会出现以下症状：

1. qBit创建的配置文件（如categories.json、feeds.json等）权限被设置为000
2. .torrent和.fastresume文件同样出现权限异常
3. 重启容器后，已添加的种子会从列表中消失（尽管实际文件仍然存在）

技术分析

经过深入调查，发现问题根源在于mergerfs的预加载库与qBit的文件创建机制存在兼容性问题：

1. qBit使用了O_TMPFILE标志创建临时文件，这是一种现代Linux系统提供的原子文件创建方式
2. mergerfs的预加载库在处理这类特殊文件创建操作时，未能正确保留文件权限属性
3. 问题不仅限于Docker环境，在原生系统中同样可以复现
4. 与mergerfs挂载点无关，问题出在预加载库对系统调用的拦截处理上

解决方案

项目维护者快速响应并提供了修复方案：

1. 专门创建了preload-tmpfile分支来解决此问题
2. 修改了预加载库对O_TMPFILE文件创建操作的处理逻辑
3. 确保在这种特殊文件创建方式下仍能正确设置文件权限

验证结果

修复后的版本经过多方面测试验证：

1. 在x86_64和aarch64架构上均测试通过
2. Docker环境和原生系统环境均恢复正常
3. 所有之前出现权限问题的文件现在都能正确设置权限
4. qBit的各项功能恢复正常运作

技术启示

这一案例为我们提供了几个重要的技术启示：

1. 预加载库(LD_PRELOAD)虽然强大，但需要谨慎处理各种系统调用场景
2. 现代应用可能使用多种文件创建方式，兼容性测试需要全面
3. 文件权限问题可能由底层机制引起，需要深入系统调用层面分析
4. 容器环境会放大某些系统兼容性问题

该问题的快速解决展现了开源社区响应和修复技术问题的效率，也为类似问题的诊断提供了参考范例。