Samba: клиент не может записать в общий ресурс
В Samba действуют два слоя прав: параметры ресурса и права файловой системы. Отказ записи при «разрешающих» настройках ресурса почти всегда означает, что не пускает второй слой.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Права файловой системы не позволяют запись
Samba работает от имени подключившегося пользователя. Каталог, принадлежащий другому пользователю без прав группе, недоступен для записи.
-
Ресурс объявлен только для чтения
Параметр ресурса перекрывает всё остальное: при запрете записи файловая система не проверяется.
-
Маска создания файлов режет права
Параметры маски определяют права новых файлов. Слишком строгая маска делает файлы недоступными для группы.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Итоговые параметры ресурсов.
testparm -s 2>/dev/null | head -30Права каталога на файловой системе.
ls -ld /srv/shareПодключённые ресурсы и пользователи.
sudo smbstatus -SРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Samba работает от имени подключившегося пользователя. Каталог, принадлежащий другому пользователю без прав группе, недоступен для записи.
- Как проверить
-
Посмотрите права каталога и пользователя подключения.
ls -ld /srv/share sudo smbstatus -S 2>/dev/null | head
- Как исправить
- Дайте нужной группе права на запись и включите в неё пользователей ресурса. Открывать права всем не нужно.
- Почему происходит
- Параметр ресурса перекрывает всё остальное: при запрете записи файловая система не проверяется.
- Как проверить
-
Посмотрите параметры ресурса.
testparm -s --section-name=share 2>/dev/null
- Как исправить
- Разрешите запись в описании ресурса и укажите, кому именно она доступна.
- Почему происходит
- Параметры маски определяют права новых файлов. Слишком строгая маска делает файлы недоступными для группы.
- Как проверить
-
Посмотрите маски.
testparm -s 2>/dev/null | grep -iE "create mask|directory mask"
- Как исправить
- Приведите маски в соответствие с тем, как файлы должны использоваться другими участниками.
Пример вывода
Ресурс разрешает запись, файловая система — нет. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
smbd[4300]: create_file: Access denied for user app to /srv/share/report.xlsx
smbd[4300]: Permission denied
$ ls -ld /srv/share
drwxr-xr-x 2 root root 4096 Sep 10 11:20 /srv/shareСвязанные ошибки
- Permission denied в журнале службы Отказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
- nginx 403 Forbidden и Permission denied на файлы сайта nginx отдаёт 403: нет прав на файлы сайта, закрыт каталог по пути, мешает SELinux или AppArmor, нет индексного файла.
- AppArmor: apparmor="DENIED" в журнале ядра Профиль AppArmor запретил операцию: как прочитать запись, найти профиль и поправить его правильно.
- Caddy не занимает порты 80 и 443 без прав Служба падает при открытии слушателя: нет возможности занимать привилегированные порты.
- Configuration file is marked executable Предупреждение о правах: unit-файл помечен исполняемым. Откуда берётся и почему это стоит исправить.
- Configuration file is marked world-inaccessible Предупреждение о правах на unit-файл: служба работает, но файл недоступен для чтения другим.
- Interactive authentication required при управлении службой systemctl требует аутентификации: обращение от непривилегированного пользователя через polkit. Как разрешить точечно.
- MongoDB: Unable to lock file mongod.lock mongod не запускается: остался файл блокировки после аварийного завершения или каталог принадлежит не тому пользователю.
Где встречается чаще всего
Источники
-
smb.conf(5)
Параметры ресурсов, маски создания и права. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено каталогом root:root с правами 0755 при записи от другого пользователя.