Permission denied: error code 3 — как исправить

В этой статье объясняется, как исправить сообщение “Permission denied. Error code: 3. Error message from server: permission denied” при попытке копирования или передачи файлов.

Это сообщение обычно означает, что сервер SFTP или клиент (например, WinSCP) вернул код ошибки 3 — доступ запрещён. Ниже — проверенные шаги и дополнительные рекомендации для безопасного и надёжного решения.

Как исправить ошибку доступа

1. Проверьте учётную запись

Убедитесь, что вы вошли в систему под нужной учётной записью. На Windows это может быть учётная запись с правами администратора. На Linux/UNIX — пользователь, у которого есть доступ к файлу или возможность эскалации прав (sudo).

• Если вы используете WinSCP, убедитесь, что в настройках подключения указан правильный пользователь.
• Если вы подключаетесь через SSH/SFTP, проверьте, не требует ли целевая директория прав владельца root.

2. Измените права доступа на файл или каталог

Важно: менять права нужно минимально необходимые. Не делайте 777 на продакшн-серверах навсегда.

2.1. Через SSH (Linux/UNIX)

1. Дайте только чтение и выполнение для всех (полезно для каталогов):

sudo chmod -R 755 /remote-dir/

2. Если требуется временная запись, можно открыть доступ (но отмените после):

sudo chmod -R 777 /remote-dir/

3. При необходимости измените владельца каталога на нужного пользователя:

sudo chown -R username:group /remote-dir/

После изменений повторите попытку передачи.

Примечание: chmod 777 даёт полный доступ всем пользователям. Это создаёт риск безопасности. Откатите права после завершения передачи, например, верните 755 или назначьте нужного владельца через chown.

2.2. Через PowerShell / CMD (Windows)

1. Нажмите Win + X и выберите “Command Prompt (Admin)” / “Windows PowerShell (Admin)” / “Terminal (Admin)”.
2. Выполните команду, чтобы дать полный доступ для “Everyone” рекурсивно:

icacls "C:\path\to\directory" /grant Everyone:(OI)(CI)F /T

3. Нажмите Enter.

Замените C:\path\to\directory на реальный путь, например C:\Users\Username\Documents\Project.

Важно: дача прав Everyone может нарушить безопасность. После передачи выполните откат прав или назначьте конкретные группы/пользователей.

3. Подтвердите правильность удалённого пути

Частая ошибка — опечатка в пути. Если указан неверный путь, сервер откажет в доступе. Проверьте абсолютный путь и права на каждом сегменте каталога.

• На Linux убедитесь, что у пользователя есть права на каждый уровень каталога.
• На SFTP клиенте (WinSCP) откройте удалённую панель и проверьте структуру.

Что делать, если описанные решения не помогли

• Проверьте SELinux/AppArmor: они могут блокировать доступ даже при правильных Unix-правах. Посмотрите логи (/var/log/audit/audit.log) и при необходимости временно отключите или настройте контекст безопасности.
• Проверьте, не используется ли chroot для SFTP: в chroot-окружении права и владельцы важны. Обычно chroot требует владельца root и определённых прав на родительские директории.
• На FTP/SFTP-сервере проверьте конфигурацию (sshd_config, sftp-server, internal-sftp) — запреты на запись могут быть заданы глобально.
• Если подключение через WinSCP, попробуйте переключиться между протоколами SFTP и SCP или включить/отключить опцию “Elevate privileges” (повышение привилегий) в настройках.

Безопасная методология быстрого решения (мини-метод)

1. Проверить учётную запись и путь. 2. Проверить права и владельца (ls -l / icacls). 3. Временно дать минимально необходимые права. 4. Выполнить передачу. 5. Откатить права и зафиксировать правильную конфигурацию.

Список команд — шпаргалка

• Linux права: sudo chmod -R 755 /remote-dir/
• Linux полный доступ: sudo chmod -R 777 /remote-dir/ (временно)
• Смена владельца: sudo chown -R username:group /remote-dir/
• Windows ACL: icacls “C:\path\to\directory” /grant Everyone:(OI)(CI)F /T

Роли и чеклисты

Администратор сервера:

• Проверить системные логи (auth, audit).
• Проверить SELinux/AppArmor и chroot.
• Назначить корректных владельцев через chown.

Разработчик/пользователь:

• Убедиться в правильном пути и учётных данных.
• Попросить администратора временно открыть доступ для передачи.
• После передачи проверить, что файлы доступны приложению.

Когда такой подход не сработает

• Если сервер использует внешние механизмы контроля доступа (LDAP, NFS с root_squash, облачные ACL), локальные chmod/icacls не помогут. Нужно править разрешения на сущности выше или в самой системе управления доступом.
• При повреждённой файловой системе или аппаратных ошибках ошибка доступа может маскироваться под permission denied.

Риски и рекомендации

• Не оставляйте 777 или полные ACL для Everyone надолго. Это повышает риск случайной или злонамеренной модификации файлов.
• Документируйте временные изменения прав и возвращайте их в безопасное состояние.

Глоссарий (1 строка)

SFTP — защищённый протокол передачи файлов поверх SSH; icacls — утилита Windows для изменения ACL; chmod/chown — стандартные утилиты управления правами и владельцами в Unix.

Краткое резюме

Проблема обычно решается проверкой учётной записи, пути и корректной настройкой прав (chmod/chown или icacls). Если встречаются дополнительные механизмы контроля доступа (SELinux, chroot, NFS), потребуется их анализ. Всегда минимизируйте время действий, которые расширяют права, и откатывайте изменения после завершения передачи.

Важно: уделяйте внимание безопасности при изменении прав. Ошибка permission denied — сигнал системы о том, что права нужно навести в порядке, а не обойти несанкционированно.