文件拖拽功能依赖Parallels Tools拖放服务正常运行及权限配置：需确保prl-tools-dragndrop服务active并开机自启，用户加入prltools组，Parallels Desktop中启用双向拖放开关，且UOS安全策略允许相关通信。
文件拖拽功能在 parallels desktop 中不是“开箱即用”的自动行为，它依赖于客户机系统（如统信uos 1060）内 parallels tools 的拖放服务正常运行，并受操作系统级权限控制。若拖拽失败、卡顿或仅支持单向（mac→uos但反之不行），大概率是权限配置未到位。
拖放服务需启用且具备执行权限
Parallels Tools 安装后，其拖放服务（prl-tools-dragndrop）默认以 systemd 服务形式运行。统信UOS 1060 使用 systemd 管理服务，必须确保该服务处于 active 状态并拥有必要权限：
- 打开终端，运行
sudo systemctl status prl-tools-dragndrop查看服务状态；若为 inactive 或 failed，执行sudo systemctl start prl-tools-dragndrop并sudo systemctl enable prl-tools-dragndrop设置开机自启 - 检查服务单元文件路径是否为
/usr/lib/systemd/system/prl-tools-dragndrop.service，确认其中User=root和PermissionsStartOnly=true已正确设置，避免以普通用户身份启动导致权限不足 - 服务启动时会创建 Unix 域套接字（如
/var/run/prltools/agent.sock），需确保该路径所属用户和组为root:prltools，且权限为srw-rw----
用户会话需加入 prltools 组
拖放操作最终由当前图形会话的桌面环境（如 DDE）调用，而 UOS 默认未将普通用户加入 prltools 组，导致无法访问拖放服务通信通道：
- 运行
sudo usermod -aG prltools $USER将当前用户加入该组 - 重启用户会话（完全注销再登录，或重启虚拟机），使组权限生效；仅重启桌面环境（如
killall dde-session-ui）通常不够 - 验证是否生效：执行
groups命令，输出中应包含prltools
SELinux 或 AppArmor 并非默认启用，但需排除干扰
统信UOS 1060 默认使用自主可控的安全模块（类似 SELinux 的策略框架），虽不叫 SELinux，但可能限制跨进程通信：
- 临时测试可运行
sudo setenforce 0（若支持该命令）关闭强制模式，观察拖拽是否恢复；若恢复，说明策略规则需调整 - 更稳妥做法是检查
/var/log/audit/audit.log或dmesg | grep -i avc是否有拒绝日志，定位被拦截的 socket_connect 或 file_write 操作 - 无需手动编写策略，UOS 提供
uos-sec-policy工具，可运行sudo uos-sec-policy --allow-prl-dnd（如存在该子命令）一键放行
Parallels Desktop 端需同步开启双向拖拽开关
宿主机端设置常被忽略——即使客户机配置无误，若 Parallels Desktop 虚拟机设置中禁用了拖拽，仍无法工作：
- 关机状态下打开虚拟机配置 → “选项” → “共享” → 确保“启用拖放”已勾选，并选择“双向”而非“仅从 Mac 到 Linux”
- 若使用 Pro 版本，还需确认“高级共享设置”中未启用“限制拖放大小”或“禁用文件夹拖拽”，这些选项会静默拦截大文件或目录
- 更改后务必重启虚拟机，设置不会热生效
