使用gcloud compute scp递归传文件无报错但GCP实例找不到内容

高频踩坑点与对应处理 #

• 最高发诱因：~路径的用户身份不匹配
  别默认gcloud scp解析的~和你手动SSH登录后看到的~是同一个路径：gcloud compute scp执行时，会自动用本地gcloud配置绑定的账号去认证VM端的登录身份，这个身份对应的家目录，和你手动SSH登录用的短用户名的家目录往往是两个完全独立的路径（比如gcloud自动认证的身份路径可能是/home/xxx@gmail.com/，手动登录的用户路径是/home/xxx/），文件实打实传到了前者的目录里，你在后者的目录里翻肯定找不到。
  排查操作：直接执行gcloud compute ssh foo --command="ls -la ~"，输出的目录内容就是刚才scp实际写入的位置。
  解决方式：传输时别依赖自动解析的~，直接写绝对目标路径，比如gcloud compute scp --recurse ./local-repo foo:/home/你的SSH登录用户名/；找到文件位置后也可以直接在gcloud ssh的会话里把文件挪到你常用的登录目录下。
• 配置偏差导致传错了同名实例
  gcloud scp执行时如果没显式指定项目、区域参数，会自动匹配当前gcloud配置的默认项目、默认区域下的同名VM。如果你手动SSH登录的foo实例属于其他项目、其他区域，相当于文件传到了另一台完全不相干的机器上，自然找不到。
  排查操作：先执行gcloud config list核对当前生效的默认项目、区域配置；再执行gcloud compute instances list --filter="name=foo"列出账号下所有叫foo的实例，对比scp执行时日志输出的实例区域、IP和你手动登录的实例是否一致。
  解决方式：执行scp时显式绑定参数，写清楚目标实例的所属项目、所在区域，避免匹配错实例，比如gcloud compute scp --recurse ./local-repo --zone=目标实例所在区域 --project=目标实例所属项目 foo:~/。
• 递归传输的路径嵌套bug
  旧版本gcloud组件有个老问题：当目标路径下已经存在和本地传输目录同名的文件夹时，递归传输会把本地目录嵌套写入到目标目录的同名文件夹下，形成~/local-repo/local-repo的双层嵌套结构，只扫第一层目录就会误以为文件没传成功。
  排查操作：在VM内执行find / -name "local-repo" -type d 2>/dev/null，全盘检索传输的目录名，定位实际存放位置。
  解决方式：把gcloud组件升级到最新版本再执行传输；传输时明确指定目标存放的具体子路径，避免自动嵌套。
• 多通道SSH的路径隔离问题
  如果VM开了OS Login或者多通道SSH访问配置，gcloud scp默认走的公网/IAP通道认证的用户身份，和你手动通过内网/第三方SSH客户端登录的会话所属用户身份不一致，两个会话的家目录属于独立的挂载分区，就会出现“传输没报错但当前会话看不到文件”的情况。
  排查操作：分别在scp触发的gcloud ssh会话、手动SSH登录的会话中执行whoami和echo $HOME，对比两边的用户身份、家目录路径是否完全一致。
  解决方式：所有访问VM的操作统一用gcloud CLI完成，别混用第三方SSH客户端的连接配置；传输时直接写入指定的绝对路径，不依赖会话内的家目录变量解析。

小技巧：执行scp时可以加-v参数打开详细输出日志，能直接看到VM端实际的文件写入路径，不用反复翻目录排查。

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