🛠️ ACL выдали, а доступа всё равно нет

Пользователю выдали права через ACL. В getfacl видно:

user:appuser:rwx

Но приложение всё равно не может записать файл.

На первый взгляд кажется: «Права же есть». На практике нужно смотреть не только на строку пользователя, но и на mask.

Условный фрагмент:

user::rw- user:appuser:rwx #effective:r-- group::r-- mask::r-- other::---

Что здесь происходит?

Строка: user:appuser:rwx показывает, какие права назначены пользователю appuser в ACL.

Но строка: mask::r-- ограничивает максимальные effective permissions для named users, group:: и named groups. На владельца файла user:: и other:: она не действует.

Поэтому фактически для appuser остаётся только: #effective:r-- То есть пользователь получает чтение, но не получает запись и выполнение, хотя в его ACL-строке указано rwx.

Диагностическая развилка: — если в getfacl есть #effective, смотрим не только номинальные права, но и результат после mask; — если пользователю выдали rw или rwx, но запись не работает, проверяем mask; — если проблема только у одного пользователя или группы, сравниваем named user / named group и mask; — если права меняли через разные инструменты, проверяем, не пересчиталась ли mask после изменений.

Типичная ошибка — снова и снова выдавать права пользователю, не замечая, что effective permissions всё равно ограничены mask. Или наоборот — сразу предлагать chmod 777, хотя проблема не в отсутствии всех прав, а в том, как ACL превращаются в фактический доступ.

Важно: менять mask вслепую тоже нельзя. Она может повлиять не только на одного named user, но и на group:: и named groups.

Практический вывод: в спорных случаях доступа нужно читать getfacl целиком: owner, group, named user, named group, mask и #effective. Номинальная ACL-запись ещё не гарантирует, что именно такие права получит процесс.

Сохраните пример: он помогает разбирать спорные случаи доступа без chmod 777.

🔹🔹🔹🔹