Ошибка при выполнении файловой операции 1с вы не можете получить доступ к этой общей папке

Содержание:

1.       Об ошибке при выполнении файловой операции

2.       Устранение «Ошибки при выполнении файловой операции» в 1С 8.3   

1.    Об ошибке при выполнении файловой операции

Приветствую, коллеги! В данной статье будет описана ошибка «Ошибка при выполнении файловой операции», и подробно рассмотрены способы ее устранения.

Когда происходит обновление конфигураций в 1С 8, по завершении обновления, часто появляется ошибка, которая гласит «Ошибка при выполнении файловой операции – файл не содержит доступных обновлений».  

2.    Устранение «Ошибки при выполнении файловой операции» в 1С 8.3

Рассмотрим методы, при помощи которых, можно устранить ошибку при выполнении файловой операции в 1С.

Итак, первый способ – это попробовать сделать обновление при помощи файлов по обновлению вида «релиз 1с*.cfu». Если это не помогло, то можно попробовать обновить систему при помощи общего файла вида «полный релиз 1С*.cf».

Вторым способом будет проверка на соответствие общей версии системы 1С с минимальными требованиями версии конфигурации 1С, которую обновляем.

Третий способ устранения ошибки при выполнении файловой операции в 1С – более сложный, но действенный. Необходимо открыть в конфигурацию от поставщика в режиме Конфигуратора. Если ошибка всё так же появляется, то необходимо удалить конфигурацию поставщика, а затем опять установить. По сути, в данном варианте «вытягивается» последняя, рабочая версия данной конфигурации и обновление будет завершено без ошибок.

Рассмотрим подробнее третий способ. Пусть у нас уже есть некоторая конфигурация 1С KORG 1-ой версии, которая работает, но нужно поставить 2-ю версию, то есть обновить версию конфигурации 1С 8.3. Когда происходит обновление, всплывает ошибка «Ошибка при выполнении файловой конфигурации». Порядок действий в этом случае:

1.     скачать релиз 1С KORG с версией 1*.cf;

2.     копируем нашу базу данных;

3.     в конфигураторе, который соответствует обновляемой базе, переходим по пути: «Конфигурация → Поддержка → Настройки поддержки → Снять с поддержки». В случае, если кнопка для снятия с поддержки недоступна, необходимо сперва включить возможные изменения. После этого нужно дать согласие, если система 1С будет уточнять что-либо или подтверждать действия;

4.     Далее переходим по следующему пути: «Конфигурация → Сравнить и объединить с конфигурацией из файла…». Здесь необходимо выбрать файл «полный релиз 1С KORG версии 1*.cf»;

5.     Далее перед нами появится окно, в котором система 1С будет запрашивать постановление на учёт для поддержки, на это уведомление обязательно отвечаем согласием;

6.     В случае, если наша конфигурация является типовой, откроется окно по сравнению конфигураций. В нем обязательно убираем все «галочки». Далее последует объединение конфигураций;

7.     В новом окне кликаем на «Сохранить изменения»;

8.     Ещё раз сохраняем базу данных;

9.     Обновляем конфигурацию 1С стандартным способом.

Если всё сделать, согласно инструкции выше, то в вашей конфигурации 1С 8.3 «Ошибка при выполнении файловой операции» больше не возникнет. Спасибо за внимание!

Специалист компании «Кодерлайн»

Айдар Фархутдинов

Обновлено 15.10.2020

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Рунета Pyatilistnik.org. В прошлый раз мы с вами разобрали, что из себя  представляет файловая система raw, и как ее исправить, чтобы восстановить свои данные. Двигаемся дальше и поговорим сегодня на тему  капризности 1С, точнее на капризную работу в рамках Windows Server 2016. Я рассмотрю причину и устранение периодически повторяющейся ошибки на сервере 1С 8.3 «Ошибка при выполнении файловой операции«. Ее я стал встречать после обновления с Windows Server 2012 R2 д 2016. Думаю мой опыт сэкономит вам часик серфинга по интернету.

