Как настроить права доступа на файлы, создаваемые сервером 1С под Linux?

← На главную

При работе сервера «1С:Предприятие» в операционных системах семейства Linux администраторы часто сталкиваются с неприятной особенностью. Файлы отчетов, выгрузок, логов или обменов, создаваемые сервером 1С (который по умолчанию работает от имени пользователя usr1cv8), записываются с правами, доступными только для чтения самому владельцу. Другие пользователи системы, внешние службы, веб-серверы (например, Apache или Nginx) или общие сетевые папки Samba видят эти файлы, но не могут открыть их для чтения или редактирования.

В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем механизмы работы операционной системы Linux с правами доступа и рассмотрим несколько способов решения — от простых системных настроек до использования расширенных списков контроля доступа (POSIX ACL).

Выясняем причину: почему umask в профиле пользователя не работает?

Первое решение, которое приходит в голову многим начинающим администраторам Linux, — изменить маску создания файлов (umask) для пользователя usr1cv8. Обычно для этого пытаются отредактировать конфигурационные файлы профиля, такие как .bashrc, .profile или глобальный файл /etc/profile.

Однако на практике такой подход не дает результатов. Дело в том, что сервер «1С:Предприятие» запускается как системная служба (демон). При старте демона операционная система не инициализирует полноценный интерактивный сеанс пользователя, а значит, все файлы инициализации окружения вроде .bashrc просто игнорируются. Настройку маски создания файлов необходимо производить непосредственно в конфигурации службы инициализации.

Рассмотрим по шагам, как правильно настроить umask для службы сервера 1С в зависимости от используемой системы инициализации.

Решение 1. Настройка UMask в системе инициализации systemd

В современных дистрибутивах Linux (Ubuntu, Debian, CentOS, RedHat, ALT Linux) управление службами осуществляется через подсистему systemd. Начиная с версии платформы 8.3.21, использование systemd стало стандартом по умолчанию, но и на более ранних версиях платформы администраторы часто настраивают запуск через юниты вручную.

Чтобы переопределить настройки прав для службы 1С, выполним следующие действия:

Откроем редактор переопределения конфигурации службы (drop-in файлов). Это наиболее правильный метод, так как он гарантирует, что при обновлении платформы 1С ваши настройки не будут затерты стандартным пакетом обновления. Выполним команду в терминале: sudo systemctl edit srv1cv83 (Обратите внимание: имя службы может отличаться в зависимости от версии платформы, например, srv1cv8-8.3.25.1234. Уточните точное имя службы перед запуском).
В открывшемся текстовом редакторе между комментариями вставим следующую секцию:
```
[Service]
UMask=0002
```
Маска 0002 означает, что вновь создаваемые файлы будут иметь права 664 (чтение и запись для владельца и группы, чтение для остальных), а каталоги — 775 (полные права для владельца и группы, чтение и переход для остальных).
Сохраним изменения и закроем редактор.
Перезапустим конфигурацию служб systemd, чтобы применить изменения, и перезапустим сам сервер 1С:
```
sudo systemctl daemon-reload
sudo systemctl restart srv1cv83
```

Решение 2. Настройка umask для систем инициализации SysV Init

Если вы используете более старые версии платформы (например, обсуждаемую в теме версию 8.3.15) или операционную систему без systemd, запуск службы выполняется через классические скрипты инициализации. Скрипт запуска обычно находится по пути /etc/init.d/srv1cv83.

Редактировать сам скрипт не рекомендуется. Вместо этого настроим конфигурационный файл окружения службы:

Откроем конфигурационный файл службы. В дистрибутивах на базе Debian/Ubuntu он обычно находится по пути /etc/default/srv1cv83, а в CentOS/RedHat — /etc/sysconfig/srv1cv83.
В самом начале файла добавим строку: umask 0002
Сохраним файл и перезапустим службу сервера 1С: sudo service srv1cv83 restart

Важная особенность платформы 1С: когда umask бессилен

Механизм umask в Linux работает как фильтр: он может только запретить выдачу определенных прав при создании файла, но не может принудительно добавить права, которые процесс не запрашивал.

Если при создании файла внутренний код платформы 1С явно вызывает системную функцию создания файла и передает в нее жестко заданные ограничения безопасности (например, права 0600 — только для чтения и записи владельцем), то системный umask не сможет расширить эти права. В некоторых сценариях работы платформы (при формировании определенных отчетов, временных файлов или выгрузок) 1С действительно принудительно ограничивает права доступа из соображений безопасности. В таких случаях изменение umask службы окажется неэффективным. Рассмотрим более гибкие варианты обхода этого ограничения.

