使用strace追踪sshfs FUSE挂载下npm ci的EPERM问题无FS调用输出

strace对FUSE是否有效？ #

strace完全可以追踪FUSE挂载目录下的系统调用，你没抓到node_modules相关调用的问题大概率出在跟踪参数或范围上，不是strace不支持FUSE。

为什么没抓到调用？ #

可能的原因：

• 线程跟踪不全：Node.js用pthread创建线程处理异步IO，strace -f只跟踪fork/vfork生成的子进程，不会跟踪线程。需要加-ff参数，让strace跟踪所有线程并将每个线程的日志输出到单独文件。
• 启动时机不对：如果是先启动npm ci再attach strace，会错过早期的open()调用，应该直接用strace包裹npm ci命令启动。
• 过滤范围太窄：如果没指定跟踪的系统调用类型，日志量太大可能你漏看了node_modules相关的记录，建议只跟踪open/openat这类和文件打开相关的调用。
• FUSE缓存干扰：sshfs默认有文件属性缓存，若Node的open()调用命中缓存，可能不会触发实际的FUSE请求，但这种情况一般不会返回EPERM，更可能是缓存的权限信息和实际文件系统不一致。

适用的调试工具与操作 #

1. 调整strace参数重新跟踪
   用以下命令精准跟踪所有线程的文件打开操作，同时显示文件描述符对应的路径：

   strace -ff -y -e trace=open,openat npm ci
   

   执行后会生成多个strace.<pid>文件，搜索其中的node_modules关键词就能找到对应的调用记录。

2. 用ltrace跟踪用户态库调用
   如果strace还是没抓到，可能是Node在用户态做了权限检查（比如通过libc的封装），用ltrace跟踪libc的open/openat调用：

   ltrace -f -e open,openat npm ci
   

3. 开启sshfs的调试日志
   直接让sshfs输出所有FUSE请求和响应，能直观看到哪个操作返回了EPERM：

   # 先卸载现有挂载，再重新挂载并开启debug
   umount /mnt/your-sshfs-mount
   sshfs user@remote-host:/path /mnt/your-sshfs-mount -o debug
   

   此时终端会输出所有FUSE交互日志，执行npm ci后搜索EPERM或node_modules即可定位问题。

4. 用auditd跨进程跟踪
   如果你用的是Linux系统，auditd可以全局跟踪文件操作，适合复杂场景：

   # 添加跟踪规则，监控node_modules目录的open操作
   auditctl -a exit,always -F arch=b64 -S open,openat -F path=/mnt/your-sshfs-mount/node_modules
   # 执行npm ci后，查看审计日志
   ausearch -i -m open
   

内容的提问来源于stack exchange，提问作者user22476690