Описание проблемы

В моей компании заканчивается обновление операционных систем у виртуальных серверов, с Windows Server 2012 R2 на Windows Server 2016, я понимаю, что поддержка первых еще будет несколько лет, но хочется уже не делать это в последний момент, а слегка опережать, да и уже давно пора стремиться к Windows Server 2019. Сервера 1С не были исключением, обновление происходило по быстрому варианты. Тут подразумевается накатывание более новой версии ОС по верх старой, тут мы убивали двух зайцев:

1. Получали свежую версию ОС
2. Оставляли весь софт на сервере, и не требовалась его переустановка

В случае чего всегда можно было откатиться из снапшота на момент проведения работ, благо ESXI 6.5 это помогает делать в два клика. Все прекрасно обновилось и сервер зажил новой жизнью. В какой-то момент при запуске клиента 1С 8.3 на RDS ферме, стала появляться ошибка:

Устранение проблемы

Начав изучать данный вопрос мы не стали откатываться к бэкапу, так как данная проблема возникала не постоянно, а через некоторые промежутки и была вызвана явно не переходом на более новую версию операционной системы. Подняв исторические данные в системе заявок, я нашел похожую, где решением ошибки был перенос базы данных 1С на другой диск. Меня это заинтересовало и я стал прикидывать, что же могло быть в той ситуации. Через минут 20 я нашел одну закономерность, что на всех проблемных хостах был установлен компонент Windows дедупликации, как раз на тех дисках, где располагались базы данных 1С.

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

Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.

Вообще если у вас виртуальные сервера лежат на системе хранения данных, то у нее должна быть своя функция дедупликации и использовать лучше и правильнее ее. Если у вас есть другие варианты решения данной проблемы, то пишите их в комментариях. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

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

Ошибка 1C при выполнении файловой операции

Здесь мы видим частный и явно описанный случай проблемы. После обновления Windows на компьютере с базой, бухгалтер со второй машины не смог зайти в базу. Программа выдала ошибку как на скриншоте.

Описание: «Вход пользователя не выполнен из-за ограничений учётной записи. Например, пустые пароли не разрешены; ограничено число входов или включено ограничение политики».

В рассматриваемом примере 1С явно указывает на возможные источники проблемы. После установки патча винда сбросила некоторые настройки сетевой политики безопасности, и по умолчанию перестала пускать пользователей с учёткой без пароля.

Чтобы починить, нужно на ПК с базой зайти в Панель управлени — Центр управления сетями и общим доступом — Изменить дополнительные параметры общего доступа — Все сети — Общий доступ с парольной защитой — установить флаг Отключить общий доступ с парольной защитой.

Если не хочется бродить в недрах панели управления, можно открыть редактор политик напрямую: 

Пуск — Выполнить (или Win+R) — secpol.msc;

Переходим в Локальные политики — Параметры безопасности — Учетные записи: разрешить использование пустых паролей только при консольном входе устанавливаем значение Отключен.

Какие ещё причины могут вызвать появление подобной ошибки:

• Некорректная работа антивируса. Обычно этим периодически грешит Касперский: нужно добавить приложение 1С и папки с базами в исключение. Иногда помогает только полная переустановка антивируса.
• Некорректная настройка общего доступа к папке с базой: нет прав у конкретного пользователя или прав на запись/изменение в папку. Проверить это очень просто: нужно перейти в папку (можно скопировать путь из окна запуска 1С) и попробовать создать в ней любой файл. Хотя бы обычный текстовый документ. Если не получается или папка не открывается — скорее всего оно.

07.06.19 — 16:48

1 — 07.06.19 — 16:50

«Давал  доступ пользователям на профиль пользователя agent на терминальном сервере» — а надо было права агента ковырять.

2 — 07.06.19 — 16:51

«зайти на терминальный сервер пользователем agent и зайти им же в 1C» — овнер файла один и тот же, что отправитель, что получатель.

