Ошибка при формировании файла usr

   antoneus

30.07.10 — 16:15

Всем здравствуйте. Цепляюсь из одной sql базы к другой sql базе с помощью ODBCDatabase. На команде База.ПрисоединитьИБ(Путь, Пользователь, Пароль) выскакивает сабж. Как лечить? База лежит на сервере под Windows Server 2000.

Блин, писал и тестировал в терминале под убунтой — всё пахало. Радостно пошёл показывать юзеру, который в терминале под виндой — и такие грабли. Подскажите кто чем может. Фпоиске был. Спасибо.

Кстати, на самом сервере пробовал запускать под админом — то же самое.

   Рэйв

1 — 30.07.10 — 16:16

Ну логично, там где слово «доступ», помотреть все ли права

   antoneus

2 — 30.07.10 — 16:17

говорю же, на серваке запускал под админской учеткой — и то же самое. Админ клянется, что права все

   Рэйв

3 — 30.07.10 — 16:19

(2)Под админской учеткой- не считается.Юзеры то не под ней сидят стопудово.А админа проверить бы надо насколько не врет в своих клятвах..

   Рэйв

4 — 30.07.10 — 16:20

+(3)Или кто-то заходит и на вводе пароля остановился или завис. Тогда блокируется имхо по чтению другим потоком.

   vde69

5 — 30.07.10 — 16:20

users.usr — блочится с момента открытия окна авторизации и до запуска глобальника, сделано это для исключения коллизий изменения списка пользователей и входа в систему

   Рэйв

6 — 30.07.10 — 16:21

приложением верне, не потоком

   antoneus

7 — 30.07.10 — 16:29

а в списке открытых файлов он должен быть когда лочится?

   Это_mike

8 — 30.07.10 — 16:30

по-моему, ПрисоединнитьМД кладет на блокировку. По крайней мере, я не разу не обламывался по блокировке.

   vde69

9 — 30.07.10 — 16:30

(7) если терминальная сесия — то нет, если по сети — да

   Рэйв

10 — 30.07.10 — 16:30

(7)По идее должен. Но не обязательно. Его могут открыть, прочитать, закрыть и держать лоченым до запуска глобальника.

   antoneus

11 — 30.07.10 — 16:30

(8) тут не МД, а ИБ :)

   Cthulhu

12 — 30.07.10 — 16:32

кто-то висит на вводе пользователя+пароля
по сусалам гаду!

   antoneus

13 — 30.07.10 — 16:33

да с ней тока этот юзер и работает. а он стопудово не висел, когда мы с ним ето дело запускали.

   Рэйв

14 — 30.07.10 — 16:33

(13)Тогда посмотри зависшие сессии.

   antoneus

15 — 30.07.10 — 16:39

хотя, не, туплю, в той к которой цепляемся — как раз таки все и работают. вот же блин, три офиса оббегать, штоле. а ещё народ по удаленке в соседней области сидит ыхыхы

   antoneus

16 — 30.07.10 — 16:39

