Рассмотрим типовую, но достаточно сложную задачу для системных администраторов, занимающихся внедрением 1С Предприятия на операционных системах Linux. Речь пойдет о ситуации, когда необходимо организовать работу нескольких пользователей с одной файловой базой данных, размещенной локально на сервере Ubuntu, к которому пользователи подключаются через терминальный доступ (XRDP).
Разберем подробно проблему, с которой сталкиваются администраторы: первый пользователь успешно входит в систему, а второй при попытке запуска получает ошибку доступа, связанную с файлом блокировок или базой данных. Проанализируем причины этого поведения и найдем правильные, безопасные способы решения.
При настройке сервера мы имеем следующую конфигурацию:
user01 и user02)./opt/1c_bases/account01.Когда первый пользователь (user01) запускает 1С в режиме файловой базы, платформа создает служебные файлы для контроля целостности и блокировок. Ключевым здесь является файл блокировок с расширением .1CL (или файл базы .1CD при попытке монопольного захвата, а также временные файлы .tmp).
Если следом пытается зайти второй пользователь (user02), он получает ошибку вида:
Ошибка при открытии файла блокировок .../1Cv8.1CL или сообщение о том, что файл занят другим процессом с недостаточными правами.
Посмотрим на ситуацию глазами операционной системы Linux, как это описано в анализе проблемы. Если мы заглянем в папку с базой в момент работы первого пользователя, мы увидим примерно следующую картину прав доступа на созданный файл блокировки:
-rw-r----- 1 user01 users_1c 0 янв 20 10:00 1Cv8.1CL
Здесь мы видим корень проблемы: файл создан пользователем user01. Права доступа (permissions) установились как 640 (чтение и запись для владельца, чтение для группы, остальным доступа нет). Пользователь user02, даже если он входит в группу users_1c, имеет право только на чтение этого файла, но для корректной работы платформе 1С требуется право на запись в этот файл блокировки для управления сеансами.
Иногда, пытаясь быстро решить проблему, администраторы прибегают к радикальному методу: запуску клиента 1С от имени суперпользователя. Рассмотрим команду, которая часто упоминается как "быстрое решение":
sudo /opt/1cv8/common/1cestart
Для работы графического приложения от root в сессии пользователя также требуется выполнить команду xhost +, которая отключает контроль доступа к графическому серверу X11.
Мы настоятельно не рекомендуем использовать этот метод в рабочей среде по следующим причинам:
xhost + позволяет любому пользователю (или вредоносному ПО) перехватывать нажатия клавиш и делать снимки экрана других пользователей.Давайте настроим доступ правильно, используя стандартные механизмы прав доступа Linux, чтобы в дальнейшем не возникало проблем, например, при архивировании баз данных.
Это наиболее современный и надежный способ для файловых систем ext4 или xfs. Стандартные права Linux (rwx) не всегда гибко позволяют управлять наследованием прав. ACL (Access Control Lists) позволяют задать "права по умолчанию" для каталога, которые будут автоматически применяться ко всем новым файлам, создаваемым внутри него, независимо от того, какой пользователь их создал.
Разберем по шагам, как это настроить:
1. Убедитесь, что утилита управления ACL установлена (обычно она есть в Ubuntu по умолчанию, пакет acl).
2. Создайте группу для пользователей 1С и добавьте туда нужных пользователей:
sudo groupadd users_1c
sudo usermod -aG users_1c user01
sudo usermod -aG users_1c user02
3. Назначьте группу владельцем папки с базой:
sudo chown -R :users_1c /путь/к/базе
4. Установите базовые права на папку (полный доступ владельцу и группе):
sudo chmod -R 770 /путь/к/базе
5. Самый важный шаг. Настройте дефолтные ACL. Это заставит систему давать полные права группе users_1c на любые файлы (включая 1Cv8.1CL и .tmp), которые 1С будет создавать в будущем.
# Устанавливаем права для текущих файлов (рекурсивно)
sudo setfacl -R -m g:users_1c:rwX /путь/к/базе
# Устанавливаем дефолтные права (для будущих файлов)
sudo setfacl -R -d -m g:users_1c:rwX /путь/к/базе
Ключ -d (default) здесь играет решающую роль. Теперь, когда user01 создаст файл блокировки, система автоматически добавит этому файлу права записи для группы users_1c, и user02 сможет с ним работать.
Если по каким-то причинам использование ACL невозможно, рассмотрим классический метод управления правами. Он базируется на изменении маски создания файлов (umask) и установке бита наследования группы (SGID).
Шаг 1: Настройка SGID на папку
Бит SGID (Set Group ID) на директории заставляет все создаваемые в ней файлы наследовать группу-владельца этой директории, а не основную группу пользователя.
# Устанавливаем группу
sudo chown -R :users_1c /путь/к/базе
# Устанавливаем права и бит SGID (цифра 2 в начале или g+s)
sudo chmod -R 2770 /путь/к/базе
Шаг 2: Настройка umask пользователей
По умолчанию в Linux umask часто равен 0022, что означает "забирать права записи у группы и остальных". Нам нужно изменить это на 0002, чтобы права записи у группы оставались.
Добавьте следующую строку в конец файла .bashrc (или .profile) в домашней директории каждого пользователя 1С:
umask 0002
После этого пользователям необходимо перелогиниться. Теперь создаваемые файлы будут иметь права 664 (rw-rw-r--), что позволит коллегам по группе редактировать файлы блокировок.
При настройке такой архитектуры важно помнить о нескольких нюансах:
/tmp или /var/tmp), так как 1С активно использует их при работе.Для организации совместной работы с файловой базой 1С на Ubuntu через RDP не требуется давать пользователям права администратора. Достаточно грамотно настроить права доступа на уровне файловой системы:
setfacl для настройки наследования прав (рекомендуемый метод).umask.Это обеспечит стабильную работу механизма блокировок платформы 1С и сохранит безопасность вашего сервера.