Решение 3. Использование POSIX ACL (Наиболее изящный способ)

Если файлы должны создаваться в определенном каталоге обмена (например, /home/shared/exchange) и быть доступными для других пользователей или веб-служб, идеальным решением будет использование списков контроля доступа (Access Control Lists). Списки ACL позволяют настроить автоматическое наследование прав для любых новых файлов и папок внутри конкретного каталога, полностью игнорируя то, с какими правами их создавала платформа 1С.

Проанализируем этот процесс и настроим его по шагам:

Установим утилиту для работы с ACL (если она не установлена в вашей системе):
```
# Для Debian/Ubuntu:
sudo apt update && sudo apt install acl

# Для CentOS/RedHat:
sudo yum install acl
```
Предположим, у нас есть группа пользователей web-users (в которую входит, например, веб-сервер или пользователи Samba), которой необходим доступ к файлам обмена. Зададим дефолтные права (Default ACL) на наш каталог:
```
# Назначаем права для существующих файлов и папок рекурсивно
sudo setfacl -R -m g:web-users:rwx /home/shared/exchange

# Устанавливаем дефолтные правила для всех НОВЫХ файлов и папок (флаг d:)
sudo setfacl -R -m d:g:web-users:rwx /home/shared/exchange
```

Благодаря этому правилу, любой файл, созданный сервером 1С в папке /home/shared/exchange, даже с жесткими правами владельца 0600, автоматически получит дополнительные права на чтение, запись и исполнение для группы web-users. Это полностью решает проблему без ослабления безопасности всей операционной системы.

Решение 4. Использование бита SGID (Set Group ID)

В операционной системе Linux можно настроить наследование группы-владельца для всех создаваемых файлов внутри каталога. Это очень полезно, если вы объединили пользователя 1С (usr1cv8) и других пользователей в общую группу.

Разберем, как применить этот подход:

Создадим общую группу для обмена файлами, если она еще не создана: sudo groupadd exchange-group
Добавим пользователя 1С и других необходимых пользователей в эту группу:
```
sudo usermod -aG exchange-group usr1cv8
sudo usermod -aG exchange-group apache
```
Назначим группу-владельца на каталог обмена: sudo chown -R usr1cv8:exchange-group /home/shared/exchange
Установим специальный бит SGID на эту папку: sudo chmod g+s /home/shared/exchange

Теперь любой файл, записанный платформой 1С в этот каталог, автоматически получит группу-владельца exchange-group. В сочетании с настройкой UMask=0002 для службы 1С это обеспечит беспрепятственный доступ к файлам всем членам группы.

Решение 5. Альтернативные методы автоматизации

Если по какой-то причине на вашей файловой системе не поддерживается ACL или вы не можете вносить изменения в параметры службы сервера 1С, рассмотрим еще два альтернативных варианта решения проблемы.

Вариант А. Виртуальное монтирование через bindfs

Утилита bindfs позволяет примонтировать одну директорию в другую с виртуальной "подменой" прав на лету. Физически файлы будут лежать в папке 1С с правами владельца, но в точке монтирования они будут отображаться так, будто имеют полный доступ для всех:


sudo bindfs --create-with-perms=0777 --perms=0777 /home/shared/exchange /home/shared/exchange_public

В результате сторонние пользователи работают с файлами через папку exchange_public, не испытывая никаких проблем с доступом.

Вариант Б. Отслеживание изменений через inotify

Мы можем написать простой фоновый скрипт на bash, который будет непрерывно мониторить папку обмена и автоматически менять права на файлы сразу после их создания платформой 1С:


#!/bin/sh
MONITORDIR="/home/shared/exchange"
inotifywait -m -r -e create --format '%w%f' "${MONITORDIR}" | while read NEWFILE
do
    chmod 664 "$NEWFILE"
done

Этот скрипт можно оформить в виде простой службы systemd, которая будет запускаться при старте операционной системы.

Выводы и рекомендации

Мы рассмотрели несколько способов решения проблемы с правами доступа к файлам под Linux. Подведем итог, какой метод выбрать:

Если вы хотите решить проблему глобально для всех файлов, создаваемых 1С, настройте Umask в службе systemd.
Если вам нужно настроить совместный доступ к определенной папке обмена для внешних служб или пользователей, используйте наследование через POSIX ACL — это наиболее профессиональное и безопасное решение.
Избегайте использования вызовов КомандаСистемы("chmod ...") из кода 1С, так как это снижает производительность системы и создает серьезные уязвимости безопасности.