нету зависших (

   vde69

17 — 30.07.10 — 16:42

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

   Cthulhu

18 — 30.07.10 — 16:43

(16): есть.

   antoneus

19 — 30.07.10 — 16:44

(17) сохранился

   Cthulhu

20 — 30.07.10 — 16:44

(18)+: они в мониторе не светятся есичо.
я таких отлавливал только прокрикивая с сисадмином я монитор он сессии.

   vde69

21 — 30.07.10 — 16:46

(19) если сохранился — значит или прав нету или уже разлочили, попробуй заново подрубится, если не выйдет — права

   antoneus

22 — 30.07.10 — 16:49

странно. попробовал подцепиться к другой, потом снова к этой — и заработало. чудны дела твои…

   antoneus

23 — 30.07.10 — 16:50

в общем усем спасибо, сисадминов с праздником!

  

Рэйв

24 — 30.07.10 — 16:51

(16)Сессии не только в скуле смотреть надо но и в сервере 1С

Нужно проверить, чтобы у файлов был тот же владелец, что и пользователь Apache. Кроме того, выставить необходимые права на папки и файлы.
chown bitrix:bitrix file.php

Для массовой смены владельца можно использовать:
find . -type f -exec chown bitrix:bitrix {} ;

Вот универсальное решение:

cd /home/bitrix/www
find . -type d -exec chmod 775 {} ;
find . -type f -exec chmod 664 {} ;
find . -type d -exec chown bitrix:bitrix {} ; 
find . -type f -exec chown bitrix:bitrix {} ;

/home/bitrix/www — директория где лежит сайт
bitrix:bitrix — пользователь и группа под кем запущен демон httpd
Пользователя и группу можно подсмотреть в phpinfo.

Администраторы и пользователи при работе в сервером 1C установленном на Linux часто сталкиваются с ошибками которые не встречаются на ОС MS Wndows. Связано это с тем что первоначально программа 1С Предприятие долгое время была ориентированна только на работу с ОС Windows и ее портировании  на ОС Linux началось сравнительно недавно. Из-за особенностей архитектуры операционной системы Linux, некоторые моменты, которые под ОС Windows были само собой разумеющимися и не вызывали вопросов, тут требуют определенной настройки. Рассмотрим наиболее часто встречающиеся ошибки при работе клиентов с сервером на ОС Linux.

Оглавление:

1. Ошибка загрузки библиотеки libfontconfig.so

2. Не печатается документ с штрихкодом. (EObjectNotFound)

3. Проблема с кодировкой в загружаемом файле в 1С

4. На сервере отсутствуют шрифты из состава Microsoft Core Fonts

5. Ошибка доступа к файлу Read-only file system

Ошибка загрузки библиотеки libfontconfig.so

Пример полного текста ошибки:

Ошибка загрузки библиотеки libfontconfig.so по причине: Библиотека не обнаружена.
Часть функций будет недоступна.
Обратитесь к разделу справочной системы «1С:Предприятие - Работа пользователя –
Особенности работы в Linux – Внешние библиотеки»

Описание:

Не запускается база в режиме 1С:Предприятия.

Решение:

Установим недостающие пакеты:

yum install ImageMagick freetype libgsf glib unixODBC libusb libicu freetype expat libpng12 -y

Не печатается документ с штрихкодом. Ошибка (EObjectNotFound)

Пример полного текста ошибки:

(EObjectNotFound) Object «СЗК_ЗащищеннаяОбработка» is not found

Описание:

Не печатается документ с штрихкодом. Текст ошибки может быть связан с получением отраслевой лицензии(для отраслевых конфигураций).

Решение:

Установим недостающие пакеты(в нашем случае нужна была только libpng12):

yum install libicu freetype expat libpng12

Проблема с кодировкой в загружаемом файле в 1С

Пример полного текста ошибки:

Ошибка загрузки библиотеки libgsf-1.so по причине: Библиотека не обнаружена. Часть функций будет недоступна.

Пример вывода сообщения об ошибке в программе 1С:

Пример вывода сообщения Ошибка загрузки библиотеки libgsf-1.so

А это пример некорректного отображения символов:

Пример некорректного отображения символов в 1С

Описание:

При загрузке данных из файла символы преобразовываются некорректно.

Решение:

Установим недостающие пакеты(в данном случае необходима была libgsf):

yum install ImageMagick freetype libgsf glib unixODBC libusb libicu freetype expat libpng12 -y

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

На сервере отсутствуют шрифты из состава Microsoft Core Fonts

Пример полного текста ошибки:

На сервере отсутствуют шрифты из состава Microsoft Core Fonts.
Внешний вид приложения может отличаться от ожидаемого.
Процедура установки описана в справочной системе в разделе
«1С:Предприятие – Работа пользователя-Особенности работы в Linux – использование шрифтов».

В веб-клиенте это сообщение выглядит так:

Пример окна сообщения На сервере отсутствуют шрифты из состава Microsoft Core Fonts на веб-клиенте 1С

В клиенте 1С Предприятие так:

Окно ошибки 1С На сервере отсутствуют шрифты из состава Microsoft Core Fonts

Описание:

При первичном запуске 1С:Предприятия выдается сообщение «На сервере отсутствуют шрифты».

Это не мешает дальнейшему запуску системы. И при последующих запусках ошибка не появляется.

Решение:

Нам понадобятся пакеты шрифтов:

  • fontconfig-2.10.95-11.el7.x86_64.rpm;
  • msttcorefonts-2.5-1.rpm

Выполним установку пакетов.

yum localinstall fontconfig-2.10.95-11.el7.x86_64.rpm

yum localinstall msttcorefonts-2.5-1.rpm

Ошибка доступа к файлу Read-only file system

Пример полного текста ошибки:

Ошибка доступа к файлу /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/snccntx0114ae32-dd36-1e86-005056b7219:
Read-only file system

Пример окна с ошибкой:Окно ошибки 1С Ошибка доступа к файлу Read-only file system

Описание:

Возникновение данной ошибки возможно, например, при миграции серверов между хостами.

Решение:

1. Выполним перезагрузку сервера

2. Если проблема не ушла – выполним перемонтирование дисков.

Иногда требуется настроить синхронизацию между базами 1с через каталог обмена. Но настройка не всегда так очевидна, как казалось бы…

В этой статье я привел решение ошибки «Каталог обмена информацией не существует» в случае, если сервер 1с установлен на Linux и Windows сервере.

  • Решение для Linux сервера 1с
  • Решение для Windows сервера и файлового режима работы 1с

Решение для сервера 1с на Linux на примере Centos Stream.

Скорее всего вы получаете одну из нескольких ошибок:

Прямое подключение к информационной базе недоступно на сервере под управлением ОС Linux — ошибка говорит сама за себя, нам потребуется настройка сетевого обмена.

Ошибка подключения: Каталог обмена информацией не существует — данная ошибка возникает из-за того, что при настройке обмена авторизация в сетевой папке происходит учетной записью usr1cv8 из под Linux.

Для решения данной проблемы нам придется смонтировать сетевую папку в Linux под учетной записью, под которой работает сервер 1с.

1) Расшариваем сетевую папку на вашем файловом сервере и даем права на запись для учетной записи guest.

