1C Linux + сетевая шара
Добрый день.
Имеется 1С Linux 8.3.19.1264 на Astra Linux CE и Windows Server 2016 с расшаренной папкой для файловых БД 1С.
Папка монтируется через fstab как cifs в линукс успешно, права со стороны Linux позволяют создавать, удалять, изменять файлы, со стороны Windows полный доступ выдан всем.
После подключения БД в 1С и попытке запуска, зависает на загрузке конфигурационной информации, файл .cfl при этом создается.
При это локальные БД открываются нормально.
Подскажите пожалуйста куда копнуть, что бы заставить 1С работать с БД
peb
New member
У меня шара работала через samba, Я в smb.conf, принудительно переназначал права ко всей директории (детали не помню уже, давно было дело). Суть в том, что после каждой пользовательской операции в 1с, слетают права на директорию для других пользователей. В файловом варианте, будет очень медленно работать. Особенно, доки очень долго проводятся.
peb
New member
JoKeR174
New member
У меня шара работала через samba, Я в smb.conf, принудительно переназначал права ко всей директории (детали не помню уже, давно было дело). Суть в том, что после каждой пользовательской операции в 1с, слетают права на директорию для других пользователей. В файловом варианте, будет очень медленно работать. Особенно, доки очень долго проводятся.
К сожалению у меня БД лежит на Windows Server, впрочем там выданы права для всех пользователей без ограничения.
На линкусе в группу grp1cv8 пользователей добавил, на сервере создал и добавил.
Ничего не помогает, 1С так и висит в попытке загрузить БД, даже ума не приложу где хотя бы логи посмотреть на каком моменте она зависает, терминал ничего не показывает
kavjazz
New member
Здравствуйте. Столкнулся с такой же ситуацией. Вы как-нибудь решили проблему? Столкнулся с такой же ситуацией.
JoKeR174
New member
Здравствуйте. Столкнулся с такой же ситуацией. Вы как-нибудь решили проблему? Столкнулся с такой же ситуацией.
DmitryB2003
New member
Начните так: на стороне файлового сервера проверить ntfs права на папки и файлы. А на общую папку дать права на всех, чтобы только ограничения были по NTFS.
Возможно почитать про » Ошибка «Слишком много открытых файлов» или «Too many open files» В 1С на Linux «
oko
New member
*в сторону*
Если база 1С = куча файлов, лежащих в Windows-«шаре» (читай, SMB-протокол), а клиентские места уже развернуты под nix, то, imho, гораздо проще перетащить эту «шару» на такой же nix-сервер и раздавать ее клиентам через NFS-протокол. Шустрее и проще, ибо NFS нативен. Проблема есть только с синхронизацией (если делать mount.nfs удаленного NFS-каталога к локальной файловой системе клиента, то при падении удаленного сервера можно получить кучу сетевых и функциональных проблем на стороне клиента). Но это тоже решается.
JoKeR174
New member
Начните так: на стороне файлового сервера проверить ntfs права на папки и файлы. А на общую папку дать права на всех, чтобы только ограничения были по NTFS.
Возможно почитать про » Ошибка «Слишком много открытых файлов» или «Too many open files» В 1С на Linux «
На стороне файловой шары ограничений не было, БД не запускалась от слова совсем, даже при попытке создать новую БД, создавался один файл и на этом все, висеть так могло хоть сутками.
*в сторону*
Если база 1С = куча файлов, лежащих в Windows-«шаре» (читай, SMB-протокол), а клиентские места уже развернуты под nix, то, imho, гораздо проще перетащить эту «шару» на такой же nix-сервер и раздавать ее клиентам через NFS-протокол. Шустрее и проще, ибо NFS нативен. Проблема есть только с синхронизацией (если делать mount.nfs удаленного NFS-каталога к локальной файловой системе клиента, то при падении удаленного сервера можно получить кучу сетевых и функциональных проблем на стороне клиента). Но это тоже решается.
Это конечно как вариант, не проверяли через nfs, но при раздаче папки через самбу, та же самая ситуация, а серверов Linux еще не имеем, до них далеко
oko
New member
to JoKeR174
Так-то для Win существуют реализации NFS-сервисов. Устойчивость и качество, конечно, надо тестировать.
ferrim
New member
Столкнулся с той же проблемой. с локальными базами работает нормально при подключении к сетевым — виснет.
такой группы не существует.
для того чтобы не было проблем с количеством открытых файлов задал такой же параметр как и в винде:
в Linux это 1024, а в Windows — 16384. Для этого в файле /etc/security/limits.conf нужно добавить две строки в конец:
* — nofile 16384
root — nofile 16384
Установка полного доступа (777) к папке 1с ничего не дало
монтирование сетевой папки на пользователя на рута и на nobody также не принесло результата
sudo mount -t cifs //192.168.0.11/1S-Base /home/fur/1S-Base -o username=guest,password=,rw,uid=65534,gid=65534,file_mode=0777,dir_mode=0777
Montfer
New member
дааааавным-давно экспериментировал с шарами. там это выглядело как
sudo mount.cifs //ip-server/katalog /mnt/kakoito_katalog -o user=username,pass=password,uid=user_id,gid=user_id_group
но мне это не понравилось и сделал монтирование через fstab, правда уже в рамках домена ad
ferrim
New member
fstab это для монтирования при загрузке, в любом случае монтируется все отлично и полный доступ каталоги и файлы имеют, просто через файловый менеджер можно зайти по сети или в примонтированную папку и сделать там все что угодно. Проблема в том, что при всем при этом, 1ска при загрузке базы из примонтированной папки просто виснет.
Montfer
New member
поищи на форуме, что то про зависание тут писали уже
кстати, тов. oko накидывал идеи https://forum.astralinux.ru/threads/3971/
но помогло или нет,топикстартер не удосужился ответить
ferrim
New member
поищи на форуме, что то про зависание тут писали уже
кстати, тов. oko накидывал идеи https://forum.astralinux.ru/threads/3971/
но помогло или нет,топикстартер не удосужился ответить
только NFS сервер еще не пробовал на винду поставить. Остальное не помогает
Таки проще, кажись, перейти на Клиент-сервер и не парить моск.
ferrim
New member
Проблема решена!
Астру удалил поставил Убунту — всё работает.
вобщем хрень эта Астра. Года через 3-5 заскочу проверю, провели ли они работу над ошибками.
oko
New member
to ferrim
А у вас, я извиняюсь, принципиально извращенная идея: файлы базы на Win, а хосты юзеров на Astra Linux? Если так, то при чем тут «nofile 16384«? Если все-таки файлы раздаются Samba из-под Astra Linux, а клиенты под Win или Astra Linux, то при чем тут «только NFS сервер еще не пробовал на винду поставить«?
При такой постановке задачи, пожалуй, вам и переход на Ubuntu не на долго поможет, ага.
Usermaster
New member
ferrim
New member
to ferrim
А у вас, я извиняюсь, принципиально извращенная идея: файлы базы на Win, а хосты юзеров на Astra Linux? Если так, то при чем тут «nofile 16384«? Если все-таки файлы раздаются Samba из-под Astra Linux, а клиенты под Win или Astra Linux, то при чем тут «только NFS сервер еще не пробовал на винду поставить«?
При такой постановке задачи, пожалуй, вам и переход на Ubuntu не на долго поможет, ага.
Задача была запустит 1с на Астре с базой из сетевой папки виндовс, само монтирование проходит без проблем, все работает, права полные, не работает только 1с из сетевой папки. Локально 1с работает без проблем. На убунте не потребовалось никаких плясок проводить, примонтировал папку и все заработало. Использованная версия астры orel-2.12.45.5-23.07.2022_07.53.
да, основной комп на винде (всего 2 пользователя поэтому никакого выделенного 1с сервера), 2й слабенький, поэтому туда поставлен линукс, обычно я ставлю лубунту, но тут решил поэкспериментировать с астрой. Эксперимент считаю неудачным, астра еще не готова к использованию.
nofile — это из инструкции https://infostart.ru/1c/articles/1573101/ по которой все работает для убунты,
только NFS сервер еще не пробовал на винду поставить — Похожая проблема (для убунты) была описана на одном из форумов и там монтирование папки через nfs решало это. А в серверных windows можно включить компонент NFS server, а также есть платные nfs сервера и на рабочие станции windows 7, 10, 11.
Пожелание. Разработчики Астры подружите с 1сниками, решите проблему.
Сетевая файловая система NFS с аутентификацией Kerberos в домене FreeIPA
«В случае необходимости использования мандатного управления доступом на сетевых дисках, их монтирование в файловую систему ОС должно осуществляться только с использованием файловой системы CIFS, поддерживающей расширенные (в т.ч. мандатные) атрибуты пользователей;»
«Руководство по КСЗ. Часть 1 РУСБ.10015-01 97 01-1» п. 17.3. «Условия применения»
При настройках по умолчанию аутентификация через Kerberos в файловой системе NFS осуществляется:
Таким образом, монтирование сетевого ресурса NFS может быть выполнено любым пользователем или процессом. С одной стороны, это позволяет автоматически монтировать общие разделяемые ресурсы до входа первого пользователя, но, с другой стороны, может стать причиной утечки или повреждения данных при некорректно настроенных правах доступа.
В статье рассматривается использование NFSv4. Более старые версии использовать не рекомендуется, так как они подвержены известным уязвимостям и некорректно работают при использовании аутентификации Kerberos.
При некорректно настроенных параметрах подключения NFS может выполнять монтирование с произвольным понижением уровня протокола (NFSv3 вместо NFSv4) и/или изменением типа аутентификации (аутентификация SYS вместо Kerberos), что также является источником потенциальных уязвимостей.
Описание стенда
- контроллер домена FreeIPA:
- имя сервера ipa0.ipadomain0.ru;
- имя администратора admin;
- IP-адрес контроллера домена не используется, так как подразумевается наличие настроенной службы DNS;
- имя клиента host0.ipadomain0.ru;
Настройка сервера
sudo sed -i ‘s/^[[:space:]]*NEED_SVCGSSD[[:space:]]*=.*/NEED_SVCGSSD=»yes»/’ /etc/default/nfs-kernel-server sudo sed -i ‘s/^[[:space:]]*NEED_GSSD[[:space:]]*=.*/NEED_GSSD=yes/’ /etc/default/nfs-common
sudo sed -i ‘s/^[[:space:]]*NEED_IDMAPD[[:space:]]*=.*/NEED_IDMAPD=yes/’ /etc/default/nfs-commonЕсли билет Kerberos был получен до регистрации службы, то после регистрации службы он должен быть обновлен (получен повторно).
ldapmodify -x -D «cn=directory manager» -W -h ipa0.ipadomain0.ru << EOT
dn: cn=IPADOMAIN0.RU,cn=kerberos,dc=ipadomain0,dc=ru
changetype: modify
add: krbSupportedEncSaltTypes
krbSupportedEncSaltTypes: des-cbc-crc:normal
EOT
ldapmodify -x -D «cn=directory manager» -W -h ipa0.ipadomain0.ru << EOT
dn: cn=IPADOMAIN0.RU,cn=kerberos,dc=ipadomain0,dc=ru
add: krbSupportedEncSaltTypes
krbSupportedEncSaltTypes: des-cbc-crc:special
EOT
ldapmodify -x -D «cn=directory manager» -W -h ipa0.ipadomain0.ru << EOT
dn: cn=IPADOMAIN0.RU,cn=kerberos,dc=ipadomain0,dc=ru
add: krbDefaultEncSaltTypes
krbDefaultEncSaltTypes: des-cbc-crc:special
EOTРазделяемые ресурсы определяются в конфигурационном файле /etc/exports. Подробно про возможные параметры разделяемых ресурсов см. man exports.
В NFSv4 все сетевые ресурсы предоставлены единым деревом каталогов. Соответственно, в списке разделяемых ресурсов один из них должен быть обозначен как корневой. Для этого используется параметр fsid=0. Отсутствие или некорректное определение корневого ресурса ведёт к неработоспособности примонтированных ресурсов, и, в случае монтирования домашних каталогов, к невозможности входа пользователей.
Пример файла с ресурсами (экспортируется домашний ката/etлог пользователей /home и созданный каталог /export):
/ *(rw,fsid=0,no_subtree_check,sec=krb5:krb5i:krb5p) /home gss/krb5i(rw,sync,no_subtree_check) /export *(rw,sync,no_subtree_check,no_root_squash,sec=krb5:krb5i:krb5p)
В приведенном примере первый ресурс — корневой, и использованы два альтернативных синтаксиса для «подчинённых» ресурсов NFSv4 с аутентификацией Kerberos.
В целях обеспечения безопасности в разделяемых ресурсах используется технология подмены идентификатора суперпользователя (root_squash). При этом операции, инициированные суперпользователем, выполняются от имени nobody:nogroup или от имени Kerberos-пользователя (См. ниже Настройка клиентской аутентификации Kerberos). Об этом ограничении следует помнить планируя настройку прав доступа в разделяемых ресурсах.Для того, чтобы в «подчиненные» ресурсы была разрешена запись, запись должна быть разрешена в корневой ресурс.
Для того, чтобы при доступе к «подчиненным» ресурсам корректно работала аутентификация Kerberos, корневой ресурс должен использовать такой же тип аутентификации.
Параметр no_root_squash неработоспособен, то есть подмена идентификатора суперпользователя выполняется всегда. См. ниже Настройка клиентской аутентификации Kerberos.