Rsync同步含venv的文件夹后，设置777权限与修改属主仍无法在目标目录运行Python（权限拒绝）

兄弟，我之前也踩过类似的坑！结合你描述的操作步骤和报错信息，咱们一步步拆解问题、解决它：

先再明确下你的场景：

• 用rsync把带.venv虚拟环境的文件夹同步到远程Ubuntu 22 LTS服务器
• 在目标目录执行了source .venv/bin/python3（这里其实应该是source .venv/bin/activate来激活虚拟环境吧？不过先按你的操作来梳理）
• 创建空文件some_file.py，给目标目录递归设了777权限：chmod -R 777 .
• 跑python some_file.py时却碰到ERROR: [Errno 13] Permission denied，还提示监控目录是/home/taagcgaat/ollama_travel_assistant
• 已知rsync是3.2.7版本，SELinux已经禁用

可能的原因及对应解决办法 #

1. Rsync同步时没保留执行权限

Rsync默认不会自动同步文件的执行权限，尤其是像.venv/bin/python这种二进制可执行文件。哪怕你给目录设了777，如果文件本身没开执行位，照样跑不起来。

解决办法：
重新同步的时候加上--perms --executable参数，强制保留文件权限和执行属性：

rsync -avz --perms --executable 你的本地源目录/ 远程用户名@服务器IP:目标目录/

同步完后可以检查下Python可执行文件的权限：

ls -l .venv/bin/python

正常应该能看到-rwxr-xr-x这种带x（执行位）的权限。

2. 虚拟环境的路径依赖坑了你

虚拟环境是在你本地机器创建的，里面的activate脚本、python软链接都绑定了本地的绝对路径，同步到远程服务器后这些路径根本不存在，自然会出问题——哪怕权限全放开也没用。

解决办法（最稳妥）：
别直接同步.venv文件夹！换个思路：

1. 先同步代码，排除本地的.venv：

rsync -avz --exclude='.venv' 你的本地源目录/ 远程用户名@服务器IP:目标目录/

2. 到远程服务器的目标目录下，重新创建虚拟环境：

python3 -m venv .venv

3. 激活新环境并装依赖：

source .venv/bin/activate
pip install -r requirements.txt

这样创建的venv完全适配远程服务器，不会有路径冲突的问题。

3. 父目录权限拖了后腿

虽然你给目标目录开了777，但它的父目录（比如/home/taagcgaat）如果权限不够，照样会导致无法访问目标目录里的文件——Linux的权限是逐层校验的。

排查+解决：
先看父目录的权限：

ls -ld /home/taagcgaat

确保当前用户有读和执行权限（权限至少是drwxr-xr-x），如果不够就改：

sudo chmod 755 /home/taagcgaat

4. 监控目录的属主问题

报错里提到了监控目录/home/taagcgaat/ollama_travel_assistant，说不定你是用了自动重载工具（比如watchmedo）在跑脚本？这种工具对目录的属主有要求，哪怕权限是777，如果属主不是当前用户，也会报错。

解决办法：
先看目录的属主属组：

ls -ld /home/taagcgaat/ollama_travel_assistant

如果不是你的用户，就改成你的：

sudo chown -R 你的用户名:你的用户组 /home/taagcgaat/ollama_travel_assistant

个人建议先试第2种方法，重新创建venv是解决这类问题最省心的方式，毕竟同步虚拟环境本身就容易出各种奇奇怪怪的问题。

内容来源于stack exchange