У меня будет //192.168.128.32/public/1C_Share

2) Установим cifs-utils на Linux сервере 1с:

yum install cifs-utils #для Centos
apt install cifs-utils #для Ubuntu

3) Создадим каталог для обмена, в который будет монтироваться сетевая папка:

mkdir /1C_Share

4) Посмотрим uid пользователя usr1cv8, чтобы при монтировании указать его владельцем: каталога

less /etc/passwd

5) Смонтируем нашу сетевую папку в каталог 1С_Share:

mount -t cifs //192.168.128.32/public/1C_Share /1C_Share -o user=guest,password=,uid=993

Теперь в настройках 1с указываем каталог для обмена 1C_Share и смотрим есть ли подключение:

Каталог обмена информацией не существует

6) Сейчас сделаем так, чтобы сетевая папка в Linux монтировалась автоматически после перезагрузки:

nano /etc/fstab и в конфиге добавляем внизу

//192.168.128.32/public/1C_Share /1C_Share cifs username=guest,password=,uid=993,iocharset=utf8,nofail 0 0

Решение для сервера 1с установленном на Windows Server.

Здесь все гораздо проще. Нужно авторизоваться в сетевом каталоге под учетной записью с которой у вас запущена служба 1с. У меня это USR1CV8.

Для этого под пользователем USR1CV8 переходим в Панель управления — Диспетчер учетных данных — Учетные данные Windows и добавляем адрес сервера //192.168.128.32 с данными авторизации, которые вы указали на файловом сервере.

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

Стоит посмотреть права для пользователя на вкладке Безопасность:

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

Первое что необходимо сделать — это проверить права на файлы и папки в нужном каталоге. Права на папку должны быть 755, на файлы 664. Ни в коем случае не выставляйте права 777 на папки или файлы, даже на время. 

В моём случае этот метод не сработал, я стал копать дальше. Нашел такой совет. в файле /bitrix/php_interface/dbconn.php установить такие константы. 

define( "BX_FILE_PERMISSIONS", 0660 );

define( "BX_DIR_PERMISSIONS", 0775 );

@umask( ~BX_DIR_PERMISSIONS );

@ini_set( "memory_limit", "512M" );

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

find . -type d -exec chmod 775 { } ;

find . -type f -exec chmod 664 { } ;

В моём случае решение оказалось куда проще.  Все сайты лежали в корневой директории, один из них являлся общим ядром. Но по какой-то причине прекратился общий доступ к «главному сайту» и всё что нужно было сделать — это открыть доступ.

Поскольку сайты на учётных записях закрыты процессы, запущенные на одном сайте, не имеют прав для обращения к каталогам, выходящим за пределы этого сайта. Для доступа из окружения веб-сервера потребуется открыть общий доступ к каталогу. Мой проект находится на beget и эта операция делается очень просто через файловый менеджер.

  1. Зайдите в нужную директорию
  2. В верхней части экрана нажмите на кнопку “Инструменты” -> “Настроить общий доступ к текущей директории”: 
  3. Установите переключатели “Чтение и запись” и “Включая вложенные папки”, нажмите кнопку “Открыть доступ”: 

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

Понравилась статья? Поделить с друзьями:
  • Ошибка при формировании уставного капитала
  • Ошибка при формировании титула покупателя
  • Ошибка при формировании счет фактуры
  • Ошибка при формировании сзв тд
  • Ошибка при формировании сводной таблицы