Доброго времени суток!
Задача такая: перевести файловое хранилище на работу через сервер хранилища конфигурации, чтобы была возможность соединения с ним по tcp.

Компонента установлена, работает под пользователем с полными правами.
Создал НОВОЕ хранилище, путь указал по tcp(папку хранилища разместил в корневом каталоге для хранилищ конфигурации) - все работает хорошо.

Проблема: Копирую в корневой каталог папку со СТАРЫМ хранилищем(которое еще не работает по tcp), через конфигуратор пытаюсь присоединиться к хранилищу по tcp: ошибка соединения с хранилищем. P.S. Службу останавливал на момент копирования папки СТАРОГО хранилища.

Прошу подсказать как подключиться к скопированному файловому хранилищу в корневой каталог для хранилищ по tcp?

Так нельзя
Точнее можно но версия и разрядность платформы 1С должны совпадать

(1) Спасибо за ответ. Проверил этот момент, версия и разрядность платформы 1С совпадали.

Проблема была в том, что при создании НОВОГО хранилища пользователь под которым работает компонента в свойствах папки -> безопасность прокидывается; а при простом копировании естественно этого пользователя не было.

Решил так: скопировал папку НОВОГО хранилища, удалил содержимое и скопировал содержимое СТАРОГО хранилища. Присоединился по tcp, все работает.

Не понимаю в чем проблема. Хранилища одновременно работать могут как через сервер так и быть расшаренными папки по сети.
Мы так и используем. Обычно рабочая база пашет на более старом релизе платформы и потому подрубаемся к хранилищу напрямую, а тем временем разработчики из новой платформы на новом сервере хранилищ работают по TCP.
От того сервер хранилищ или нет, структура данных не отличается, по TCP просто надежность выше и по сети хранилище так просто не удалить, если его не расшаривать в сеть

(3) А вы отчаянные.😱
И разработку вести на разных версиях платформы и с хранилищем боевой базы работать на разных версиях платформы, да ещё и с хранилищем боевой базы работают разработчики напрямую.....
Чтобы быть уверенным, что при такой схеме ничего не сбойнёт, это прям очень жёстко должны быть выстроены регламенты работы и взаимодействия.

(4) Угу я тоже думал что когда хран не пускает к себе с другой версии платформы это фигня
Обойду через подмену в http с помощью OpenResty и все ОК будет
Оказалось не совсем ОК и бывают изредка проблемы

(4) да откуда у вас так много страху я не понимаю)) хранилища расширений конфигураций это вам не всю ERP в хранилище загрузить
У нас единственно проблемы были, когда все сидели без сервера хранилищ, вот там хранилище рушилось порой, как и рушатся файловые базы 1С при проблемах сети и зависших конфигураторах
Сама же 1С хранилища рееедко дорабатывает и поэтому фиолетово какими версиями платформы вы в них лезете.
Для малых групп разработчиков до 10 вполне пойдет так работать, все оперативно, быстро разрабатывается, тестируется и применяется. Нас устраивает. Не лезьте в наш монастырь со своей верой)))

(6) >> Не лезьте в наш монастырь со своей верой.

Боже упаси Вас подумать будто бы я лезу.
Если вам всё норм, то работайте, как хотите.

Я всего лишь делюсь своим мнением и опытом. Слушать меня или пропустить мимо ушей - ваш выбор.

К тому же в (4) ни слова о расширениях не сказано было.
Может с расширениями и нормально так работать, как вы.

Но с основной конфигурацией такая схема точно недопустима. Да, оно как-то может вполне себе работать, но рано или поздно сбойнёт или само хранилище, или конфигурация, или и то и другое. После нескольких восстановлений, включая таких, когда хранилище пришлось пересоздавать с потерей всей истории, я в такие игры больше не играю.
У основной конфигурации продуктивной базы только одно хранилище. С ним никто из разработчиков вообще не работает. Оно по сути используется только доя хранения всей истории изменений, попавших в конфу боевой базы. Подключается к этому хранилищу только один человек, который накатывает окончательные изменения и доработки в продуктив (мерджит дев в мастер).
А для разработчиков - отдельные базы с отдельными хранилищами под каждый проект/задачу. И только какие-то совсем мелкие/простые/короткие задачи можно и в одном хранилище делать нескольким разрабам.

