Коли Linux каже «Доступ заборонено»

Коли з’являється «Доступ заборонено»

Ви вводите команду, сподіваючись на гладке виконання, а замість того отримуєте:

bash: ./deploy.sh: Permission denied.

Це та дратувальна помилка, яка зупиняє розгортання, зриває збірки чи блокує оновлення сервера — і часто змушує витрачати години на полювання за одним-єдиним прапорцем прав доступу. Майже кожен, хто працює з Linux, стикався з цим, і попри те, що це трапляється постійно, все одно викликає паніку та простої.

Ось у чому річ — це не значить, що щось зламано. Просто ви намагаєтеся зробити те, на що у вас немає прав. Linux просто стоїть на варті своїх кордонів безпеки.

В цій статті ми розглянемо, чому ця помилка виникає, що вона насправді означає, і як її виправити крок за кроком — без того, щоб порушити безпеку системи чи створити нові дірки.

Чому виникає «Доступ заборонено» (і чому це трапляється постійно)

Помилка «Доступ заборонено» в Linux з'являється, коли користувач не має належних прав на читання, запис чи виконання файлу.

Звучить просто, але в реальних умовах — контейнерах, середовищах з кількома користувачами чи CI/CD-пайплайнах — права доступу швидко перетворюються на хаос.

• Скрипт склонований з Git, але втратив прапорець виконання;
• Веб-додаток намагається записати логи в директорію, яка належить root;
• SELinux тихо блокує доступ;
• Або хтось колись «виправив» усе за допомогою chmod 777, і тепер панує безлад.

Тож ні, це не просто про «забули додати +x». Це про те, як Linux тримає кордони, щоб забезпечити безпеку.

Модель прав доступу в Linux коротко

Кожен файл і папка в Linux має три типи доступу — читання (r), запис (w) і виконання (x) — які застосовуються до трьох сутностей:

Приклад:

-rwxr-xr-- 1 dev dev 1234 Oct 10 12:00 app.sh

Тут власник (dev) може читати, писати й виконувати; група — читати й виконувати; інші — тільки читати.

Кожен прапорець позначається числом:

• r = 4
• w = 2
• x = 1

Тож chmod 755 file.sh = 7 (rwx) для власника, 5 (r-x) для групи, 5 (r-x) для інших.

Реальні сценарії, де все ламається

1. Запуск скрипту без прав на виконання

Ви склонували репозиторій і спробували:

./build.sh

Але оболонка видає «Доступ заборонено». Чому? Бо Git за замовчуванням не зберігає біти виконання. Виправте так:

chmod +x build.sh
git update-index --chmod=+x build.sh

2. Проблеми з доступом до SSH-ключа

chmod 600 ~/.ssh/id_rsa
chown $USER:$USER ~/.ssh/id_rsa

3. Веб-додаток не може писати в директорії

sudo chown -R www-data:www-data storage
sudo chmod -R 750 storage

4. «Доступ заборонено» всередині Docker-контейнера

Монтування директорії хоста в контейнер часто призводить до невідповідності UID.

docker run --user $(id -u):$(id -g) ...
sudo chown -R 1000:1000 /data

5. Редагування системних конфігурацій

sudo nano /etc/nginx/nginx.conf

Для глибшого розуміння вибору між NGINX і Apache дивіться нашу статтю Оптимізація веб-сайту: вибір між NGINX і Apache

Крок-за-кроком: чек-лист для виправлення «Доступ заборонено»

1. Перевірте права файлу:

   ls -l filename

2. Якщо бракує прав на виконання:

   chmod +x script.sh

3. Якщо не можете писати в директорію:

   sudo chown youruser:youruser /path/to/dir

4. Потрібні підвищені привілеї?

   sudo command

5. Все ще блокує? Можливо, винен SELinux:

   getenforce
   sudo ausearch -m avc

А що з числами в chmod?

• chmod 744 file → повні права для власника, тільки читання для інших
• chmod 755 file → повні для власника, читання й виконання для інших
• chmod 777 file → усі можуть усе (не рекомендується!)

Правило великого пальця:

• 755 для скриптів
• 644 для конфігів
• Ніколи 777 у продакшені

Просунуті концепції прав доступу (які часто плутають новачків)

• setuid (4xxx) — дозволяє програмі запускатися від імені власника (часто root).
• setgid (2xxx) — забезпечує, щоб файли в директорії успадковували групу цієї директорії.
• sticky bit (1xxx) — запобігає видаленню файлів один одного в спільних папках (як /tmp).

Коли це насправді не проблема з правами

• Файлова система змонтована тільки для читання після збою: mount | grep your_folder
• Umask в CI/CD створює надто обмежені файли.
• Мережевий диск (NFS/SMB) ігнорує локальний chmod.
• SELinux застосовує обмеження на рівні політики.

Поради щодо запобігання

• Тримайте власництво файлів однаковим на всіх серверах.
• Уникайте запуску збірок від root.
• Встановіть правильний umask 022.
• Регулярно перевіряйте права за допомогою автоматизованих скриптів.
• Моніторте зміни прав за допомогою auditd:

auditctl -w /etc/ -p w -k perms
ausearch -k perms

«Доступ заборонено» — це не баг, а Linux, яка робить свою справу, запобігаючи небезпечним чи несанкціонованим діям. Як тільки ви розберетеся з власництвом і правами, помилка стає передбачуваною й легкою для виправлення.

У продакшені дрібні помилки з правами можуть перерости в дорогі простої. Щоб уникнути рутинного головняка, розгляньте керовані VPS-сервери, які автоматично керують правами, безпекою та обслуговуванням, дозволяючи зосередитися на коді.