3 — 07.06.19 — 16:52

«При чем тут пользователь agent » — при том, что операции очевидно производит сервер-1с работающий под агентом.

4 — 07.06.19 — 16:52

«Сегодня буду пробовать новую платформу 8_3_14_1779.» — полезное занятие, но бессмысленное в контексте озвученной проблемы.

5 — 07.06.19 — 19:10

Но вот что еще заметил если пользователем в терминальник agent и войти в базу с agent то

1 попытка выгрузить будет удачна то

2..3..4..итд. будет выходить всё та же ошибка.

Блин где грабли?

6 — 07.06.19 — 19:39

(0) >Давал  доступ пользователям на профиль пользователя agent на терминальном сервере — результат такой же.

O! Это как ?!

7 — 07.06.19 — 19:54

Да просто добавлял в безопасность группу пользователей терминального сервера на полный доступ.

Любой пользователь имел полные права на профиль пользователя agent

8 — 07.06.19 — 19:55

9 — 07.06.19 — 20:09

Раньше работало на старом сервер в режиме файлового сервера, теперь всё перенесли в скуль и на терминальник.

10 — 07.06.19 — 20:15

(9) Возможно баг в коде выгрузки. Не поддерживает клиент-серверный режим.

11 — 07.06.19 — 20:20

Такая же конфигурация прекрасно работает на другой прощадке

12 — 07.06.19 — 21:07

Заметил что такое происходит именно на сервере 1с приложений!

Так что терминальник отпадает — уже ближе.

Но почему происходит блокировка файлов на сервере?

13 — 08.06.19 — 07:04

(12) тебе же уже объяснили, проверь есть ли у пользователя agent полный доступ на диск c: сервера. Или в безопасности убери наследование папок. Чтобы у папки C:Usersagent не было наследования прав от родительской папки. А то папка C:Usersagent наследует у тебя права от C:Users, папка C:Users наследует права от C:, а на C: ты полные права не дал. Поэтому пошуруй еще раз в безопасности на предмет наследования.

14 — 08.06.19 — 09:20

С правами всё ОК!

На сервере перенес папку temp в другое место для пользователя agent и стал снова запускать выгрузку и что обнаружилось что файлы v8_DCA6_XXXX.txt прекрасно создаются и у пользователя полнейший доступ — полнее не бывает.

Но вот что обнаружил нажимаю постоянно кнопку выгрузки рандомно может 20 раз выполниться,а после ошибка и снова по прошествии времени нажать выгрузить и всё ОК! Получает как то рандом то создаются временные файлы то нет.

Ранее эта конфигурация была файловая и была перенесена в скул dt выгрузкой.

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

Взял базу центральную залил на тоже железо с тем же пользователем -и и начал проводить те же процедуры.

Ни одной ошибки выгрузки ну пробовал раз 40, и смотрел на папку temp в которой я не обнаружил что выгрузка что то создает при выгрузке. Получается в переферийной конфигурации что то осталось от файловой версии? Или куда копать?

15 — 08.06.19 — 09:39

(14) С отладчиком дружишь?

16 — 08.06.19 — 11:04

попробуйте указать путь не в профиль через получитьвременныйфайл,а в какую-то осознанную папку и посмотреть от имени кого туда пишется,а для этого в системе нужно аудит настроить.

17 — 14.06.19 — 08:22

Тема до сих пор актуальна.

Обновил платформу.

Обновил конфигурацию.

Переустанавливал 1С.

Кэш чистил.

Проводил тесты чтения записи дисков.

Переносил папку Temp на другой диск — давая права на неё полный доступ всем.

Ошибка всплывает рандомно! Можно 10 раз подряд нажимать кнопку Выгрузить — все ОК! на 11 раз ошибка!

18 — 14.06.19 — 08:37

19 — 14.06.19 — 09:16

20 — 14.06.19 — 11:01

