VS Code SSH调试VirtualBox内Ubuntu18.04 C程序报Permission denied错误

核心根因（90%以上同场景匹配） #

你的可执行文件存放在/vagrant路径下，这是Vagrant+VirtualBox默认的宿主机-虚拟机共享文件夹挂载点，vboxsf类型的共享目录默认以noexec参数挂载，该参数会禁止挂载点内所有文件的执行权限，和文件本身的rwx权限位、gdb运行身份无关，哪怕文件权限设为777也会触发Permission denied报错。

修复步骤 #

• 先确认挂载属性：执行命令查看/vagrant挂载参数

mount | grep vagrant

如果输出结果包含noexec字段，即可确认是该问题。

• 临时生效修复：执行命令重新挂载，开启执行权限

sudo mount -o remount,exec /vagrant

执行完成后直接重试VS Code调试即可，无需修改文件权限、无需用sudo运行gdb。

• 永久生效修复：在Vagrantfile中添加挂载参数配置，避免虚拟机重启后配置失效

config.vm.synced_folder ".", "/vagrant", mount_options: ["exec"]

保存后执行vagrant reload重载虚拟机配置即可。

其他遗漏排查点 #

如果上述方法未解决问题，按以下顺序排查：

• 检查文件格式与架构匹配度
  执行命令确认可执行文件是当前系统可运行的格式：

file /你的可执行文件完整路径/point

正常输出应匹配你虚拟机的CPU架构（64位x86系统应输出ELF 64-bit LSB executable, x86-64），如果是32位程序但未安装32位运行库、或是为其他架构/系统编译的二进制（如Windows exe、ARM架构程序），也会报Permission denied，这类情况需要在虚拟机内重新编译适配当前系统的可执行文件。

• 检查其他挂载点的noexec属性
  如果可执行文件不在/vagrant路径下，同样用mount | grep 对应挂载目录命令检查所在挂载点是否带noexec参数，参照上面的remount命令重新挂载开启exec权限即可，常见触发场景包括自定义tmpfs分区、NTFS/FAT32格式的外接存储挂载。
• 检查安全模块拦截
  Ubuntu 18.04默认启用AppArmor安全模块，自定义规则可能拦截gdb调试或共享目录程序执行，可临时关闭测试是否为该原因：

sudo aa-teardown

如果关闭后调试正常，针对性调整AppArmor规则即可，不建议长期关闭安全模块。

你提到的GDB: Failed to set controlling terminal警告是VS Code C/C++扩展调试层的已知提示，不影响核心调试流程，无需额外处理。

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