问题现象：SSH 能登录，但所有命令都无法执行
在维护VMware ESXi 8.x 主机时，不少管理员都会遇到一个很迷惑的问题：SSH 可以正常登录，Shell 也能进入，但无论执行 esxcli、ls、cp、vim-cmd 还是常见的网络/存储排障命令，全部报错：
-sh: <cmd>: Operation not permitted
奇怪的是，esxtop、vm-support 却又能正常运行。
这种“能进系统却不能操作”的状态，很容易让人误以为是 root 权限异常、文件系统只读、系统损坏或安全策略冲突，很多时间都浪费在错误的排查方向上。实际上，在 ESXi 8.x 里，这种现象大多数并不是故障，而是安全机制导致的“预期行为”。
根本原因：ESXi 8引入Shell Sandbox安全机制
根据 **Broadcom 官方 KB 说明，ESXi 8新增了 Shell Sandbox（Shell 沙箱模式）。当该功能启用时，普通 ESXi Shell 会被限制执行权限，大部分系统命令都会被阻止，只允许少量白名单工具运行，目的是减少误操作风险、限制恶意脚本执行，并提升整体主机安全性和合规性。
可以用下面命令快速确认：
esxcfg-advcfg --get /UserVars/ShellSandboxEnabled
如果返回值为：
Value of ShellSandboxEnabled is 1
说明Sandbox已启用，此时出现Operation not permitted就完全属于正常现象，而不是权限问题。
官方解决方法：使用 supershell 执行命令
遇到这种情况，不建议直接关闭安全策略，官方推荐做法是使用 supershell 来执行命令，相当于通过受控方式临时提权。
用法示例：
supershell -c "esxcli network ip interface list"
supershell -c "vim-cmd vmsvc/getallvms"
supershell -c "ls /vmfs/volumes"
简单理解就是：所有原本报错的命令，前面套一层 supershell -c 即可正常执行。
虽然也可以手动把 /UserVars/ShellSandboxEnabled 设置为 0 来关闭限制，但生产环境并不推荐，这会降低主机安全等级，也违背 ESXi 8 的安全加固设计。
运维经验总结与常见搜索关键词
在实际运维中，如果你遇到以下情况：
- ESXi shell 无法执行命令
- esxcli 不能运行
- ESXi 提示 Operation not permitted
- ESXi 8 权限不足或命令被拒绝
- supershell 怎么用
基本可以第一时间检查 ShellSandboxEnabled。
记住一句话：ESXi 8 登录正常但命令全报错，十有八九是 Shell Sandbox，用 supershell 执行即可解决。 这也是目前新版本 ESXi 主机最常见、也最容易误判的排障场景之一。
VM技术助理
