В систему технической поддержки поступила заявка от пользователя, смысл которой сводился к тому, что отсутствовала возможность сохранения рабочих таблиц формата xlsx на корпоративном сетевом ресурсе, в папке департамента к которому принадлежал данный клиент. Дополнительно, самим же пользователем было установлено, что абсолютно идентичной проблемой страдает и другое офисное приложение, почтовый клиент Outlook 2010 в процессе сохранения вложений из писем по тому же самому сетевому пути, а так же и ряд других программ, в частности 1С. В чем же заключались детали инцидента? При попытке сохранения файлов на корпоративном сетевом хранилище, пользователь получал ошибку "Этот путь не существует. Проверьте правильность указания пути и повторите попытку".
Целевой ресурс был незамедлительно проверен, и как Вы уже догадались, сетевая папка находилась там где ей и положено быть, и при этом на нее были выставлены абсолютно корректные параметры безопасности, что и было дополнительно подтверждено. При всем этом, те же самые файлы пользователя превосходно сохранялись на локальные диски.
В ходе более углубленного изучения деталей инцидента, было установлено, что при попытке создания новой папки на заданном сетевом ресурсе, выдавалось сообщение Слишком много файлов открыто для совместного доступа:
Диагностика
Исходя из того, что я успел понять, проводник либо другое приложение взаимодействует с сетевым ресурсом посредством стандартных системных сетевых функций ввода-вывода, которые работают с UNC-путями. С большой вероятностью данные функции используют сервис "Служба доступа к файлам и принтерам сетей Microsoft", а тот, в свою очередь, использует драйвер SMB. Допустим, перед выполнением определенных операций с файлами, гипотетический сервис осуществляет ряд проверок неких предопределенных условий. Одним из таких условий является ограничение на количество одновременно открытых файловых дескрипторов от имени удаленного пользователя. Скажем так, любой открытый сетевой (?) файл, увеличивает некий счетчик открытых файловых дескрипторов. Где задается этот лимит и какое конкретное значение имеет по-умолчанию, на текущий момент для меня остается тайной. Судя по тем немногочисленным осколкам информации, которые мне удалось обнаружить в Сети, этот лимит (начиная с Windows Vista) жестко задан в какой-то переменной ядра, скорее всего в небольшое значение (15). Тем не менее, если это предположение верно, заключим, что именно с этим ограничением и столкнулся наш пользователь, что и привело к генерации описанной выше ошибки Слишком много файлов открыто для совместного доступа. Оригинальная ошибка имеет идентификатор 36 и носит англоязычное название ERROR_SHARING_BUFFER_EXCEEDED. Но почему проблема образовалась именно сейчас, ведь на протяжении продолжительного времени работы подобных инцидентов не возникало, то есть пользователь вполне укладывался в предоставляемые системные лимиты? Вероятнее всего какая-либо служба или программа на станции пользователя, создающая собственные сессии с тем же сетевым ресурсом, от имени того же пользователя, начала "сбоить", создавая собственные сессии в избыточном количестве. В этих условиях штатное подключение пользователя к сетевому ресурсу из программ либо посредством проводника уже не укладывается в лимит. Но это всего-лишь мое предположение, основанное на простой логике и вовсе не опирающееся на глубокие знания работы сервиса "Служба доступа к файлам и принтерам сетей Microsoft", протокола SMB и других вероятных составляющих цепочки доступа к сетевому ресурсу. Однако теория есть теория, но без внутреннего знания нам остается один лишь, временем проверенный и безотказный, великий "метод тыка", имеющий отрицательным свойством своим огромное количество времени, затрачиваемое на перебор возможных вариантов решения. На определенном этапе поиска, я совсем случайно я обратил внимание на небольшой зеленого цвета значок в нижней области статуса сетевой папки.
Данный маркер говорит об использовании автономных файлов.
Автономные файлы, также известные под псевдонимом "кэширование на стороне клиента" (Client Side Caching, CSC), позволяют пользователям работать с сетевыми файлами, когда подключение к серверу недоступно или работает слишком медленно.
Функция "Автономные файлы" имеет в системе собственную одноименную службу и драйвер, которые и выполняют весь объем работ по синхронизации файлов между локальными и сетевыми версиями данных. Как оказалось, между приложением, использующим SMB для доступа к сетевым ресурсам, и клиентским SMB драйвером, имеются еще системные и сторонние драйвера различного функционала, одним из которых является драйвер автономных файлов. В случае включенной функции автономных файлов, данные от приложения сначала попадают на драйвер автономных файлов и, в зависимости от критериев скорости и доступности целевого сетевого ресурса, драйвер либо выполняет локальное кеширование данных, либо использует драйвер SMB для синхронизации с целевым сетевым ресурсом, тем самым уменьшая лимиты дескрипторов? Вот именно какой-то код синхронизации либо в самих автономных файлах, либо в драйвере SMB и вызывает подобный эффект, скорее всего где-то в коде имеется ошибка.
Решение
Поскольку проблему надо было решать достаточно оперативно, самым очевидным решением, которое сразу пришло на ум, было полностью отключить функцию автономные файлы. Следующие действия необходимо выполнять из-под учетной записи с правами локального администратора. Для осуществления этого откроем Панель управления, далее Центр Синхронизации, затем Управление автономными файлами. Увидим перед своими глазами следующее окно:
Далее ждем кнопку Отключить автономные файлы. После отключения может потребоваться перезагрузка операционной системы. После того, как мной было выполнено отключение автономных файлов, проблема на станции пользователя более не повторялась.
Вполне возможно, в описанном выше случае мы имели дело с ошибкой функционирования "автономных файлов". Поэтому не исключено, что существует путь решить проблему не столь кардинальным образом, то есть не отключая автономные файлы.