(19) тю, проблем то. он в темпы своего профиля лезет, а это с точки зрения вменяемого админа шиндовс ну совсем не проблема переназначить.

21 — 14.06.19 — 11:10

Так я уже писал что Temp переносил на разные диски и в вменяемым название.

Не помогло.

22 — 14.06.19 — 11:20

(21)

«Переносил папку Temp на другой диск — давая права на неё полный доступ всем.» — а надо было наоборот.

23 — 14.06.19 — 11:32

В том числе делал конкретно пользователю под которым запущен 1С сервер предприятие

Что не так?

24 — 14.06.19 — 11:44

«Что не так?» — «права на неё полный доступ всем»

Это уже последний вариант.

По умолчанию только этому пользователю были — и ошибка была такая же!

От того что я права дал всем — лучше не стало.

Разговор не о чем, тут что то другое.

Описание ошибки:
При обновлении конфигурации 1С: Комплексная автоматизация, ред. 1.1 при установке релиза 1.1.104.1 и запуска серверной базы в режиме 1С: Предприятие для завершения обновления релиза после согласия лицензионного соглашения возникла ошибка, которая фатально прерывала дальнейшую работу с базой:
Ошибка при выполнении файловой операции ‘v8srvr://ECO-SERVER2/1C-ECO82/Config/7ad7a83c-ceed-4eaf-871f-23830205ec2f.0’
по причине:
Ошибка при выполнении файловой операции ‘C:Usersadmin1CAppDataLocalTempv8_EBA6_7.tmp’. 131(0x00000083): Попытка поместить указатель на файл перед началом файла.

Найденные решения:

После подтверждения на продолжение обновления практически сразу же, в ближайшие секунды, долго ждать не приходилось.

Возникала ошибка. При повторном запуске базы в режиме 1С: Предприятие повторялось то же самое. Скрин не совсем тот, а уже сделанный позднее, когда ошибка себя проявила повторно, после обновления конфигурации другим релизом (об этом подробнее см. в конце публикации), но в точности иллюстрирующий ситуацию. Разница лишь в том, какой текст следует после «‘v8srvr://<имя_сервера>/<имя_базы>/Config/»

Вот полный текст ошибки

Сразу же при виде формулировки «Ошибка при выполнении файловой операции  ‘v8srvr://<имя_сервера>/<имя_базы>/Config/7ad7a83c-ceed-4eaf-871f-23830205ec2f.0’ по причине:» рука потянулась выполнить «Тестирование и исправление базы данных»

Но, увы, тестирование не повлияло на ситуацию. Ошибка вновь возникала. И тут внимание обратилось ко второй половине формулировки ошибки: «Ошибка при выполнении файловой операции  ‘C:Usersadmin1CAppDataLocalTempv8_EBA6_7.tmp’. 131(0x00000083): Попытка поместить указатель на файл перед началом файла.»

В этом пути явно присутсвует папка со временными файлами базы. Тогда было решено выполнить простую операцию удаления и добавления базы в списке баз, чтобы очистить пользовательские временные файлы, связанные с базой.

И это дало положительный результат. Обновление базы после этого было выполнено успешно.

P.S.

P.S.: ситуация имела повторное возникновение еще позднее (т.к. выполнялось продолжительное обновление конфигурации 1С: Комплексная автоматизация 1.1, было пропущено чуть более 20 релизов) но в сопряжении с ошибкой, очень похожей по формулировке на ту, что описана в описании ошибки Ошибка разбора XML: -[1,202] Фатальная ошибка: expected ‘>’ . Но, если ознакомиться с похожей ошибкой, то можно увидеть, что она тоже решилась в свое время удалением/добавлением базы в списке баз 1С: Предприятия 8, что очистило пользовательские файлы, связанные с базой и нормализовало дальнейшую работу без дополнительных действий, кроме тех, что описаны выше.

Оцените, помогло ли Вам предоставленное описание решения ошибки?

© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

24-04-2019

Журавлев А.С.
(Сайт azhur-c.ru)