SFTP上传失败主因是用户身份、目录归属与SFTP会话机制不协同；SFTP权限在登录时锁定，su切换无效；root直连最简解法，普通用户需chown/chmod目标目录，并排查SELinux、只读挂载等高层限制。
上传文件失败，十有八九不是网络或软件问题，而是权限没对上——用户身份、目录归属、SFTP会话机制这三者没协同好，就会卡在“Permission denied”。
别指望su切换能救SFTP
很多人在FinalShell的SSH终端里输入su -或sudo su -切到root，就以为SFTP也能跟着升级权限。其实不行。SFTP连接一建立，权限就锁死在登录时用的那个用户身上，和你在终端里怎么切无关。
- SFTP是独立子系统，认证只发生在连接初期
- 终端里
su只是开了个新shell，不刷新SFTP会话 - 往
/etc或/root这种目录拖文件，普通用户登录的SFTP直接被拒，表现就是进度条不动、弹窗无提示、连接看似正常但传不进去
最省事：用root直连FinalShell
本地虚拟机、内网测试环境，安全可控，直接root登录是最干脆的解法。
- 新建连接时，“用户名”填
root，密码输root密码 - 连接成功后，SFTP面板和终端权限完全一致，拖文件进
/root/.m2/、/etc/docker/都畅通无阻 - 不用改配置、不碰SELinux、不设ACL，零额外维护成本
想用普通用户？那就把目标目录“认领”过来
如果坚持用普通账号（比如dev），就得让目标目录明确属于它：
- 运行
sudo chown -R dev:dev /opt/myapp，把整个目录及子项所有权转给dev - 再补一句
sudo chmod -R 755 /opt/myapp，确保目录可进入、文件可读执行、属主可写 - 若需更细粒度控制（比如只让
dev对某个日志目录有写权），可用setfacl -m u:dev:rwx /var/log/myapp
别漏掉SELinux和挂载限制
chmod和chown都做了还是传不上？看看是不是被更高层的安全机制拦住了：
- 执行
sestatus，如果输出enabled且enforcing，说明SELinux在起作用；临时验证可运行sudo setenforce 0，若上传立刻成功，问题就出在这 - 检查目标路径所在分区是否只读：
mount | grep $(df . | tail -1 | awk '{print $1}')，看有没有ro字样 - AppArmor用户可运行
aa-status确认是否有相关配置限制sftp进程