>> Для малых групп разработчиков до 10 вполне пойдет

Для групп более 10 1С-овское хранилище вообще подходит уже весьма условно и с огромным количеством оговорок.

(7) >Для групп более 10 1С-овское хранилище вообще подходит уже весьма условно и с огромным количеством оговорок.

Уже от 5 разработчиков на одну конфу/хранилище проблемы
Приходится вести разработку в отдельных не подключенных базах
А через пустые базы (без данных, с подключением к храну дев) только помещать доработки в хран, обновляя из него тестовые базы (с данными) для аналитиков

(8) как же вам сложно живется, капец...
(7) есть такое понятие как бэкапы и можно легко бэкапить базы хранилищ, что мы и делаем.
А по поводу сбоев в живой базе, ничего серьезнее чем привносит сама фирма 1С по части сбоев да динамические обновления я наверное не встречал, ой нет, по одному месту накопители шли, ну это так лирика)))
Блин все тут по своему шуганные, чего вы еще накручиваете и накручиваете? Что у вас травмы не проходят психологические? Опыт все дела, но может хватит нагонять панику?

PS
Чтобы вам спалось хуже, мы постоянно применяем динамические обновления, когда можем)))

(9) Так у вас и разработчиков вероятно много нет
Или вы их потыкайте, может они уже не живые ))

Тебе надо добавить несколько объектов метаданных
Как ты это сделаешь без захвата корня?
А если это одновременно надо не только тебе но и всем прочим разработчикам?

Причем ладно корень, это легко решаемо
Захватил, быстро новые метаданные добавил даже не именуя как надо и все закинул в конфу отпустив корень
Далее захватываешь уже только свои объекты и правишь их как надо

Проблема то в (общих) модулях, огромных, которые заразы пересекаются по задачам

(10) отчеты и обработки я просто создаю заранее болванок гору, обработка 1 2 3 ... Отчет 1 2 3 .... Кому надо захватывает и пилит
Регистры документы справочники, ну да сопли не жуешь (чай не на скуле ручками это создаешь), сразу создаешь нужной структуры, сдаешь, а потом на расслабоне пилишь
Общие модули разбиваешь по направлениям учета и часто это один модуль 1 человек
Да и в жопу горячки нет, что прям вот блин умри, но отдай мне объект

(10) гораздо хуже обстоят дела с постоянными тормозами базы при применении изменений, что отчеты и обработки приходится как внешние отлаживать, про это жопное неудобство не все говорят

(8) Последнее обновление ЕРП (26.100) помещалось в хран 9 часов(!!). сетка гигабит, серваки неслабые. и во что только упирается эта сказка

(13) потому и надо разработку вести на все 100% в расширении, желательно только одном, а не в зоопарке и подрубить хранилище конфигураций

(13) Врут про серваки неслабые и сетку гигабит
Может они и неслабые и гигабит (что странно ибо для серверов давно есть 2.5 и 10 и даже больше гигабит)
Но делят через виртуалки на кучу поменьше

Хотя обычно все упирается в дисковую
Проверьте CrystalDiskMark скорость дисковой
Там обычно сетевое хранилище общее на все сервера делают а потом страдают

(13) EDT попробуйте, там такая же шляпа, работать невозможно с ERP ни в каком виде, осеовная это конфа или расширения, уволят раньше за простои

(13) и проблема не в сети. Тупая однопоточная работа конфигуратора и сервера, сеть простаивает 99% времени

(11) >Общие модули разбиваешь по направлениям учета и часто это один модуль 1 человек

И как вы разбиваете многострадальный(ые) МодификацияКонфигурацииПереопределяемый?

(16) У меня на моем i9 совершенно EDT не тормозит
Ничего не знаю
Утаскиваю базы и кодю на своем компе, даже отладку ЕРПУХ без внешних обработок нормально, запуск 5-10 сек
Затем уже переношу через тормозные VPN с RDP

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

(20) Дада
Особенно когда в расширение один объект добавляешь
А оно как следом разной фигни как потянет автоматом...
Да еще собако с автозахватом в хранилище расширения

(19) у меня такие мощностм только дома, а дома я не ралотаю
Показать фирмы, где даже сервера десятилетиями не обновляют не говоря о ПК?

(21) вообще пофиг, мы не комплексуем по этому поводу