Перенос файловой базы старой доброй платформы «1С:Предприятие 7.7» на терминальный сервер (RDP) — классическое и до сих пор популярное решение для организации совместной работы. Однако администраторы часто сталкиваются с неприятным сюрпризом: первый пользователь заходит в базу без проблем, а при попытке входа второго система выдает критическую ошибку: «Ошибка блокировки данных. Возможно, данные используются другой задачей».
В этой статье мы подробно разберем, почему возникает эта ошибка, как устроены механизмы блокировки файлов в платформе 1С 7.7 и как по шагам устранить эту проблему раз и навсегда. Мы рассмотрим не только базовое решение с правами доступа, но и разберем глубокие системные настройки Windows Server, которые влияют на стабильность работы файловых баз.
Для того чтобы понять природу ошибки, давайте проанализируем, как платформа 1С 7.7 работает с файлами в многопользовательском режиме. В отличие от современных клиент-серверных версий 1С v8, файловая версия 7.7 не имеет собственного сервера базы данных. Все операции чтения и записи производятся непосредственно движком платформы, запущенным на стороне клиента (в данном случае — в сессии RDP каждого пользователя).
При запуске базы данных система выполняет следующие действия:
1Cv7.md.1cv7.lck в корневом каталоге базы данных. Этот файл координирует совместный доступ.1cv7.lck, прописывая туда информацию о сессии.Если на каком-то из этих этапов операционная система Windows запрещает пользователю модифицировать, создавать или перезаписывать файлы блокировок, 1С 7.7 считает, что база занята монопольно другим процессом, и выдает ошибку блокировки данных.
Рассмотрим по шагам все возможные причины и методы их устранения.
Как показывает практика и обсуждение на форуме, самая частая причина этой ошибки — недостаточные права доступа терминальных пользователей на уровне файловой системы NTFS к каталогу (папке), в которой находится база данных.
Часто системные администраторы совершают ошибку: они дают пользователям права на чтение и запись файлов базы данных, но забывают дать полные права на сам каталог. Платформа 1С 7.7 постоянно создает, удаляет и модифицирует служебные файлы (такие как 1cv7.lck, временные файлы индексов *.cdx и файлы транзакций). Если у пользователя нет прав на изменение самого каталога, он не сможет корректно создать или обновить файл блокировки.
Выполним настройку прав по шагам:
После предоставления полных прав на каталог проверьте запуск базы под вторым пользователем. В большинстве случаев проблема будет решена.
Еще одна классическая ошибка при переносе базы в терминальный режим — использование одного и того же рабочего каталога для разных пользователей 1С. Если два пользователя ссылаются на один рабочий каталог, первый вошедший заблокирует конфигурационные файлы в этой папке, и второй получить доступ уже не сможет. Для массового редактирования учетных записей и их каталогов подойдёт консольная утилита для управления списком пользователей 1С 7.7.
Проанализируем структуру каталогов:
C:\1C_Bases\Accounting\Users\Ivanov и C:\1C_Bases\Accounting\Users\Petrov.Если права настроены верно, но ошибка сохраняется, выясним, не занята ли база монопольно кем-то из пользователей или зависшим системным процессом. Для этой задачи также подойдёт утилита для просмотра активных пользователей 1С 7.7.
Для диагностики используем штатный инструмент 1С 7.7 — «Монитор пользователей»:
Иногда пользователи закрывают сессию RDP простым нажатием на крестик окна терминала (Disconnect) вместо корректного выхода из системы (Log off). В этом случае процесс 1cv7s.exe продолжает висеть в памяти сервера и удерживать файлы базы. Чтобы решить эту проблему:
1cv7s.exe (или 1cv7.exe) и принудительно завершите их, нажав «Снять задачу».При аварийном завершении работы 1С (например, зависании сервера, отключении электроэнергии или сбое сетевого подключения в RDP-сессии) файлы блокировок могут остаться на диске. Система будет считать, что в базе кто-то есть, даже если все пользователи фактически вышли.
Выполним принудительную очистку:
1cv7s.exe.*.lck.1cv7.lck из корня базы и аналогичные файлы из папок пользователей).*.tmp в каталоге базы.Для автоматизации этой процедуры системные администраторы часто используют простой командный скрипт (.bat), который запускается перед началом рабочего дня или при перезагрузке сервера. Рассмотрим пример такого скрипта:
@echo off
echo Остановка зависших процессов 1С...
taskkill /F /IM 1cv7s.exe
taskkill /F /IM 1cv7.exe
timeout /t 2
echo Удаление остаточных файлов блокировки...
del /F /Q "C:\1C_Bases\Accounting\*.lck"
del /F /Q "C:\1C_Bases\Accounting\Users\*\*.lck"
del /F /Q "C:\1C_Bases\Accounting\*.tmp"
echo Очистка успешно завершена!
pause
Современные антивирусные программы очень агрессивно контролируют файловую активность. При открытии базы данных 1С начинает быстро считывать и записывать сотни мелких файлов базы данных (DBF/CDX). Антивирус перехватывает эти обращения для сканирования, монопольно блокируя доступ к файлу на доли секунды. Для 1С 7.7 этого времени достаточно, чтобы выдать ошибку совместного доступа.
Добавим базу в исключения антивируса на сервере:
1cv7s.exe (обычно расположен по пути C:\Program Files (x86)\1Cv77\BIN\1cv7s.exe).*.dbf, *.cdx, *.lck, *.md, *.tmp, *.usr.Если папка с базой данных физически расположена не на самом терминальном сервере, а на выделенном файловом хранилище или другом сервере в сети, и подключена к RDP-серверу как сетевой диск, вы гарантированно столкнетесь с проблемой кэширования Windows.
Протоколы SMB2 и SMB3 используют механизмы Oplocks (оппортунистические блокировки) и Leasing (лизинговые соглашения на файлы). Они позволяют клиентскому компьютеру кэшировать части файлов локально для ускорения работы. Но в случае с файловой 1С 7.7 это приводит к тому, что один терминальный сервер захватывает таблицу 1С монопольно и «забывает» вовремя сообщить файловому серверу о том, что файл освобожден. В результате другие сессии получают ошибку блокировки данных.
Чтобы решить эту проблему, крайне рекомендуется размещать файловую базу 1С 7.7 локально на SSD/NVMe дисках того же сервера, где запущены службы удаленных рабочих столов (RDP). Если перенос базы локально невозможен, необходимо отключить кэширование на файловом сервере через реестр Windows:
regedit) на сервере, где физически лежат файлы базы.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\ParametersHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\ParametersFileInfoCacheLifetimeFileNotFoundCacheLifetimeDirectoryCacheLifetimeПри работе в современных ОС (Windows Server 2012 / 2016 / 2019 / 2022) активная служба контроля учетных записей (UAC) может сыграть злую шутку с файловой базой 1С 7.7, если база расположена в защищенных системных директориях (например, внутри C:\Program Files или корне диска C:\ без должной настройки прав).
Включается механизм виртуализации папок:
%localappdata%\VirtualStore\Program Files\....Правило простое: всегда располагайте каталоги с базами данных 1С 7.7 на выделенном несистемном диске (например, D:\1C_Bases\) или в специально созданной папке в корне диска C с явно назначенными правами доступа, как было описано в первом решении.
Мы подробно проанализировали причины возникновения ошибки блокировки данных в «1С:Предприятие 7.7». Основным и самым частым решением является предоставление полных прав (Full Control) на каталог базы данных в NTFS для всех пользователей терминала, так как платформе жизненно необходима возможность беспрепятственно управлять временными файлами и файлами блокировок *.lck.
Совместное использование правильного распределения рабочих каталогов пользователей, регулярная очистка зависших сессий и грамотная настройка антивирусного ПО гарантируют долгую, стабильную и быструю работу вашей базы 1С 7.7 в многопользовательском терминальном режиме.