# 7. Устранение неисправностей Диагностика и решение проблем # Синхронизация с доменом не выполняется ## Симптом Пользователи из домена не появляются в Printum или изменения в домене не применяются. ## Диагностика ### Шаг 1. Проверить настройки домена Перейдите в **Настройки → Интеграции → Домены**. Убедитесь, что домен добавлен и настроен. ### Шаг 2. Запустить тестовый импорт В карточке домена нажмите **«Тестовый импорт»**. При ошибке отобразится описание проблемы. Большинство проблем синхронизации связано с настройками подключения к домену, областью поиска пользователей или настройками атрибутов. | Ошибка | Причина | Решение | | :---------------------------------------- | :--------------------------------------------------- | :---------------------------------------------------------------------------- | | Ошибка подключения / `Connection refused` | Неверный адрес или порт домена, либо LDAP недоступен | Проверьте `ldap://адрес:389`, сетевую доступность и порт `389` или `636`. | | Неверный пароль / `Invalid credentials` | Неверный логин или пароль доменной учётной записи | Проверьте учётные данные. Учётная запись должна иметь права на чтение домена. | | Нет пользователей при импорте | Неверный стартовый уровень поиска или фильтр | Исправьте **Стартовый уровень поиска** и **Фильтр** в настройках домена. | | `certificate verify failed` | Ошибка проверки сертификата при использовании LDAPS | Проверьте сертификат LDAP-сервера и цепочку доверия сертификатов. | ### Шаг 3. Проверить расписание синхронизации В разделе **«Расписание»** карточки домена убедитесь, что расписание синхронизации настроено. При необходимости запустите синхронизацию вручную. ### Шаг 4. Проверить обязательные атрибуты В разделе **«Атрибуты»** карточки домена убедитесь, что заполнены все обязательные атрибуты: * Логин; * Фамилия; * Имя; * Идентификатор в домене; * Email. ### Что приложить к обращению в поддержку * вывод команды: ```bash bash /opt/printum/logs.sh ``` * версию системы: ```bash cat /opt/printum/.version ``` * описание сценария и шагов воспроизведения; * ОС сервера. ## Связанные страницы - [Расписание синхронизации с доменом](http://wiki.printum.io/books/4-integracii/page/raspisanie-sinxronizacii-s-domenom) - [Настройка атрибутов домена](http://wiki.printum.io/books/4-integracii/page/nastroika-atributov-domena) - [Интеграция с Active Directory](http://wiki.printum.io/books/4-integracii/page/integraciia-s-active-directory) # Проблемы печати # Задание не появляется в очереди печати ## Симптом Пользователь отправил документ на печать, но задание не появляется в разделе **Управление → Задания** личного кабинета и в разделе **Печать** встроенного приложения на МФУ. ## Условия возникновения - Используется отложенная печать через клиента ПринтМенеджера. ## Диагностика ### Шаг 1. Проверить статус службы клиента ПМ **Windows:** Win+R → `eventvwr` → Журналы Windows → Приложение → источник _Print Manager Client_. Найти ошибки (красные/жёлтые записи). **Linux:** ``` sudo systemctl status printum-printmanager-client.service sudo journalctl -u printum-printmanager-client.service ``` ### Шаг 2. Типовые ошибки в логах - **No user {'i.sokolov'} is authorized, removing all printers.** Эта ошибка означает, что сотрудник с именем i.sokolov, авторизованный в операционной системе Windows, не авторизован в системе управления печатью.  Откройте раздел “Сотрудники” на сервере, убедитесь, что сотрудник с именем i.sokolov существует и имеет правильный SID. Также проверьте, что токен доступа `access_token` введен правильно. - **Error in VirtualPrintersUpdater: HTTPSConnectionPool(host='192.168.1.1, port=8080): Max retries exceeded with url: /direct_printers/** Ошибка означает, что программа не смогла подключиться к серверу c адресом 192.168.1.1 и портом 8080. Проверьте, что сервер доступен по этому адресу с этого компьютера. - **Error in VirtualPrintersUpdater: (1789, 'LookupAccountName', 'Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом.')** Ошибка означает, что программа не смогла подключиться к домену, для получения необходимых данных. Проверьте соединение с доменом. Если ошибка возникает при отправке документа от локальной учётной записи пользователя, убедитесь, что этот пользователь входит в рабочую группу WORKGROUP, а не в какую-либо другую. - **Job 00021 for VersaLink_B405_XXXXXXXXX failed: Error: 401** Ошибка означает, что программа не смогла подключиться к CUPS из-за неправильных логина-пароля или настроек шифрования. Проверьте настройки Сервера печати, куда добавлен принтер для прямой печати. Так же проверьте, что включена настройка ALLOW_BYPASS_PRINTING в Настройках печати. - **AssertionError: Adding printer Printum means critical error. Reinstall this printer manually or application entirely.** Ошибка означает, что при старте службы, программа не нашла принтер Printum с драйвером Printum XPS. Т.е. либо самого принтера с таким именем нет, либо у него установлен неверный драйвер. Удалите такой принтер вручную, и переустановите программу. - **http.client.RemoteDisconnected: Remote end closed connection without response** Ошибка встречается в отказоустойчивой конфигурации. Происходит, если в конфигурационном файле клиента ПМ стоит флаг `use_cups_ssl: false` Для исправления ошибки поменяйте значение. ### Шаг 3. Проверить наличие принтера Убедитесь, что в системе присутствует виртуальный принтер с именем **Printum** и он использует драйвер Printum XPS. ## Что проверить перед эскалацией - Логи клиента ПринтМенеджер без ошибок - Служба клиента запущена - Принтер Printum присутствует на АРМ - Пользователь существует в Printum ## Логи и диагностические данные ### Где смотреть логи - **Клиент ПМ Windows** — Отправка заданий на печать на ОС Windows Откройте `eventvwr` → Журналы Windows → Приложение → источник _Print Manager Client_ - **Клиент ПМ Linux** — Отправка заданий на печать на ОС Linux `sudo journalctl -u printum-printmanager-client.service` - **printmanager-app** — Основной контейнер ПМ — обработка HTTP-запросов, приём заданий от клиентов `sudo docker logs printmanager-app` ### Что искать в логах - Выявить ошибки запуска сервиса клиента ПМ. - Выявить ошибки передачи данных от клиента на сервер. - Выявить ошибки обработки API-запросов в printmanager-app. - Определить причины возврата кодов 4xx/5xx. ### Что приложить к обращению в поддержку - Логи клиента ПМ: Windows — Просмотр событий (`eventvwr`) → Журналы Windows → Приложение → источник _Print Manager Client_; Linux — `sudo journalctl -u printum-printmanager-client.service` - Версию ПринтМенеджера: `cat /opt/printmanager/.version` - Описание сценария и шагов воспроизведения - ОС рабочей станции и сервера ## Связанные страницы - [Задание не распечатывается на принтере](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadanie-ne-raspecatyvaetsia-na-printere) - [Принтеры не появляются на рабочей станции](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/printery-ne-poiavliaiutsia-na-rabocei-stancii) # Задание не распечатывается ## Симптом Задание появилось в очереди Printum, пользователь авторизовался на МФУ, но документ не вышел на печать. ## Диагностика ### Шаг 1. Проверить статус задания в CUPS 1. Откройте CUPS: `https://:1631` 2. Перейдите во вкладку **«Задания»** и найдите задание. 3. Если задание отсутствует — проблема на стороне клиента ПринтМенеджер (см. «Задание не появляется в очереди»). 4. Если статус отличается от «напечатано» (например, `Broken pipe`) — проблема в подключении CUPS к принтеру. ### Шаг 2. Проверить протокол подключения в CUPS 1. Перейдите во вкладку **«Принтеры»** в CUPS. 2. Сравните адрес и метод подключения устройства (ipp, ipps, socket). 3. Если метод отличается от поддерживаемого для вендора — измените протокол в карточке устройства в Printum (вкладка «Драйвер»). ### Шаг 3. Заменить драйвер в CUPS Если проблема не решена (медленная печать, некорректные символы, нечёткие изображения, не работает дуплекс): замените драйвер с Generic PostScript на родной драйвер модели или Generic PCL. ## Типовые ошибки | Ошибка | Причина | Решение | | :--- | :--- | :--- | | CUPS: Unable to send job to printer. | Неверный логин/пароль CUPS или отключён ALLOW_BYPASS_PRINTING | Проверьте настройки сервера печати. Включите ALLOW_BYPASS_PRINTING в настройках печати ПМ. | | CUPS: Unable to write print data: Broken pipe | Разрыв соединения с принтером | Проверьте сетевую доступность принтера. Измените протокол подключения. | ## Логи и диагностические данные ### Где смотреть логи - **printmanager-app** — Основной контейнер ПМ — обработка заданий, взаимодействие с принтерами - **printmanager-cups** — Сервер печати CUPS — обработка и отправка заданий на принтер - **printmanager-celery-print-queue** — Очередь бесклиентской печати — проверка CUPS на наличие новых заданий ### Что искать в логах - Выявить ошибки при отправке задания на принтер. - Определить причины возврата кодов 4xx/5xx. - Выявить ошибки работы сервиса CUPS и ошибки принтеров в CUPS. - Выявить ошибки соединения с принтерами. ### Что приложить к обращению в поддержку - Вывод команды `bash /opt/printmanager/logs.sh` - Версию: `cat /opt/printmanager/.version` - Описание сценария и шагов воспроизведения - ОС сервера ## Связанные страницы - [Задание не появляется в очереди печати](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadanie-ne-poiavliaetsia-v-oceredi-pecati) - [Управление драйверами и протоколами](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-draiverami-i-protokolami) # Медленная печать или долгая обработка документов # Симптом Большие документы долго обрабатываются системой, отправка задания на устройство занимает значительное время. ## Диагностика и решение ### Шаг 1. Включить PostScript-печать (для бесклиентской печати) Если проблема наблюдается при бесклиентской печати, попробуйте включить режим PostScript-печати. В панели администратора ПринтМенеджера **Системные настройки → Настройки печати** включите параметр **USE_PS_PRINTING**. Подробности настройки и ограничения режима описаны в статье [«Использование PostScript-печати»](https://docs.printum.io/books/5-upravlenie-sistemoi/page/ispolzovanie-postscript-pecati). ### Шаг 2. Проверить драйвер печати Если включение PostScript-печати не помогло, попробуйте заменить драйвер печати на стороне сервера. Вместо драйвера Generic PostScript Printer используйте: - родной драйвер производителя устройства; - драйвер для конкретной модели; - Generic PCL. # Связанные статьи - [Использование PostScript-печати](https://docs.printum.io/books/5-upravlenie-sistemoi/page/ispolzovanie-postscript-pecati) - [Форматы заданий печати](https://docs.printum.io/books/1-arxitektura-i-koncepcii/page/formaty-zadanii-pecati) - [Задание не распечатывается на принтере](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadanie-ne-raspecatyvaetsia-na-printere) - [Управление драйверами и протоколами](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-draiverami-i-protokolami) # Не печатаются схемы в PDF при отложенной печати ## Симптом PDF-документы со схемами или чертежами не печатаются или отображаются некорректно при отложенной печати без клиента ПМ. ## Решения ### Шаг 1. Попробовать другой браузер/приложение Если печать идёт из Chrome или Yandex Browser — попробуйте Firefox. Разные приложения по-разному растеризуют PDF. ### Шаг 2. Отключить пересылку PostScript в драйвере (Windows 10) 1. Пуск → Параметры → Устройства → Принтеры и сканеры. 2. Выберите принтер Printum → Управление → Настройки печати → вкладка **«Дополнительно»**. 3. Откройте **Драйвер** (+) → **Пересылка PostScript** → **Выключено** → ОК. **Предупреждение:** это может ухудшить качество печати других документов. ## Связанные страницы - [Медленная печать или долгая обработка документов](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/medlennaia-pecat-ili-dolgaia-obrabotka-dokumentov) - [Задание не распечатывается на принтере](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadanie-ne-raspecatyvaetsia-na-printere) # Проблемы с печатью из Office 2010 ## Симптомы Цветные документы, распечатанные из Microsoft Office 2010 через Клиент ПМ, выходят в чёрно-белом виде. --- ## Решение 1. Перейдите в папку с установленным Клиентом ПМ: ``` C:\Program Files\printum\printmanager_client ``` 2. Откройте файл `settings.yml`. 3. Измените следующие строки: ``` use_gs_conversion: true use_pdf_color_analysis: true ``` 4. Сохраните файл и перезапустите службу **Printum Optimize Service** (через компонент `services`). --- ## Что проверить перед эскалацией - Параметры `use_gs_conversion` и `use_pdf_color_analysis` установлены в `true`. - Служба Printum Optimize Service перезапущена. - Проверена печать цветного документа после изменений. # Проблемы с печатью из LibreOffice ## Симптомы При отправке задания печати из LibreOffice через Клиент ПМ в очереди печати появляется дополнительная копия задания (задание отправляется дважды). --- ## Решение 1. Откройте LibreOffice и перейдите в настройки (Alt+F12). 2. В разделе **«LibreOffice»** откройте подраздел **«Печать»**. 3. Включите галочку **«Задания печати в формате PDF»**. [![image232.png](https://wiki.printum.io/uploads/images/gallery/2026-05/scaled-1680-/image232.png)](https://wiki.printum.io/uploads/images/gallery/2026-05/image232.png) --- # Встала печать после обновления — Bad response from monitoring 500 # Симптомы - После обновления Мониторинга или ПринтМенеджера печать перестала работать на всех или части устройств. - В логах ПринтМенеджер или на почту администраторов приходят ошибки вида: ``` Bad response from monitoring 500 ``` - Синхронизация Мониторинг–ПринтМенеджер завершается с ошибкой. --- # Причина После обновления Мониторинга изменился адрес, порт или протокол синхронизации. ПринтМенеджер продолжает обращаться по старым параметрам — получает 500 вместо корректного ответа. --- # Диагностика Проверить логи ПринтМенеджер: ```bash cd /opt/printmanager sudo docker-compose logs printum_worker-high --tail=100 | grep -i "bad response\|monitoring" ``` Проверить доступность Мониторинга с сервера ПринтМенеджер: ```bash curl -k https://<адрес_М>:8001/api/health/ ``` Норма: ответ 200. Ошибка: connection refused, timeout, 500. --- # Решение **1. Проверить настройки синхронизации в Личном кабинете** Настройки → Интеграции → ПринтМенеджеры: убедиться, что адрес М и порт указаны корректно. **2. Проверить `.env` ПринтМенеджер** ```bash grep MONITORING_ADDRESS /opt/printmanager/.env ``` Адрес должен совпадать с актуальным адресом сервера Мониторинга. **3. Перезапустить ПринтМенеджер** ```bash cd /opt/printmanager sudo docker-compose down && sudo docker-compose up -d ``` **4. Запустить синхронизацию вручную** --- ## Как проверить результат - Синхронизация завершается без ошибок. - Задания уходят на МФУ. - Логи не содержат `Bad response from monitoring`. --- ## Связанные страницы - [Как обновить Printum](kak-obnovit-printum) - [Как работает синхронизация Мониторинга и ПринтМенеджера](kak-rabotaet-sinhronizaciya-monitoring-i-printmanager) # Пользователь авторизовался, но задания не отображаются ### Симптомы - Авторизация на МФУ прошла успешно. - Экран очереди пуст — нет ни одного задания. - Задания были отправлены с АРМ, но до МФУ не дошли. --- ### Решение **Шаг 1. Проверить, есть ли задание в очереди ПринтМенеджер** Панель администратора ПринтМенеджер → Администрирование → Очередь. Задание должно быть там.\ **Если задания нет** в ПринтМенеджер — проблема на стороне формирования задания или обработки задания в ПринтМенеджере. См. [Как диагностировать проблемы печати](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/kak-diagnostirovat-problemy-pecati-po-etapam).\ **Если задание есть** в ПринтМенеджер, но не отображается на МФУ — идём дальше. **Шаг 2. Проверить, кому принадлежит задание** Задание должно принадлежать тому же пользователю, под которым выполнена авторизация. Логин пользователя на АРМ и логин пользователя в Printum должны совпадать вплоть до регистра. Более подробно см. [Задание отправлено но не появилось на сервере](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadanie-otpravleno-no-ne-poiavilos-na-servere) **Шаг 3. Проверить синхронизацию Мониторинг–ПринтМенеджер** Настройки пользователя (в том числе привязка карты, PIN-код) передаются из Мониторинга в ПринтМенеджер при синхронизации. Если пользователь был добавлен или изменён недавно — синхронизация могла не выполниться. Запустить синхронизацию вручную. --- ### Связанные страницы - [Встроенное приложение — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/vstroennoe-prilozenie-diagnostika-problem) - [Как диагностировать проблемы печати по этапам пути задания](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/kak-diagnostirovat-problemy-pecati-po-etapam) # Проблемы авторизации # Пользователь не может авторизоваться на МФУ по карте ## Симптом Пользователь прикладывает карту к считывателю, но авторизация не происходит или появляется сообщение об ошибке. ## Диагностика ### Шаг 1. Проверить наличие карты в системе Перейдите в **Управление → Пользователи**, откройте карточку пользователя → вкладка **«Авторизация»**. Убедитесь, что карта привязана к учётной записи. ### Шаг 2. Проверить способы добавления карты - **Самостоятельная привязка на МФУ** (рекомендуется): встроенное приложение предложит привязку при первом прикладывании. Введите PIN-код и нажмите «Привязать». - **Импорт из домена**: убедитесь, что атрибут карты указан в настройках синхронизации с доменом. - **Ручной ввод**: администратор добавляет карту в карточке пользователя. - **Импорт из файла**: загрузка CSV/XLS через панель администратора Мониторинга → «Карты авторизации» → «Импорт». ### Шаг 3. Проверить картридер - Убедитесь, что тип картридера соответствует стандарту карты (MIFARE, HID, EM-Marine и др.). - Проверьте физическое подключение картридера к МФУ. - Протестируйте другую карту того же стандарта. ### Шаг 4. Проверить совместимость Возможны нюансы в сочетаниях «картридер ↔ модель принтера». Проверьте рекомендованный список картридеров (по запросу в поддержку Printum). ## Что проверить перед эскалацией - Карта привязана к пользователю в системе - Картридер физически работает - Тип карты поддерживается ## Связанные страницы - [Управление картами авторизации](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-kartami-avtorizacii) - [Пользователь не может авторизоваться на МФУ по PIN](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/polzovatel-ne-mozet-avtorizovatsia-na-mfu-po-pin) # Пользователь не может авторизоваться на МФУ по PIN ## Симптом Пользователь вводит PIN-код на экране МФУ, но авторизация не происходит или отображается ошибка. ## Диагностика ### Шаг 1. Убедиться, что PIN-код сгенерирован Перейдите в **Управление → Пользователи → Все**, откройте карточку пользователя → вкладка **«Авторизация»**. PIN-код должен быть сгенерирован и отправлен на e-mail пользователя. ### Шаг 2. Перегенерировать PIN-код 1. Убедитесь, что e-mail пользователя указан и почтовый сервер настроен. 2. В карточке пользователя (вкладка «Авторизация») нажмите **«Сгенерировать PIN-код»** 3. Попросите пользователя проверить почту и использовать новый PIN. ### Шаг 3. Проверить настройку SMTP Если PIN не доходит по почте — проверьте настройки SMTP (Настройки → Интеграции → Почта). Отправьте тестовое письмо. ### Шаг 4. Проверить встроенное приложение PIN-авторизация доступна только во встроенном приложении Printum на устройстве. Убедитесь, что встроенное приложение установлено и активировано (лицензия EMB). ## Важно Администратор не видит PIN-код в открытом виде — только инициирует генерацию. ## Связанные страницы - [Управление PIN-кодами](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-pin-kodami) - [Пользователь не может авторизоваться на МФУ по карте](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/polzovatel-ne-mozet-avtorizovatsia-na-mfu-po-karte) # Пользователь не может войти в Личный кабинет ## Симптом Пользователь не может войти в веб-интерфейс Printum (Личный кабинет) по логину/паролю или доменной учётной записи. ## Диагностика ### Шаг 1. Проверить тип авторизации - **Логин/пароль Printum**: убедитесь, что пользователь существует в системе и пароль задан. При необходимости — сбросьте пароль через «Восстановить пароль» на странице входа. - **Доменная УЗ / SSO**: убедитесь, что SSO настроен (SAML или Kerberos) и пользователь импортирован из домена. ### Шаг 2. Восстановить пароль 1. На странице авторизации нажмите **«Восстановить пароль»**. 2. Введите e-mail, привязанный к учётной записи, нажмите **«Отправить код»**. 3. Введите код из письма, задайте новый пароль. ### Шаг 3. Проверить почтовый сервер Если письмо не приходит — проверьте настройки SMTP (Настройки → Интеграции → Почта). ### Шаг 4. Проверить роль пользователя Убедитесь, что пользователю назначена роль с правом доступа к ЛК. Роль «Пользователь» имеет минимальный доступ. ## Связанные страницы - [Управление ролями пользователей](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-roliami-polzovatelei) - [Настройка SSO через Kerberos](http://wiki.printum.io/books/4-integracii/page/nastroika-sso-cerez-kerberos) # Авторизация по карте не работает во встроенном приложении ### Симптомы - Считыватель реагирует на карту (мигает, пищит), но авторизация в приложении не происходит. - После прикладывания карты — экран остаётся на стартовом, сессия закрывается или появляется ошибка. - Предложения привязать карту не появляется. --- ### Диагностика **Шаг 1. Убедиться, что считыватель виден МФУ** В зависимости от вендора МФУ: Войти в веб-интерфейс → раздел с USB-устройствами или внешними устройствами. Считыватель должен отображаться.\ Для ряда вендоров (Pantum, Ricoh) в веб-интерфейсе нужно вручную указать VID и PID считывателя. Проверить, что они заданы корректно.\ Для вендора Kyocera требуется приобрести лицензию Kyocera Card Authentication Kit. Проверить, что лицензия активна.\ Для вендора Konica Minolta есть ограничения на совместимость связки МФУ - Konica Minolta - EMB Printum. За уточнение обратитесь в техническую поддержку. **Шаг 2. Проверить тип карты и считывателя** Считыватель должен поддерживать тип карт заказчика (MIFARE, HID, EM-Marine и др.). Проверить совместимость: приложить карту к считывателю, подключённому к ПК — данные должны считываться. **Шаг 3. Проверить, привязана ли карта к пользователю** Личный кабинет → Управление → Пользователи → карточка пользователя → Авторизация → проверить поле "Карты авторизации". Если поле пустое — карта не привязана. Варианты привязки: - Самостоятельно на МФУ через PIN-код (рекомендуется). - Вручную администратором в карточке пользователя. - Импорт из домена или файла. Помимо существования номера карты в Личном кабинете, номер карты должен быть импортирован в ПринтМенеджер во время очередной синхронизации. Проверить:\ Панель администратора ПринтМенеджер → Управление печатью → Сотрудники → карточка пользователя → вкладка "Карты авторизации". Если номера карты нет и карты выгружались из домена/файла или привязывались вручную администратором, то провести синхронизацию между Мониторингом и ПринтМенеджером. --- ### Частые ситуации #### Считыватель не определяется МФУ Попробовать другой USB-порт МФУ. Перезагрузить МФУ с подключённым считывателем. Если считыватель по-прежнему не определяется — возможна несовместимость считывателя и МФУ. Рекомендуется тест с рекомендованными считывателями (список — у ТП). #### VID/PID указаны неверно (Pantum, Ricoh) VID и PID считывателя можно найти: - В документации к считывателю. - На ПК: Диспетчер устройств → считыватель → Свойства → Сведения → ИД оборудования. #### Карта считывается, но авторизация не происходит (Pantum) Сообщение «не введён PIN-код» вместо авторизации по карте означает, что приложение не получило серийный номер карты. Проверить: - Считыватель подключён к правильному порту МФУ. - VID/PID в веб-интерфейсе МФУ указаны верно. - В настройках МФУ включена авторизация по картам. #### После прикладывания карты сессия закрывается (Pantum) Это происходит, если пользователь уже авторизован — повторное прикладывание карты завершает сессию. Нормальное поведение. --- ### Как проверить результат Приложить карту к считывателю — пользователь авторизован, очередь заданий отображается. --- ### Когда эскалировать - VID/PID указаны верно, карта привязана, считыватель виден МФУ — авторизация не происходит. - Ни один считыватель из нескольких протестированных не работает с данной моделью МФУ. Приложить к заявке: вендор и модель МФУ, марка и модель считывателя, тип карт, версии Мониторинга и ПринтМенеджер, версия приложения, логи системы Printum. --- ### Связанные страницы - [Встроенное приложение — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/vstroennoe-prilozenie-diagnostika-problem) - [Как работает RFID-авторизация в Printum](https://wiki.printum.io/books/2-komponenty-sistemy/page/kak-rabotaet-rfid-avtorizaciia-v-printum) # Постоянный запрос токена на МФУ Ricoh ## Симптомы Встроенное приложение на МФУ Ricoh постоянно запрашивает получение токена. Авторизация пользователей не завершается. --- ## Возможная причина Проблема может быть вызвана сторонними приложениями, установленными на принтере, которые взаимодействуют с устройством и конфликтуют с системой Принтум. Например, это могут быть утилиты управления, такие как **Device Software Manager**. --- ## Решение 1. **Проверьте установленные приложения:** - Откройте интерфейс управления принтером. - Войдите в систему под логином и паролем администратора. - Перейдите в раздел, где перечислены все установленные приложения. 2. **Удалите сторонние приложения:** - Найдите приложения, не связанные с системой Принтум, но имеющие доступ к принтеру. - Удалите их. Особое внимание уделите утилитам, которые могут управлять настройками устройства. 3. **Перезагрузите принтер:** после внесённых изменений выполните перезагрузку устройства, чтобы убедиться в устранении проблемы. Если проблема сохраняется, обратитесь в службу поддержки с указанием модели устройства и подробным описанием возникшей ситуации. --- ## Логи и диагностические данные ### Где смотреть логи - **printmanager-app** — Основной контейнер ПМ — обработка запросов авторизации от встроенного приложения `cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app` - **printmanager-converter-server** — TCP-конвертер — приём запросов авторизации по TCP от устройства `cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-converter-server` ### Что искать в логах - Выявить, приходит ли сообщение от конвертера. - Выявить ошибки авторизации по TCP. - Выявить ошибки обработки API-запросов от встроенного приложения МФУ. ### Что приложить к обращению в поддержку - Вывод команды `bash /opt/printmanager/logs.sh` - Версию: `cat /opt/printmanager/.version` - Описание сценария и шагов воспроизведения - ОС сервера ## Что проверить перед эскалацией - Все сторонние приложения удалены. - Принтер перезагружен после удаления приложений. - В обращении указана модель устройства и подробное описание ситуации. # Документ сканируется, но не доставляется ## Симптомы - МФУ сообщает об успешном сканировании, но документ не приходит на почту и не появляется в папке. - В журнале заданий задание отображается, но статус «Ошибка». - Документ доходит с задержкой (более 5–10 минут). --- ## Возможные причины - Сетевая недоступность SMTP-сервера или SMB-хоста с сервера ПМ. - Документ превысил ограничения SMTP по размеру (не настроена обработка больших документов). - Задание застряло в очереди обработки ПринтМенеджер (проблема с контейнером). - Неверный e-mail или путь к папке в профиле пользователя. --- ## Диагностика 1. Найти задание в журнале: Управление → Задания → фильтр по пользователю и дате. 2. Проверить статус задания и наличие ошибки. 3. Проверить логи ПМ: `docker-compose logs --tail=300 | grep -i scan` 4. Проверить сетевую доступность SMTP и SMB с сервера ПМ: - SMTP: `telnet ` - SMB: попробовать монтирование папки вручную 5. Проверить настройку обработки больших документов: SCAN_LARGE_DOC_PROCESS_METHOD, SCAN_MAX_SIZE. --- ## Логи и диагностические данные ### Где смотреть логи - **printmanager-app** — Основной контейнер ПМ — обработка и доставка документа после сканирования `cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-app` - **printmanager-ftpd** — FTP-сервер — временное хранилище для обмена файлами сканирования и копирования `cd /opt/printmanager && docker-compose logs -f --tail=200 printmanager-ftpd` ### Что искать в логах - Выявить ошибки при выполнении процесса обработки образа документа задания сканирования и копирования. - Выявить ошибки доставки файла после сканирования. - Проверить, поступил ли образ документа в FTP-хранилище. ### Что приложить к обращению в поддержку - Вывод команды `bash /opt/printmanager/logs.sh` - Версию: `cat /opt/printmanager/.version` - Описание сценария и шагов воспроизведения - ОС сервера ## Решение 1. Убедиться в сетевой доступности SMTP/SMB с сервера ПМ. 2. Настроить обработку больших документов (SCAN_LARGE_DOC_PROCESS_METHOD): выбрать «Отправить ссылку», «Сетевую папку» или «Разделить». 3. Настроить максимальный размер в SCAN_MAX_SIZE на 20–25% меньше лимита почтового сервера. 4. Перезапустить контейнеры при застревании заданий: `cd /opt/printmanager && docker-compose restart` --- ## Что проверить перед эскалацией - Версию ПринтМенеджера - Логи контейнера printmanager-app (grep scan) - Сетевую доступность SMTP и SMB с сервера - Размер сканируемого документа и лимиты SMTP - Статус задания в журнале --- ## Связанные страницы - [Сканирование на email не работает](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/skanirovanie-na-email-ne-rabotaet) - [Сканирование в сетевую папку не работает](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/skanirovanie-v-setevuiu-papku-ne-rabotaet) - [Настройка отправки документов большого размера](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/nastroika-otpravki-dokumentov-bolsogo-razmera-s4g) # Проблемы обнаружения устройств # Принтер не обнаружен при сетевом сканировании ## Симптом Принтер включён и доступен в сети, но не появляется в Printum после сканирования локации. ## Диагностика ### Шаг 1. Проверить настройки локации Перейдите в **Управление → Устройства → Локации**. Убедитесь, что IP-адрес принтера входит в диапазон сканирования локации и не попадает в список исключений. ### Шаг 2. Проверить агент мониторинга Проверьте, что агент мониторинга опрашивает локацию с устройствами. Для этого перейдите во вкладку **Настройки > Интеграции > Сетевые агенты**. Локация с устройствами должна быть отмечена чек-боксом или входить в другую локацию, отмеченную чек-боксом. ### Шаг 3. Проверить сетевую доступность Для этого на ПК, находящемся в одной сети с принтером, откройте браузер и укажите в адресной строке ip-адрес принтера. Если принтер отвечает по указанному в настройках локации ip-адресу, проверьте, включена ли на принтере передача данных по протоколу SNMP. Если нет, необходимо включить. Проверьте, отвечают ли принтеры на запросы и отдают ли информацию по snmpwalk по командам: snmpwalk -v 2c -c public printer-ip-address или snmpwalk -v 1 -c public printer-ip-address Если принтеры не отвечают на команды, следует откорректировать настройки принтеров и включить передачу данных по протоколу SNMP. ### Шаг 4. Настройка SNMP параметров Если нужный ip-адрес указан в настройках локаций, принтер по нему отвечает и в настройках включена передача данных по протоколу SNMP, вероятно, потребуется настройка SNMP параметров для данной модели. Сделайте необходимые настройки или обратитесь в техническую поддержку. При обращении в техподдержку в запросе также укажите ошибки идентификации по этому устройству. Чтобы их посмотреть, перейдите в “Инвентаризация” > “Устройства”, найдите нужное устройство, вбив ip-адрес в строку поиска, скопируйте данные из столбца “Ошибки идентификации”. ## Связанные страницы - [Управление локациями](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-lokaciiami) - [Управление устройствами — обзор](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-ustroistvami-obzor) # Некорректно отображаются запчасти устройства ## Симптом На вкладке «Детали» в карточке устройства отображаются неверные данные о расходных материалах или запчастях (неверный процент, неверное название). ## Диагностика ### Шаг 1. Проверить тип показателя - Показатели из SNMP помечены иконкой принтера (столбец «Оставшийся ресурс»). - Расчётные показатели (по объёму печати) помечены иконкой базы. ### Шаг 2. Проверить OID-параметры устройства 1. Откройте карточку устройства → вкладка **«Параметры»**. 2. Нажмите кнопку **SNMP** для просмотра всех SNMP-данных устройства. 3. Сопоставьте OID значения с ожидаемыми параметрами и исправьте при необходимости. ### Шаг 3. Проверить характеристики модели Вкладка **«Характеристики»** — убедитесь, что тип устройства и параметры указаны корректно. ### Шаг 4.Проверка в справочниках Проверьте наличие запчастей в справочниках. Для этого откройте панель администратора мониторинга, далее “Инвентаризация” > “Запчасти”. Откроется список запчастей. В строку поиска введите модель принтера именно так, как она отображается в личном кабинете, нажмите “Найти”. Если данные по запчастям отсутствуют в справочнике, отправьте запрос в службу технической поддержки с указанием точной модели устройства. В запросе укажите модель принтера именно так, как она отображается в личном кабинете. Сотрудник технической поддержки направит вам обновленный справочник, который необходимо будет загрузить в панели администратора мониторинга. Если данные по запчастям есть в справочнике, но не отображаются в личном кабинете, это может быть вызвано тем, что наименование модели в справочнике не совпадает с тем, как модель принтера указывается в SNMP-данных, получаемых от устройства. Для устранения проблемы требуется настройка интерпретации SNMP-данных или корректировка справочников. Отправьте запрос в службу технической поддержки с точным наименованием модели (именно так, как она отображается в личном кабинете). ## Связанные страницы - [Управление устройствами — обзор](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-ustroistvami-obzor) - [Учёт расходных материалов](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/ucet-rasxodnyx-materialov) # Некорректный счётчик отпечатков ## Симптом Счётчик отпечатков в системе не совпадает с реальным показателем на принтере или не обновляется. ## Диагностика ### Шаг 1. Проверить синхронизацию SNMP-данных - Откройте карточку устройства → вкладка **«Параметры»** → нажмите **SNMP**. - Найдите корректный OID. - Во вкладке **«Параметры»** в строке счетчика укажите нужный OID. ### Шаг 2. Проверить лицензию мониторинга Сбор SNMP-данных требует активной лицензии типа **M**. Убедитесь, что лицензия назначена устройству (страница **Настройки > Общие > Организации**). ## Связанные страницы - [Некорректно отображаются запчасти устройства](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/nekorrektno-otobrazaiutsia-zapcasti-ustroistva) - [Управление лицензиями устройств](http://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-licenziiami-ustroistv) # Не все устройства отображаются в системе ## Симптомы - Часть принтеров и МФУ не появляется в отчёте по устройствам в Личном кабинете. - Устройства физически подключены к сети, включены и доступны, но система их не обнаруживает. --- ## Диагностика и решение ### 1. Проверьте настройки локаций Откройте Личный кабинет, раздел **«Управление» → «Устройства» → «Локации**». Откройте целевую локацию и убедитесь, что: - IP-адрес отсутствующих устройств указан в поле **«IP-адреса устройств»**. - IP-адрес отсутствующих устройств **не указан** в поле **«Исключить IP-адреса»**. ### 2. Проверьте назначение агента мониторинга В Личном кабинете перейдите во вкладку **«Настройки» → «Интеграции» → «Сетевой агент»**, нажмите кнопку **"Редактировать"**. Локация с целевыми устройствами должна быть отмечена чек-боксом или входить в другую локацию, отмеченную чек-боксом. ### 3. Проверьте доступность принтера в сети На ПК, находящемся в одной сети с принтером, откройте браузер и укажите в адресной строке IP-адрес принтера. При наличии сетевого доступа должна открыться страница с веб-панелью управления устройства. ### 4. Проверьте настройки SNMP на устройстве Если принтер отвечает по IP-адресу — проверьте, включена ли передача данных по протоколу SNMP. Выполните команду: ``` snmpwalk -v 2c -c public printer-ip-address ``` Если принтер не отвечает на команды — скорректируйте настройки и включите передачу данных по протоколу SNMP. ### 5. Проверьте ошибки идентификации Если нужный IP-адрес указан в настройках локаций, принтер отвечает и SNMP включён, вероятно, потребуется настройка SNMP-параметров для данной модели. При обращении в техподдержку укажите ошибки идентификации: перейдите в панель администратора Мониторинга, в раздел **«Инвентаризация» → «Устройства»**, найдите устройство по IP и скопируйте данные из столбца **«Ошибки идентификации»**. --- ## Массовая проверка через printer_scan.py Для проверки большого количества устройств используется консольное приложение `printer_scan.py`. Файл запросите у службы технической поддержки. Перед использованием установите библиотеки nmap и pandas. 1. Перенесите `printer_scan.py` на сервер в любое место. 2. Зайдите в Личный кабинет, в раздел **«Устройства»**. 3. Выберите необходимую локацию и нажмите кнопку **«Excel»**. 4. Полученный отчёт переименуйте в `Devices.xlsx` и перенесите на сервер. 5. Из папки с приложением введите команду: `sudo python3 printer_scan.py` 6. Приложение запросит IP-адреса — введите диапазоном или подсетью. 7. Программа выведет устройства в 4 группы: - **IPs that are up** — общий список откликнувшихся адресов. - **Checked as printers** — устройства, отмеченные как принтеры. - **Doubtful devices with no snmp** — устройства с выключенным SNMP. - **Not printers** — устройства, не являющиеся принтерами. 8. При запросе сравнения со списком из ЛК — введите `y` и укажите полный путь до файла `Devices.xlsx`. 9. Отчёты сохраняются в формате CSV: - `netscan_with_snmp.csv` — принтеры с включённым SNMP. - `netscan_without_snmp.csv` — принтеры с выключенным SNMP. - `not_found_in_monitoring.csv` — не найденные в мониторинге. --- ## Что проверить перед эскалацией - IP-адрес устройства входит в диапазон локации и не исключён. - Сетевой агент назначен на локацию с устройствами. - Устройство доступно по сети (браузер, ping). - SNMP включён на устройстве (`snmpwalk` возвращает данные). - В обращении в поддержку указаны: ошибки идентификации, модель устройства, IP. --- ## Связанные страницы - [Управление локациями](https://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-lokaciiami) - [Управление устройствами — обзор](https://wiki.printum.io/books/5-upravlenie-sistemoi/page/upravlenie-ustroistvami-obzor) # Некорректный список запчастей устройства ## Симптомы - Наименования деталей отображаются на английском языке. - Тип детали отображается как «Другое». - Отсутствует парт-номер. - Данные по оставшемуся ресурсу деталей не отображаются. --- ## Возможные причины - Данные по запчастям отсутствуют в справочнике. - Наименование модели в справочнике не совпадает с тем, как модель принтера указывается в SNMP-данных. --- ## Диагностика и решение ### Шаг 1. Проверьте наличие в справочнике Откройте панель администратора мониторинга, перейдите в **«Инвентаризация» → «Запчасти»**. В строку поиска введите модель принтера **именно так, как она отображается в личном кабинете**, нажмите «Найти». Если данные по запчастям отсутствуют — отправьте запрос в службу технической поддержки с указанием точной модели устройства (именно так, как она отображается в личном кабинете). Сотрудник направит обновлённый справочник, который необходимо загрузить в панели администратора (раздел «Загрузка справочников»). ### Шаг 2. Данные есть в справочнике, но не отображаются Причина: наименование модели в справочнике не совпадает с тем, как модель указывается в SNMP-данных, получаемых от устройства. Для устранения требуется настройка интерпретации SNMP-данных или корректировка справочников. Отправьте запрос в службу технической поддержки с точным наименованием модели (именно так, как она отображается в личном кабинете). ### Шаг 3. Некорректное отображение отдельных деталей Если часть деталей отображается корректно, а часть — на английском с типом «Другое»: - Определите деталь по значению в поле «парт-номер» или по наименованию (например, «Fuser»). - Если деталь с корректным русским наименованием уже есть в списке, но дублируется — настройте синонимы, как описано в разделе «Настройка синонимов», скопировав значение из поля «Наименование» в поле «Синонимы». - Если подходящей детали с корректным наименованием нет — отправьте запрос в службу технической поддержки с точным указанием модели, детали и содержанием столбца «Наименование» в личном кабинете. ### Шаг 4. Нет данных по оставшемуся ресурсу расходных материалов - Вероятнее всего, у принтера есть альтернативные запчасти и данные отображаются в строке другой детали. В этом случае следует объединить детали (раздел «Объединение деталей»). - Если альтернативные детали отсутствуют или корректно настроены, но данные всё равно не отображаются — настройте интерпретацию SNMP-данных для данной модели через раздел **«Конфигурация» → «Параметры запчастей»**. --- ## Что проверить перед эскалацией - Модель устройства в запросе указана точно так, как отображается в ЛК. - Проверены синонимы для дублирующихся деталей. - Проверено объединение деталей для альтернативных расходников. # Несколько расходных материалов одного цвета в списке запчастей ## Симптомы В списке запчастей одновременно отображаются несколько расходных материалов одного цвета, но разной ёмкости (например, два чёрных картриджа). --- ## Диагностика и решение ### Шаг 1. Определите установленный картридж Проверьте, есть ли у одной из деталей в столбце «Оставшийся ресурс» иконка «принтер». Если да — именно эта деталь установлена в принтере. Чтобы скрыть остальные — объедините детали, как описано в разделе «Объединение деталей». ### Шаг 2. Если иконки принтера нет ни у одной детали Проверьте, есть ли в списке запчасти с английским наименованием и типом «Другое». Если есть и по наименованию можно определить, что это один из расходных материалов (например, наименование может быть: `Black Toner HP CF256A`) — настройте синонимы для детали, как описано в разделе «Настройка синонимов». ### Шаг 3. Если предыдущие шаги не помогли Отправьте запрос в службу технической поддержки через раздел «Обращение в техническую поддержку». --- ## Что проверить перед эскалацией - Выполнены шаги 1 и 2. - В обращении указана модель устройства и содержимое столбца «Наименование» для каждой из дублирующихся деталей. # Статистика HP отображается некорректно ## Симптомы При использовании МФУ HP с драйвером **Xerox Global Print Driver PostScript** статистика печати в Личном кабинете не соответствует реальному количеству листов, страниц и применению дуплекса. --- ## Возможная причина При использовании драйвера **Xerox Global Print Driver PostScript** для МФУ HP статистика печати передаётся некорректно. Необходимо настроить подключение принтера по протоколу IPP. --- ## Решение 1. Войдите в Личный кабинет на страницу **«Управление → Устройства → Все»**. 2. Найдите нужный принтер в таблице и откройте карточку принтера. 3. Перейдите во вкладку **«Драйвер»**. 4. В поле **«Протокол»** выберите **«ipp»**. Нажмите кнопку **«Сохранить»**. 5. После синхронизации Мониторинга и ПринтМенеджера изменения вступят в силу. --- ## Что проверить перед эскалацией - Протокол изменён на **ipp** в карточке устройства. - Выполнена синхронизация Мониторинга и ПринтМенеджера. - Статистика проверена после следующего задания печати. # Локальные принтеры не отображаются в статистике ## Симптомы Локальные принтеры меняют своё название после печати документов. В статистике Мониторинга отображаются некорректные имена устройств. --- ## Возможная причина Проблема связана с неактуальными заданиями печати в спулере АРМ, на котором работает локальный агент мониторинга. --- ## Решение 1. Откройте командную строку с правами администратора и перейдите в директорию: ``` C:\Windows\System32\spool\PRINTERS ``` 2. Остановите службу диспетчера печати: ``` net stop spooler ``` 3. Удалите все файлы в директории: ``` del *.shd del *.spl ``` 4. Запустите службу диспетчера печати: ``` net start spooler ``` --- ## Что проверить перед эскалацией - Команды выполнены с правами администратора. - Служба диспетчера печати успешно перезапущена. - Имена принтеров стабилизировались после следующих заданий печати. # Сканирование — диагностика проблем ### Как работает сканирование в Printum МФУ сканирует документ → встроенное приложение передаёт файл на сервер ПринтМенеджер → ПринтМенеджер формирует статистику по заданияю → ПринтМенеджер отправляет файл на email или в сетевую папку пользователя. Из этого следует: если скан не дошёл — проблема либо в передаче файла с МФУ на ПринтМенеджер, либо в отправке с ПринтМенеджер на email/SMB. --- ### Предусловия для работы сканирования Перед диагностикой убедиться: **Для сканирования на email:** - Почтовый сервер настроен в ПринтМенеджер: панель администратора ПринтМенеджер → Настройки → SMTP. Тестовое письмо отправляется успешно. - У пользователя заполнен email в карточке. - Синхронизация Мониторинг–ПринтМенеджер выполнена. **Для сканирования в папку (SMB):** - Настроены `SMB_HOSTNAME`, `SMB_USERNAME`, `SMB_PASSWORD` в панели ПринтМенеджер → Настройки → Настройки сканирования. - У пользователя или отдела заполнен путь к сетевой папке. - Пользователь `SMB_USERNAME` имеет права на запись в папку. --- ### Алгоритм диагностики **Шаг 1. Проверить настройки ПринтМенеджер** Панель администратора ПринтМенеджера → `https://:8080/config/constance/config/` → раздел «Настройки сканирования». Для email: проверить SMTP-настройки, отправить тестовое письмо. Для SMB: проверить `SMB_HOSTNAME`, `SMB_USERNAME`, `SMB_PASSWORD`. **Шаг 2. Проверить карточку пользователя** Панель администратора Мониторинга → Пользователи → карточка пользователя: - Email заполнен и корректен. - Путь к сетевой папке, логин и пароль заполнен (для SMB). **Шаг 3. Проверить, не запрещено ли сканирование правилом** Личный кабинет → Управление → Пользователи → карточка пользователя → принтеры и правила. Правило «Запретить сканирование в почту» или «Запретить сканирование в папку» блокирует функцию. **Шаг 4. Проверить логи ПринтМенеджер** ```bash cd /opt/printmanager sudo docker-compose logs --tail=100 ``` **Шаг 5. Проверить, дошёл ли файл до ПринтМенеджер** В панели администратора ПринтМенеджер → Управление печатью → Задание печати: задание сканирования должно появиться после выполнения операции на МФУ. Если задания нет — файл не был передан с МФУ на ПринтМенеджер. Проверить сетевой доступ МФУ к серверу ПринтМенеджер и версию прошивки встроенного приложения. --- ### Навигация по конкретным проблемам | Симптом | Статья | |---|---| | Скан не приходит на email | [Скан не приходит на email](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/fail-skanirovaniia-ne-prixodit-na-email) | | Скан не сохраняется в сетевую папку | [Скан не сохраняется в сетевую папку](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/fail-skanirovaniia-ne-prixodit-v-setevuiu-papku) | | Большой файл не доходит по email | [Большой файл сканирования не доходит](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/bolsoi-fail-skanirovaniia-ne-doxodit-po-email) | | Konica Minolta / Kyocera: сканирование зависает при высоком DPI | [Konica Minolta / Kyocera — сканирование больших файлов](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/konica-minolta-kyocera-skanirovanie-zavisaet-pri-vysokom-dpi) | | Ricoh: скан не отправляется после таймаута сессии | [Ricoh — скан не отправляется после таймаута сессии](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/ricoh-skan-ne-otpravliaetsia-posle-taimauta-sessii) | --- ### Что приложить при эскалации в ТП - Вендор и модель МФУ, версия приложения. - Тип сканирования: email или SMB. - Версии Мониторинга и ПринтМенеджера. - Логи системы. - Описание: задание появляется в ПринтМенеджер или нет. # Konica Minolta / Kyocera — сканирование зависает при высоком DPI ### Симптомы На МФУ Konica Minolta или Kyocera при сканировании документов с высоким разрешением (DPI ≥ 600) или многостраничных документов: - Сканирование зависает или занимает очень долго. - Файл не доходит до ПринтМенеджер. - При малом DPI (150-300) сканирование работает нормально. --- ### Причина На некоторых моделях Konica Minolta и Kyocera при передаче больших файлов по умолчанию используется протокол, который плохо справляется с объёмными данными. Смена протокола передачи на WebDAV решает проблему. --- ### Решение **Для Konica Minolta:** Панель администратора ПринтМенеджер → `https://:8080/config/constance/config/` → раздел «Настройка приложения для принтеров KONICA MINOLTA» → переменная `KONICA_TRANSFER_PROTOCOL`. Изменить значение на `WebDAV` → сохранить. **Для Kyocera:** Панель администратора ПринтМенеджер → `https://:8080/config/constance/config/` → раздел «Настройка приложения для принтеров Kyocera» → переменная `KYOCERA_TRANSFER_PROTOCOL`. Изменить значение на `WebDAV` → сохранить. --- ### Как проверить результат Отсканировать документ с DPI 600 на Konica Minolta или Kyocera. Файл передаётся на ПринтМенеджер без зависания и доходит до email или папки пользователя. --- ### Когда эскалировать - Смена протокола на WebDAV не помогла. - Зависание происходит и при малом DPI. - Проблема только на одной конкретной модели. Приложить: вендор и модель МФУ, версия прошивки, значение `KONICA_TRANSFER_PROTOCOL`, DPI при котором воспроизводится, логи системы Printum. --- ### Связанные страницы - [Сканирование — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/skanirovanie-diagnostika-problem) - [Большой файл сканирования не доходит](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/bolsoi-fail-skanirovaniia-ne-doxodit-po-email) # Ricoh — приложение постоянно запрашивает токен ### Симптомы На МФУ Ricoh встроенное приложение Printum при каждом открытии запрашивает ввод токена, несмотря на то что токен уже был введён ранее и приложение работало. --- ### Причина Стороннее приложение, установленное на МФУ, конфликтует с приложением Printum и сбрасывает его настройки. Наиболее часто виновник — **Device Software Manager** или другие утилиты управления устройством от производителя или третьих сторон. --- ### Решение 1. Открыть веб-интерфейс МФУ Ricoh → войти под учётной записью администратора. 2. Перейти в раздел установленных приложений. 3. Найти и удалить все сторонние приложения, не связанные с Printum (особое внимание: Device Software Manager и аналогичные утилиты управления). 4. Перезагрузить МФУ. 5. Открыть приложение Printum — токен запрашиваться не должен. --- ### Как проверить результат Приложение открывается без запроса токена. Авторизация по карте или PIN-коду работает в штатном режиме. --- ### Когда эскалировать - Сторонних приложений нет, но токен запрашивается каждый раз. - После удаления стороннего ПО проблема сохраняется. Приложить к заявке: модель МФУ Ricoh, версия прошивки, версия приложения Printum, список установленных приложений на МФУ, логи системы Printum. --- ### Связанные страницы - [Встроенное приложение — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/vstroennoe-prilozenie-diagnostika-problem) # Ricoh — скан не отправляется после таймаута сессии ### Симптомы На МФУ Ricoh при сканировании документов объёмом 50+ страниц: - Сканирование занимает более 60 секунд. - По истечении таймаута сессия пользователя завершается автоматически. - После окончания сканирования письмо на email не приходит. - Задание сканирования в ПринтМенеджер не появляется. - При ручном продлении сессии или увеличении таймаута — скан доходит. --- ### Причина Приложение завершает обработку сканирования вместе с сессией пользователя. Если сканирование занимает больше времени, чем таймаут сессии МФУ (по умолчанию 60 секунд), документ теряется. --- ### Решение **Вариант 1. Увеличить таймаут сессии на МФУ** В веб-интерфейсе МФУ Ricoh → Настройки → таймаут сессии (Session Timeout / Auto Logout Timer). Установить значение выше времени сканирования документа (например, 180-300 секунд). Это самый простой и быстрый вариант. **Вариант 2. Уменьшить DPI или количество страниц за один сеанс** Снизить разрешение сканирования (например, с 600 до 300 DPI) или разбить большой документ на несколько меньших. **Вариант 3. Использовать сканирование в папку вместо email** Сканирование в SMB-папку часто работает надёжнее для больших документов, так как не зависит от ограничений почтового сервера и может потребовать меньше времени. --- ### Как проверить результат Отсканировать документ 50+ страниц при увеличенном таймауте. Задание появляется в ПринтМенеджер. Пользователь получает скан на email или в папку. --- ### Когда эскалировать - Таймаут увеличен, но скан по-прежнему не приходит. - Задания нет в ПринтМенеджер даже при коротких документах. Приложить: модель Ricoh, версия прошивки и приложения, текущее значение таймаута сессии, размер документа при котором воспроизводится, логи системы Printum. --- ### Связанные страницы - [Сканирование — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/skanirovanie-diagnostika-problem) - [Большой файл сканирования не доходит](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/bolsoi-fail-skanirovaniia-ne-doxodit-po-email) # Большой файл сканирования не доходит по email ### Симптомы - Сканирование небольших документов работает корректно. - При сканировании многостраничных документов или с высоким DPI (300+) письмо не приходит или приходит пустое. - Почтовый сервер отклоняет письмо из-за превышения размера вложения. --- ### Причина Почтовые серверы имеют ограничение на размер вложения (типично 10-25 МБ). Большие сканы превышают этот лимит и отклоняются SMTP-сервером. --- ### Решение Настроить способ обработки больших файлов в ПринтМенеджер: Панель администратора ПринтМенеджер → `https://:8080/config/constance/config/` → раздел «Настройки сканирования» → переменная `SCAN_LARGE_DOC_PROCESS_METHOD`. Доступные варианты: | Значение | Поведение | |---|---| | Отправить на email ссылку для скачивания | Файл хранится на сервере ПринтМенеджер, пользователю приходит временная ссылка (по умолчанию 2 часа - `DOC_LINK_LIFETIME`) | | Отправить в сетевую папку | Файл автоматически перенаправляется в SMB-папку пользователя | | Разделить по страницам | Документ разбивается на части, каждая часть — отдельное письмо | | Разделить на zip-файлы | Документ разбивается на zip-архивы заданного размера | **Настройка максимального размера** (для разбиения): Переменная `SCAN_MAX_SIZE` — максимальный размер одного сообщения в МБ. Рекомендуется устанавливать на 20-25% меньше лимита SMTP-сервера (например, если лимит 25 МБ — ставить 18-20 МБ). **Настройка срока действия ссылки** (для варианта со ссылкой): Переменная `DOC_LINK_LIFETIME` — срок в минутах (по умолчанию 120). --- ### Как проверить результат Отсканировать многостраничный документ (20+ страниц, 300 DPI). Пользователь получает письмо со ссылкой, несколькими частями или уведомлением о сохранении в папку — в зависимости от выбранного метода. --- ### Когда эскалировать - Метод настроен, но большие файлы по-прежнему не доходят. - Ссылка для скачивания не открывается или сразу истекает. Приложить: настройку `SCAN_LARGE_DOC_PROCESS_METHOD`, значение `SCAN_MAX_SIZE`, лимит SMTP-сервера, логи системы Printum. --- ### Связанные страницы - [Скан не приходит на email](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/fail-skanirovaniia-ne-prixodit-na-email) - [Сканирование — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/skanirovanie-diagnostika-problem) # Встроенное приложение не устанавливается ### Симптомы - Кнопка «Установить приложение» в Личном кабинете не переключается на «Удалить приложение» — установка не завершается. - При ручной установке через PEDK или интерфейс МФУ: ошибка `App installed failed, please try again later`. - Токен сгенерирован, но при вводе на МФУ приложение не появляется. --- ### Причины и решения #### МФУ недоступен с сервера ПринтМенеджер Автоматическая установка требует сетевого доступа от ПринтМенеджер к МФУ. Проверить: ```bash ping ``` Если МФУ недоступен — сетевая проблема на стороне заказчика. --- #### Лицензия EMB не активирована или слоты исчерпаны Проверить: Личный кабинет → Управление → Устройства → карточка устройства → вкладка «Лицензии». Лицензия EMB должна быть активна. Если слоты исчерпаны — освободить слот у другого устройства. > **Важно:** для EMB обязательно нужны активные лицензии M и PM на том же устройстве. --- #### Несовместимая версия прошивки МФУ Некоторые версии встроенного приложения имеют требования к версии прошивки МФУ. Несовместимая прошивка — одна из наиболее частых причин ошибки `App installed failed`. Проверить: запросить у Технической поддержки список совместимых прошивок для конкретной модели. Обновить прошивку МФУ при необходимости. > **Важно** Перепрошивку аппарата должен осуществлять обученный сервисный инженер. Для Pantum: прошивка TE13 совместима с текущей версией приложения (проверить актуальность в ТП). --- #### Для Pantum: ошибка при установке через PEDK Если используется PEDK-инсталлятор: 1. Убедиться, что версия PEDK актуальная (запросить у ТП). 2. Убедиться, что на МФУ нет ранее установленного приложения — удалить через веб-интерфейс МФУ. 3. Перезагрузить МФУ перед установкой. 4. Проверить правильность учётных данных администратора МФУ (логин/пароль). --- #### Токен просрочен или использован Если установка завершилась некорректно, а токен уже был введён на МФУ: 1. В Личном кабинете → «Удалить токен» или "Удалить приложение". 2. Сгенерировать новый токен или установить приложение. 3. Повторить установку (в случае если используется установка через usb-накопитель). --- ### Как проверить результат Личный кабинет → Управление → Устройства → карточка устройства: кнопка изменилась на «Удалить приложение». Приложение отображается на экране МФУ после перезагрузки. --- ### Когда эскалировать - Прошивка совместимая, лицензии есть, МФУ доступен — но установка не проходит. - Ошибка воспроизводится на всех устройствах одной модели. - Нет совместимой прошивки для модели МФУ. Приложить к заявке: вендор, модель, версия прошивки, версия приложения (если известна), версии Мониторинга и ПринтМенеджера, логи системы Printum. --- ### Связанные страницы - [Встроенное приложение — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/vstroennoe-prilozenie-diagnostika-problem) # Xerox — сканирование или копирование не работает, ошибок нет ### Симптомы На МФУ Xerox AltaLink при сканировании или копировании через встроенное приложение Printum операция не выполняется. Ошибок на экране нет или появляется ошибка `SenderPermissionDeniedClient … GetJobDetails`. --- ### Причина 1: Автоопределение формата не может определить размер оригинала Если выбран режим «Автоопределение» формата оригинала, но МФУ не может его определить (стекло пустое, нестандартный размер, АПД неисправен) — операция зависает без явной ошибки. **Диагностика:** во время сканирования на экране появляется таблица статусов. Если в конце `InputScanSizeNotDetermined` — причина в автоопределении. **Решение:** выбрать формат оригинала вручную (A4, A3 и т.д.) вместо «Автоопределение». --- ### Причина 2: Приложение «Работы» (Jobs) лишено прав Приложение Printum использует системное приложение «Работы» (Jobs) на Xerox AltaLink для получения информации о статусе сканирования. Если это приложение было ограничено в правах — сканирование не фиксируется. **Ошибка:** `SenderPermissionDeniedClient … GetJobDetails` **Решение:** восстановить права приложения «Работы» в веб-интерфейсе МФУ. Инструкция производителя: https://www.support.xerox.com/en-us/article/en/2121276 (доступ с VPN). Если ограничения не настраивались вручную — проверить настройку экрана блокировки (Lock Screen) в разделе настроек безопасности МФУ. Установить режим Custom и убедиться, что приложение «Работы» не заблокировано. --- ### Как проверить результат Запустить сканирование в тестовом режиме с явно указанным форматом A4. Документ сканируется и отправляется по назначению (email или папка). --- ### Когда эскалировать - Формат указан вручную, права приложения восстановлены — сканирование не работает. - Проблема только на одной модели Xerox при одинаковых настройках. Приложить к заявке: модель Xerox, версия прошивки, версия приложения, версии Мониторинга и ПринтМенеджера, логи системы Printum. --- ### Связанные страницы - [Встроенное приложение — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/vstroennoe-prilozenie-diagnostika-problem) # Ошибки при установке # После установки Printum пропало подключение к серверу ## Симптомы - После установки системы или первого запуска контейнеров пропадает связь с сервером: недоступен SSH, недоступен веб-интерфейс. - При запуске контейнеров в логе — ошибка: ``` ERROR: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network ``` ## Чаще всего Диапазон адресов внутренней сети Docker (`10.28.32.0/26`, используется по умолчанию) пересекается с адресным пространством инфраструктуры заказчика. Проявляется во время установки, сразу после неё или при первом запуске контейнеров — причина во всех случаях одна и та же. ## Диагностика Если SSH недоступен — подключитесь к серверу через консоль гипервизора (vSphere / Proxmox / Hyper-V и т.д.), без этого дальнейшие шаги не выполнить. Проверьте адреса, назначенные контейнерам: ``` sudo docker ps -q | sudo xargs -n 1 docker inspect -f '{{ .Name }}: {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' ``` Если адрес контейнера пересекается с локальной сетью сервера — причина подтверждена. ## Решение 1. Остановите контейнеры Printum (если проблема обнаружена после первого запуска; если конфликт известен заранее — пропустите этот шаг и шаг 5): Мониторинг: ``` cd /opt/printum docker-compose down ``` ПринтМенеджер: ``` cd /opt/printmanager docker-compose down ``` 2. Проверьте наличие файла `/etc/docker/daemon.json`. Если файла нет — создайте: ``` sudo nano /etc/docker/daemon.json ``` 3. Укажите новый пул IP-адресов Docker, не пересекающийся с локальной сетью (диапазон согласуйте с сетевым администратором): ``` { "default-address-pools": [ { "base": "x.x.x.x/x", "size": 26 } ] } ``` `size: 26` менять не требуется. 4. Перезапустите Docker: ``` sudo systemctl restart docker ``` 5. Запустите контейнеры Printum (те же команды, что в шаге 1, но `up -d` вместо `down`). Если при запуске контейнеров снова появляется ошибка `could not find an available, non-overlapping IPv4 address pool` — выбранный диапазон тоже пересекается с существующими сетями. Вернитесь к шагу 3 и укажите другой диапазон. ## Проверка результата Выполните команду из раздела «Диагностика» ещё раз: адреса контейнеров должны принадлежать новому пулу (не старому `10.28.32.0/26`). SSH-соединение с сервером устанавливается; веб-интерфейс Мониторинга/ПМ открывается в браузере. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: вывод `bash /opt/printum/logs.sh` (Мониторинг) или `bash /opt/printmanager/logs.sh` (ПринтМенеджер); - версию и ОС: `cat /opt/printum/.version` или `cat /opt/printmanager/.version`; - описание сценария: когда и на каком шаге пропала связь; - результаты диагностики: адреса контейнеров из команды `docker inspect` (раздел «Диагностика»). # Ошибка «сломаны пакеты» при установке ## Симптомы Установка Мониторинга или ПринтМенеджера останавливается с ошибкой: ``` E: Невозможно исправить ошибки: У вас зафиксированы сломанные пакеты. ``` ## Чаще всего Установка пакетов была прервана до завершения — например, сервер выключился или перезагрузился во время установки. ## Диагностика Симптом уже однозначно виден по тексту ошибки — дополнительная диагностика не требуется. ## Решение 1. Обратитесь к документации используемой ОС по восстановлению пакетного менеджера. 2. Если стандартное восстановление не помогает — удалите проблемные пакеты вручную и установите их заново. 3. Повторите установку Printum. ## Проверка результата Команда установки/обновления пакетов (`apt install` или её аналог в вашем дистрибутиве) отрабатывает без сообщения о сломанных пакетах; установка Printum проходит этот шаг без остановки. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: вывод команды, которой чинили пакеты, и её результат; - версию и дистрибутив ОС; - описание сценария: что происходило перед прерыванием установки (если известно); - результаты диагностики: полный текст ошибки пакетного менеджера. # Timeout при установке Мониторинга ## Симптомы Установка Мониторинга останавливается с ошибкой: ``` Timeout error. Check docker logs. Then restart the installation. ``` ## Чаще всего Неверно указана переменная `MON_HOSTNAME` при установке. ## Диагностика Проверьте значение `MON_HOSTNAME`, указанное при установке, и сверьте с фактическим IP-адресом/доменным именем сервера. ## Решение 1. Укажите верное значение `MON_HOSTNAME` (корректный IP-адрес или доменное имя сервера). 2. Запустите установку заново. ## Проверка результата Установка Мониторинга проходит этот шаг без таймаута; `docker ps` показывает контейнеры в статусе `Up`. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: вывод docker-логов установки; - версию системы и ОС; - описание сценария: какое значение `MON_HOSTNAME` было указано при установке; - результаты диагностики: сверку `MON_HOSTNAME` с фактическим адресом сервера. # Ошибка dpkg frontend lock при установке ПринтМенеджера ## Симптомы Установщик ПринтМенеджера останавливается с сообщением: ``` E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it. ``` ## Чаще всего Предыдущий процесс установки был прерван вручную (например, отменена команда), но сам процесс пакетного менеджера ещё не завершился и удерживает блокировку. ## Решение Дождитесь, пока активный процесс самостоятельно завершит работу — принудительно прерывать его не нужно, это может повредить состояние пакетного менеджера. После завершения процесса блокировка снимается автоматически, установку можно запустить заново. ## Проверка результата Повторный запуск установки ПринтМенеджера проходит этот шаг без ошибки о блокировке. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки установщика; - версию и дистрибутив ОС; - описание сценария: что предшествовало прерыванию установки. # Timeout Docker-демона при установке ПринтМенеджера ## Симптомы Установка ПринтМенеджера останавливается с одной из ошибок: ``` "msg": "An unexpected requests error occurred when docker-py tried to talk to the docker daemon: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)" ``` или ``` docker.errors.DockerException: Error while fetching server API version: UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60) ``` ## Чаще всего Docker-демон на сервере не отвечает вовремя на запрос — временная перегрузка или сбой самого Docker. ## Решение 1. Повторите установку. 2. Если ошибка повторяется — перезагрузите сервер целиком и запустите установку заново. ## Проверка результата `docker ps` отвечает сразу, без задержки; установка проходит этот шаг без сообщения о timeout. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки установщика; - версию ОС и версию Docker (`docker --version`); - описание сценария: сколько раз повторяли установку, перезагружали ли сервер. # Ошибка при установке ПМ с шифрованием ## Симптомы Установка ПринтМенеджера с включённым шифрованием завершается ошибкой. ## Чаще всего Не указана переменная `ENV_VAULT_PASSWORD`, необходимая при включённом шифровании. ## Диагностика Проверьте команду запуска установки — присутствует ли в ней `ENV_VAULT_PASSWORD`. ## Решение Запустите установку, явно указав пароль: ``` sudo ENV_VAULT_PASSWORD= -E ./install.sh ``` ## Проверка результата Установка ПринтМенеджера с шифрованием проходит без остановки; `docker ps` показывает контейнеры ПринтМенеджера в статусе `Up`. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки; - версию системы; - описание сценария: точную команду запуска установки (без самого пароля); - результаты диагностики: подтверждение того, что `ENV_VAULT_PASSWORD` был передан в команду. # Конфликт версий тома printmanager_media ## Симптомы При запуске ПринтМенеджера появляется ошибка: ``` ERROR: Configuration for volume media specifies "o" driver_opt addr=10.0.10.10,nolock,soft,rw,nfsvers=4, but a volume with the same name uses a different "o" driver_opt (addr=10.0.132.44,nolock,soft,rw). If you wish to use the new configuration, please remove the existing volume "printmanager_media" first ``` ## Возможные причины Адрес или параметры NFS-хранилища изменились (например, сменился адрес NFS-сервера), а старый Docker-том `printmanager_media` с прежними параметрами всё ещё существует. Docker не может использовать один и тот же volume с двумя разными конфигурациями подключения — старой (сохранённой в томе) и новой (указанной в `.env`). ## Диагностика Сравните параметры в тексте ошибки (старый и новый `driver_opt`) с текущим содержимым `.env` ПринтМенеджера — расхождение подтверждает причину. ## Решение Удалите устаревший том: ``` docker volume rm printmanager_media ``` Затем запустите ПринтМенеджер. ## Проверка результата `docker volume rm printmanager_media` выполняется без ошибок; при повторном запуске ПринтМенеджер создаёт новый том и переходит в статус `Up` (`docker ps`). ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки; - версию: текущее содержимое строки `DRIVER_OPTS_O` из `.env`; - описание сценария: историю изменений адреса NFS-хранилища (если известна); - результаты диагностики: сравнение старого и нового `driver_opt` из текста ошибки. # Ошибка монтирования NFS-хранилища ПринтМенеджера ## Симптомы При установке или запуске ПринтМенеджера в конфигурации Кластер Active-Active появляется ошибка: ``` Error response from daemon: error while mounting volume '/var/lib/docker/volumes/printmanager_media/_data': failed to mount local volume: mount :scratch:/var/lib/docker/volumes/printmanager_media/_data, data: addr=10.10.10.10,nolock,soft: permission denied ``` ## Чаще всего Несовпадение версии протокола NFS между ПринтМенеджером и сервером NFS. ## Возможные причины В порядке убывания вероятности: 1. Версия протокола NFS не указана явно и не совпадает с той, что использует NFS-сервер. 2. NFS-сервер настроен неверно или недоступен по сети с сервера ПринтМенеджера. 3. Права на монтирование директории на стороне NFS-сервера не позволяют смонтировать её с этого узла. ## Диагностика 1. Проверьте возможность монтирования вручную с сервера ПринтМенеджера. 2. Проверьте, что NFS-сервер настроен верно и доступен по сети. 3. Если сеть и доступность в порядке — вероятная причина в версии протокола. ## Решение Явно укажите версию протокола NFS в `.env` ПринтМенеджера. Откройте файл и найдите строку: ``` DRIVER_OPTS_O="addr=NFS_ADDR,nolock,soft,rw" ``` Добавьте `nfsvers`: ``` DRIVER_OPTS_O="addr=NFS_ADDR,nolock,soft,rw,nfsvers=4" ``` Допустимые значения `nfsvers`: `3`, `4`, `4.2`. Запустите ПринтМенеджер заново. ## Проверка результата ПринтМенеджер запускается без ошибки монтирования; контейнеры в статусе `Up` (`docker ps`), том `printmanager_media` примонтирован. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки; - версию: NFS-сервера и его конфигурацию; - описание сценария: содержимое строки `DRIVER_OPTS_O` из `.env` (без учётных данных, если есть). # ПринтМенеджер не подключается к Мониторингу после установки ## Симптомы После установки ПринтМенеджер не устанавливает соединение с сервером Мониторинга: интеграция не работает, синхронизация не запускается. ## Чаще всего Адрес Мониторинга указан неверно либо недоступен по сети. ## Возможные причины В порядке убывания вероятности: 1. Адрес Мониторинга, указанный при установке ПринтМенеджера, недоступен с сервера ПринтМенеджера. 2. Порты 8000 и 8001 закрыты firewall'ом на одном из серверов. 3. Сертификат сервера Мониторинга не актуален. ## Диагностика Проверяйте по порядку: 1. Адрес Мониторинга доступен с сервера ПринтМенеджера. 2. Порты 8000 и 8001 открыты в firewall на обоих серверах. 3. Сертификат сервера Мониторинга не просрочен. ## Решение - Адрес неверный или недоступен — укажите верный адрес Мониторинга в настройках ПМ и перезапустите синхронизацию. - Порты закрыты — откройте 8000 и 8001 в firewall на обоих серверах. - Сертификат не актуален — обновите сертификат на сервере Мониторинга. ## Проверка результата Синхронизация запускается без ошибок; ПМ появляется в списке ПМ в личном кабинете Мониторинга со статусом «активен». ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: `bash /opt/printmanager/logs.sh`; - версию: Мониторинга и ПМ; - описание сценария: адрес Мониторинга, указанный на ПМ; - результаты диагностики: что показали проверки из раздела «Диагностика». ## Связанные страницы - [Требования к сетевой доступности и портам](https://docs.printum.io/books/8-spravocnik/page/trebovaniia-k-setevoi-dostupnosti-i-portam) - [Требования к сертификатам безопасности](https://docs.printum.io/books/8-spravocnik/page/trebovaniia-k-sertifikatam-bezopasnosti) # Повреждена RPMDB при установке (РедОС) ## Симптомы При установке на РедОС (RED OS) появляется ошибка вида «проверка транзакции на разрешение зависимостей», «Вероятно у вас повреждена RPMDB». ## Чаще всего Локальная база данных RPM-пакетов повреждена или рассинхронизирована с системными компонентами. ## Решение Выполните обновление системных компонентов: ``` sudo yum update -y sudo yum install rpm ``` Повторите установку. ## Проверка результата `sudo yum update -y` отрабатывает без ошибок; установка проходит этот шаг без сообщения о повреждении RPMDB. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки; - версию РедОС (`cat /etc/os-release`); - результаты диагностики: вывод `sudo yum update -y`. # Ошибка "rpm.error: package not installed" при установке ## Симптомы При установке появляется ошибка: ``` _rpm.error: package not installed ``` ## Чаще всего Пакет, который установщик ожидает найти в системе, отсутствует или не зарегистрирован в RPM корректно. ## Решение Выполните: ``` dnf update ``` Повторите установку. ## Проверка результата `dnf update` отрабатывает без ошибок; установка проходит этот шаг без сообщения `package not installed`. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки (включая название пакета, если оно есть в выводе); - версию РедОС; - вывод `dnf update`. # Ошибка "AttributeError X509_V_FLAG_NOTIFY_POLICY" при установке на РедОС ## Симптомы При установке на РедОС появляется ошибка: ``` AttributeError: module 'lib' has no attribute 'X509_V_FLAG_NOTIFY_POLICY' ``` ## Чаще всего На сервере установлена несовместимая версия пакета `python3-pyOpenSSL`. ## Решение Выполните обновление системных компонентов: ``` dnf update ``` Повторите установку. ## Проверка результата Установка проходит этот шаг без AttributeError. ## Если проблема сохраняется Соберите перед обращением в поддержку: - логи: полный текст ошибки; - версию `python3-pyOpenSSL` (`rpm -q python3-pyOpenSSL`); - версию РедОС (`cat /etc/os-release`). # Ошибка сертификата драйвера при установке Клиента ПМ на Windows ## Симптомы При установке Клиента ПМ на Windows появляется системное предупреждение о недоверии к сертификату драйвера. ## Чаще всего В хранилище сертификатов Windows отсутствует полная цепочка сертификатов «ООО Принтум». ## Возможные причины В порядке убывания вероятности: 1. Сертификат «ООО Принтум» отсутствует в разделе «Доверенные издатели». 2. Цепочка сертификатов неполная — отсутствует промежуточный или корневой сертификат. ## Диагностика 1. Откройте оснастку `certlm.msc`, проверьте раздел «Доверенные издатели» — там должен быть сертификат «ООО Принтум»: [![image348.png](https://wiki.printum.io/uploads/images/gallery/2026-05/scaled-1680-/image348.png)](https://wiki.printum.io/uploads/images/gallery/2026-05/image348.png) 2. Правой кнопкой мыши на сертификате → Открыть → вкладка «Путь сертификации» — сертификаты с ошибкой цепочки помечаются жёлтым или красным цветом: [![image41.png](https://wiki.printum.io/uploads/images/gallery/2026-05/scaled-1680-/dTlimage41.png)](https://wiki.printum.io/uploads/images/gallery/2026-05/dTlimage41.png) ## Решение Установите сертификаты с ошибкой в соответствующие разделы: 1. **GlobalSign GCC R45 EV CodeSigning CA 2020** — в «Промежуточные центры сертификации». 2. **GlobalSign Code Signing Root R45** — в «Доверенные корневые центры сертификации». Если цепочка не состоит из 3 ступеней — установите оба сертификата вручную, как описано выше. ## Проверка результата Путь сертификации отображается без ошибок (все элементы цепочки — зелёные); установка Клиента ПМ проходит без предупреждения. ## Если проблема сохраняется Соберите: - скриншот вкладки «Путь сертификации»; - версию Windows; - версию устанавливаемого Клиента ПМ. # Клиент ПМ перестал работать после обновления Astra Linux ## Симптомы - Клиент ПМ работал корректно до обновления ОС. - После обновления Astra Linux (например, 1.7.7 → 1.7.9) задания перестали попадать в очередь ПринтМенеджера. - CUPS принимает задания (`Job completed`), очередь ПринтМенеджера пустая. - Служба клиента ПМ запущена. - Переустановка клиента ПМ без смены дистрибутива не помогла. В логах одна или несколько ошибок: ``` BrokenPipeError: [Errno 32] Broken pipe ``` ``` ipplib.IppTransportException: Error: 401 ``` --- ## Причина После обновления ОС изменились системные библиотеки Python или IPP-стек, с которыми взаимодействует клиент ПМ. Текущая версия дистрибутива клиента несовместима с новой версией ОС. Переустановка того же дистрибутива проблему не решает — нужна актуальная версия клиента, совместимая с обновлённой ОС. --- ## Диагностика **Шаг 1.** Убедиться, что проблема появилась именно после обновления ОС: ```bash cat /etc/os-release # Зафиксировать версию Astra Linux journalctl --since "дата обновления ОС" -u printum-printmanager-client.service | grep -i "error\|broken\|failed" ``` **Шаг 2.** Проверить, воспроизводится ли проблема на другом АРМ с той же версией ОС: Если да — проблема системная, связана с версией ОС. --- ## Решение **1. Запросить актуальный дистрибутив клиента ПМ в ТП**, указав версию ОС (`cat /etc/os-release`). **2. Переустановить клиент ПМ с новым дистрибутивом:** ```bash sudo systemctl stop printum-printmanager-client.service ``` Установить новую версию клиента ПМ по инструкции: [Клиент ПМ на Linux — установка и проверка](https://wiki.printum.io/books/3-ustanovka/page/klient-pm-na-linux-ustanovka-i-proverka) ```bash sudo systemctl status printum-printmanager-client.service ``` **3. Проверить передачу заданий:** ```bash sudo journalctl -u printum-printmanager-client.service --since "5 minutes ago" ``` Отправить тестовое задание — оно должно появиться в очереди ПринтМенеджера. --- ## Как проверить результат - В логах нет ошибок `BrokenPipeError` и `Error: 401`. - Тестовое задание появилось в очереди ПринтМенеджера и на МФУ. --- ## Когда эскалировать - Обновлённый дистрибутив клиента ПМ не помог. - Проблема воспроизводится не на всех АРМах после одинакового обновления ОС. - На тестовом АРМ с той же версией ОС проблема не воспроизводится — нужна более глубокая диагностика конкретного АРМ. Приложить к заявке: версию ОС до и после обновления, версию клиента ПМ, логи `journalctl` с ошибкой, результат `systemctl status`. --- ## Связанные страницы - [Клиент ПМ на Linux — установка и проверка](https://wiki.printum.io/books/3-ustanovka/page/klient-pm-na-linux-ustanovka-i-proverka) - [BrokenPipeError — задания не передаются из CUPS в ПринтМенеджер](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/brokenpipeerror-zadaniia-ne-peredaiutsia-iz-cups-v-pm-linux) - [Error 401 — пользователь не найден в ПМ](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/error-401-polzovatel-ne-naiden-v-pm-klient-pm-linux) # Сбой активации лицензии после простоя системы ### Симптомы После длительного простоя системы (месяц и более) при входе в ЛК отображается сообщение о сбое активации. Ранее лицензия не была активирована. При попытке повторно ввести лицензионный ключ — ошибка. --- ### Причина При длительном простое ключ лицензии, привязанный к системе, может быть аннулирован или устареть. Старый ключ лицензии, выданный технической поддержкой, больше не валиден — нужен новый ключ под актуальный токен. --- ### Решение **Шаг 1.** Обратится в sales@printum.io за перевыпуском ключа лицензии для продления активации. **Шаг 2.** Полученный новый ключ лицензии актививароть в Личный кабинет → Настройки → Общие → Организации. Нажать кнопку **«Токен активации»** и Скопировать актуальный токен. > **Примечание** Если Личный кабнет недоступен, что активировать лицензию через страницу первого запуска `https:///welcome` **Шаг 3.** Отправить токен в ТП (support@printum.io) вместе с названием и идентификатором организации. **Шаг 4.** Полученный новый ключ ввести в поле **«Указать лицензионный ключ»** → «Сохранить». --- ### Как проверить результат ЛК открывается без ошибки активации. В карточке организации отображаются типы лицензий и срок действия. --- ### Когда эскалировать - ЛК полностью недоступен, нет возможности получить токен. - Новый ключ получен, но ошибка активации сохраняется. --- ### Связанные страницы - [Как активировать или продлить лицензию](https://wiki.printum.io/books/5-upravlenie-sistemoi/page/kak-aktivirovat-ili-prodlit-licenziiu) - [Ошибка «Provided license key instead of activation key»](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/osibka-provided-license-key-instead-of-activation-key) # Проблемы кластера и балансировщика # Задания не распечатываются в отказоустойчивой конфигурации ## Симптом В конфигурации с балансировщиком HAProxy пользователи авторизуются, но задания не выходят на печать. ## Диагностика ### Шаг 1. Проверить панель HAProxy Откройте панель администратора HAProxy. Проверьте, что все секции зелёные: - `ftp` - `cups_1631` - `tcp_converter_7776` / `tcp_converter_7777` - `admin_8010` / `admin_8080` Красная строка сервера = сервер установлен некорректно или недоступен. ### Шаг 2. Проверить флаг use_cups_ssl в клиенте ПМ Ошибка `http.client.RemoteDisconnected: Remote end closed connection without response` означает неверный флаг SSL. 1. Перейдите в директорию клиента ПМ: `C:\Program Files\printum\printmanager_client\` 2. Откройте файл `settings.yml` с правами администратора. 3. Установите: `use_cups_ssl: true` ### Шаг 3. Проверить NFS-хранилище Убедитесь, что NFS-хранилище доступно. Недоступность NFS приводит к потере файлов заданий. ### Шаг 4. Проверить синхронизацию ПринтМенеджер с Мониторингом Запустите ручную синхронизацию в личном кабинете: **Настройки → Интеграции → ПМ**. ## Связанные страницы - [Файл недоступен при отложенной печати в кластере](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/fail-nedostupen-pri-otlozennoi-pecati-v-klastere) - [Обновление в отказоустойчивой конфигурации](http://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/obnovlenie-v-otkazoustoicivoi-konfiguracii) # Файл недоступен при отложенной печати в кластере ## Симптом Пользователь авторизовался на МФУ, но задание недоступно или файл документа отсутствует в очереди. ## Причина Файлы заданий в кластерной конфигурации хранятся на NFS-хранилище. Если NFS недоступен или неправильно смонтирован на одном из серверов ПринтМенеджер — файлы заданий не видны этому серверу. ## Диагностика ### Шаг 1. Проверить монтирование NFS ``` # На каждом сервере ПМ: df -h | grep nfs mount | grep nfs ``` ### Шаг 2. Проверить права доступа к папке NFS ``` ls -la /scratch # Ожидаемые права: 777, владелец nobody ``` ### Шаг 3. Проверить сетевую доступность NFS-сервера ``` ping # Проверка экспортов NFS: showmount -e ``` ### Шаг 4. Перемонтировать NFS при необходимости ``` sudo umount /scratch sudo mount : /scratch ``` ## Связанные страницы - [Задания не распечатываются в отказоустойчивой конфигурации](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadaniia-ne-raspecatyvaiutsia-v-otkazoustoicivoi-konfiguracii) # Как диагностировать проблемы NFS и DNS ### Назначение DNS и NFS являются критически важными инфраструктурными зависимостями системы Printum. Проблемы с DNS или NFS могут вызывать: - restart loop контейнеров; - недоступность ПринтМенеджера; - ошибки синхронизации; - недоступность очередей печати; - проблемы работы встроенных приложений; - ошибки авторизации пользователей; - недоступность архива заданий. --- ### Типовые признаки проблем DNS | Симптом | Возможная причина | |---|---| | Контейнеры постоянно перезапускаются | hostname не резолвится, nfs-сервер недоступен | | Ошибки timeout | DNS-сервер недоступен | | Ошибки синхронизации | неверное DNS-имя | | SSL/TLS errors | hostname не соответствует сертификату | | ПринтМенеджер недоступен | отсутствует DNS-resolve между узлами, nfs-сервер недоступен | --- ## Диагностика DNS ### Проверка resolv.conf Проверить содержимое файла: ```bash cat /etc/resolv.conf ``` Необходимо убедиться: - DNS-серверы указаны корректно; - DNS-серверы доступны; - отсутствуют ошибочные записи; - указан корректный search domain (если используется). --- ### Проверка разрешения hostname Проверить разрешение hostname: ```bash ping monitoring.local ``` Дополнительно рекомендуется выполнить: ```bash nslookup monitoring.local ``` Проверить: - hostname успешно резолвится; - IP-адрес соответствует ожидаемому; - отсутствуют timeout; - ответ приходит от корректного DNS-сервера. --- ### Проверка сетевой связности Проверить доступность серверов: ```bash ping printmanager.local ``` При использовании отказоустойчивой конфигурации необходимо проверить связность между: - Мониторингом; - всеми узлами ПринтМенеджера; - NFS-сервером; - балансировщиком; - PostgreSQL; - Redis/Sentinel. --- ## Диагностика NFS ### Проверка доступности NFS-портов Проверить доступность NFS: ```bash telnet nfs-server.local 2049 ``` Если используется stunnel: ```bash telnet nfs-server.local 20490 ``` Ожидаемый результат: - TCP-соединение успешно устанавливается; - отсутствуют timeout; - отсутствует ошибка `Connection refused`. --- ### Проверка mounted volumes #### Проверка NFS volume в Docker Проверить список Docker volumes: ```bash docker volume ls ``` Найти volume, который используется ПринтМенеджером (printmanager-app). Проверить параметры volume: ```bash docker volume inspect ``` Проверить: - volume существует; - указан корректный NFS server; - указан корректный путь NFS export; - параметры подключения соответствуют конфигурации. --- #### Проверка mount внутри контейнера Зайти в контейнер ПринтМенеджера: ```bash docker exec -it printmanager-app sh ``` Проверить подключённые файловые системы внутри контейнера: ```bash df -h ``` Дополнительно проверить доступность каталога: ```bash ls -la ``` Проверить: - каталог доступен из контейнера; - отсутствуют ошибки `Stale file handle`; - файловая система не находится в режиме `read-only`; - файлы создаются и читаются корректно. --- ### Проверка сервисов NFS На NFS-сервере проверить состояние сервисов: ```bash systemctl status nfs-server.service ``` Если используется stunnel: ```bash systemctl status stunnel.service ``` Проверить: - сервисы находятся в состоянии `active (running)`; - отсутствуют restart loop; - отсутствуют ошибки systemd. --- ### Перезапуск сервисов NFS При необходимости выполнить перезапуск: ```bash systemctl restart nfs-server.service ``` Если используется stunnel: ```bash systemctl restart stunnel.service ``` После перезапуска рекомендуется повторно проверить: - доступность портов; - состояние mount; - доступность каталогов; - состояние контейнеров Printum. --- ### Что делать при restart loop контейнеров Если контейнеры Printum постоянно перезапускаются, необходимо последовательно проверить: - DNS; - NFS; - сетевую связность; - mounted volumes; - доступность PostgreSQL; - доступность Redis; - корректность hostname; - срок действия SSL-сертификатов. После устранения проблемы выполнить перезапуск контейнеров: ```bash cd /opt/printmanager docker-compose down && docker-compose up -d ``` --- ### Дополнительная диагностика Docker Проверить состояние контейнеров: ```bash docker ps -a ``` Просмотреть логи контейнера: ```bash cd /opt/printmanager/ docker-compose logs -f --tail=5 ``` --- ### Важно помнить - DNS является одной из самых частых причин инфраструктурных отказов. - NFS критически важен для работы отказоустойчивой конфигурации ПринтМенеджера. - Большинство restart loop связано с инфраструктурными зависимостями. - Проверка DNS и NFS должна быть первым этапом диагностики. - В Active-Active конфигурации стабильная работа DNS и NFS обязательна для всех узлов кластера. ### Связанные страницы * [Установка NFS-хранилища](https://wiki.printum.io/books/3-ustanovka/page/ustanovka-nfs-xranilishha) * [Проверка корректности установки кластера](https://wiki.printum.io/books/3-ustanovka/page/proverka-korrektnosti-ustanovki-klastera) # MissingSchema — неверные адрес или токен ПМ (клиент ПМ Linux) ### Симптомы Виртуальный принтер Printum не появляется на АРМ после установки клиента ПМ. \ В логах Пр: ``` requests.exceptions.MissingSchema: Invalid URL '/direct_printers/': No schema supplied. Perhaps you meant http:///direct_printers/? ``` --- ### Причина При установке клиента ПМ переменные адреса ПринтМенеджер или `access_token` указаны неверно — без схемы (`https://`), с опечаткой или пустым значением. --- ### Диагностика Проверить текущие значения в конфигурационном файле: ```bash cat /opt/printum/printmanager_client/settings.yml ``` Проверить: - `server_url` содержит полный адрес с протоколом: `https://:8080` или `http://:8010` - `access_token` не пустой и совпадает с ключом доступа в Личном кабинете → Настройки → Интеграции → ПМ --- ### Решение Переустановить клиент ПМ с корректными параметрами согласно по инструкции из разделов [Удаление клиента ПМ на Linux](https://wiki.printum.io/books/3-ustanovka/page/udalenie-klienta-pm-na-linux) **и** [Клиент ПМ на Linux — установка и проверка](http://wiki.printum.io/books/3-ustanovka/page/klient-pm-na-linux-ustanovka-i-proverka) При установке обязательно указать: - полный адрес ПринтМенеджер с протоколом и портом: `https://<адрес_пм>:8080` или `http://:8010` - актуальный `access_token` из Личного кабинета → Настройки → Интеграции → ПМ После установки проверить: ```bash sudo systemctl status printum-printmanager-client.service sudo tail /var/log/printum/printmanager-client.log -f ``` --- ### Как проверить результат Виртуальный принтер Printum появился на АРМ. В логах нет `MissingSchema`. Тестовое задание появляется в очереди ПринтМенеджер. --- ### Когда эскалировать - Параметры указаны корректно, но ошибка сохраняется. - Клиент ПМ не запускается после переустановки. --- ### Связанные страницы - [Клиент ПМ на Linux — установка и проверка](http://wiki.printum.io/books/3-ustanovka/page/klient-pm-na-linux-ustanovka-i-proverka) # Проблемы Клиента ПМ # Принтеры не появляются на рабочей станции ## Симптом После установки клиента ПринтМенеджер принтер Printum не появился в списке принтеров на АРМ пользователя. ## Диагностика ### Шаг 1. Проверить статус службы **Windows:** Win+R → `eventvwr` → Журналы Windows → Приложение → источник _ПринтМенеджер Client_. **Linux:** ``` sudo systemctl status printum-printmanager-client.service ``` ### Шаг 2. Проверить типовые ошибки в логах | Ошибка | Решение | | --- | --- | | No user {'login'} is authorized, removing all printers | Пользователь не существует в Printum или неверный SID. Проверьте учётную запись. | | Max retries exceeded | АРМ не достигает сервер ПМ. Проверьте сетевую доступность и порты. | | AssertionError: Adding printer Printum means critical error | Принтер Printum не найден или неверный драйвер. Удалите принтер вручную и переустановите клиент. | ### Шаг 3. Проверить драйвер принтера Printum В списке принтеров Windows: принтер должен называться **Printum** и использовать драйвер **Printum XPS**. ### Шаг 4. Windows 7: ошибка «ОС Windows не удается подключиться к принтеру» Включите компонент **«Клиент интернет-печати»**: Панель управления → Программы → Включение компонентов Windows → Службы печати документов → Клиент интернет-печати. Перезагрузите компьютер. ## Логи и диагностические данные ### Где смотреть логи - **Клиент ПМ Windows** — Отправка заданий на печать на ОС Windows Откройте `eventvwr` → Журналы Windows → Приложение → источник _Print Manager Client_ - **Клиент ПМ Linux** — Отправка заданий на печать на ОС Linux sudo journalctl -u printum-printmanager-client.service - **printmanager-app** — Основной контейнер ПМ — формирование списка принтеров для клиентов sudo docker logs printmanager-app ### Что искать в логах - Выявить ошибки запуска сервиса клиента ПМ. - Выявить ошибки передачи данных (список принтеров). - Определить причины возврата кодов 4xx/5xx при запросе списка принтеров. ### Что приложить к обращению в поддержку - Логи клиента ПМ: Windows — Просмотр событий (`eventvwr`) → Журналы Windows → Приложение → источник _Print Manager Client_; Linux — `sudo journalctl -u printum-printmanager-client.service` - Версию ПринтМенеджера: `cat /opt/printmanager/.version` - Описание сценария и шагов воспроизведения - ОС рабочей станции и сервера ## Связанные страницы - [Задание не появляется в очереди печати](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadanie-ne-poiavliaetsia-v-oceredi-pecati) # Задание отправлено но не появилось на сервере ## Симптом Пользователь отправил документ на принтер Printum, но задание не появилось в системе (нет в разделе «Задания» и на МФУ). ## Диагностика ### Шаг 1. Проверить логи клиента ПМ **Windows:** Win+R → `eventvwr` → источник _ПринтМенеджер Client_. **Linux:** ``` cat /var/log/printum/printmanager_client.log ``` ### Шаг 2. Проверить подключение к серверу ПМ Ошибка `HTTPSConnectionPool: Max retries exceeded` — клиент не достигает сервер. Проверьте подключение с АРМ до test250-158.prtm.tst, например, с помощью ping. Если подключение существует, то проверьте доступность порта 8080, как до АРМ, так и от него. ### Шаг 3. Проверить настройку IGNORE_USERNAME_CASE При бесклиентской печати: убедитесь, что в панели ПринтМенеджер → Системные настройки → Настройки импорта из доменов включена настройка `IGNORE_USERNAME_CASE` (если регистр логина на АРМ отличается от домена). ## Связанные страницы - [Принтеры не появляются на рабочей станции](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/printery-ne-poiavliaiutsia-na-rabocei-stancii) - [Задание не распечатывается на принтере](http://wiki.printum.io/books/7-ustranenie-neispravnostei/page/zadanie-ne-raspecatyvaetsia-na-printere) # Error 401 — пользователь не найден в ПМ (клиент ПМ Linux) ### Симптомы Задание отправлено на печать, но в очереди ПринтМенеджер не появляется. В логах клиента ПМ: ``` Job 00233 for Printum failed: 401 Client Error: Unauthorized for url: https://:8080/create_job ``` или: ``` ipplib.IppTransportException: Error: 401 ``` --- ### Причина Пользователь, авторизованный в ОС Linux, не существует в ПринтМенеджер, или не прошла синхронизация Мониторинг–ПринтМенеджер после добавления пользователя. --- ### Диагностика **Шаг 1. Проверить, существует ли пользователь в ПринтМенеджер:** В панели администратора ПринтМенеджер → Сотрудники: найти пользователя по имени учётной записи Linux → в его карточке проверить наличие Учётной записи с указанным логином и uid. **Шаг 2. Проверить синхронизацию:** Если пользователь есть в Мониторинге, но нет в ПринтМенеджер — не прошла синхронизация Мониторинг–ПринтМенеджер. **Шаг 3. Проверить Ключ доступа ПринтМенеджера:** ```bash cat /opt/printum/printmanager_client/settings.yml | grep access_token ``` Токен должен совпадать с ключом доступа ПринтМенеджера, к которому подключён клиент. --- ### Решение **Если пользователя нет в ПринтМенеджер:** 1. Убедиться, что пользователь существует в Мониторинге. 2. Запустить синхронизацию домена в Личный кабинет → Настройки → Интеграции → Домены. 3. Запустить синхронизацию Мониторинг–ПринтМенеджер: панель администратора М → ПринтМенеджеры → «Синхронизировать». 4. Проверить, появился ли пользователь в панели ПринтМенеджер. **Если `access_token` неверный:** Обновить токен в `settings.yml`: ```bash sudo nano /opt/printum/printmanager_client/settings.yml # Указать актуальный access_token из Личного кабинета → Настройки → Интеграции → ПМ sudo systemctl restart printum-printmanager-client.service ``` --- ### Как проверить результат Отправить тестовое задание от пользователя. Задание появляется в очереди ПринтМенеджер. В логах нет `401`. --- ### Когда эскалировать - Пользователь есть в ПринтМенеджер, токен верный, но ошибка 401 сохраняется. - Синхронизация завершается с ошибкой. Приложить к заявке: логи клиента ПМ, версию ПринтМенеджер, имя пользователя (без персональных данных), конфигурационный файл CUPS на АРМ. --- ### Связанные страницы - [Клиент ПМ на Linux — установка и проверка](https://wiki.printum.io/books/3-ustanovka/page/klient-pm-na-linux-ustanovka-i-proverka) - [Как работает синхронизация пользователей с доменом](https://wiki.printum.io/books/4-integracii/page/kak-rabotaet-sinxronizaciia-polzovatelei-s-domenom) - [Как работает синхронизация Мониторинга и ПринтМенеджера](https://wiki.printum.io/books/1-arxitektura-i-koncepcii/page/kak-rabotaet-sinxronizaciia-monitoringa-i-printmenedzera) # Ошибка проверки SSL-сертификата: Hostname mismatch ## Симптом В логах ПринтМенеджера или при установке появляется ошибка: ```text [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for '<адрес>' ``` Возможные проявления: * не работает синхронизация Мониторинга и ПринтМенеджера; * CUPS не создаёт принтеры; * встроенное приложение не подключается к серверу. ## Причина Компонент обращается к серверу по адресу, который отсутствует в сертификате (CN или Subject Alternative Name). Типичные ситуации: * система была установлена по hostname, а сертификат выпущен для IP-адреса (или наоборот); * после обновления изменился адрес сервера, а сертификат не был перевыпущен; * в переменной `MON_HOSTNAME` или `MONITORING_ADDRESS` указан неверный адрес; * при использовании собственных сертификатов отсутствует необходимый CN или SAN; * в кластерной конфигурации или филиальной сети один сертификат используется для нескольких серверов. ## Диагностика Проверьте, для какого адреса выпущен сертификат: ```bash openssl s_client -connect <адрес_сервера>:<порт> /dev/null | openssl x509 -noout -subject -ext subjectAltName ``` Сравните результат с адресом, по которому компонент обращается к серверу. Если Мониторинг и ПринтМенеджер установлены на разных серверах: ```bash grep MONITORING_ADDRESS /opt/printmanager/.env ``` Если Мониторинг и ПринтМенеджер установлены на одном сервере — проверьте значение **EXT_HOSTNAME** в панели администратора ПринтМенеджера. ## Решение ### Автоматические сертификаты Переустановка без SSL-параметров пересоздаёт сертификаты автоматически под текущий адрес: ```bash # М sudo curl -L https://s3.printum.io/box/monitoring/install.sh | sudo -E bash # ПМ sudo curl -L https://s3.printum.io/distrib/printum-printmanager/install.sh | sudo -E bash ``` ### Собственные сертификаты Перевыпустить сертификат для актуального адреса сервера. CN и SAN должны содержать адрес, по которому компонент обращается к серверу. Затем обновить с новыми файлами: ```bash sudo curl -L https://s3.printum.io/box/monitoring/install.sh | \ sudo -E SSL_CERT=/path/cert.crt \ SSL_KEY=/path/cert.key \ SSL_CERT_CA=/path/ca.crt bash -s agent ``` ### Кластер и филиальная сеть Каждый сервер должен использовать собственный сертификат. Все сертификаты должны быть выпущены одним удостоверяющим центром (CA). ## Связанные страницы - [Требования к сертификатам безопасности](https://wiki.printum.io/books/3-ustanovka/page/trebovaniia-k-sertifikatam-bezopasnosti) - [Как обновить Printum](https://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/kak-obnovit-printum) # Проблемы интеграций # Синхронизация Мониторинга и ПринтМенеджера не выполняется ## Симптом Изменения, сделанные в Мониторинге, не применяются на ПринтМенеджерах (пользователи, правила, принтеры не синхронизируются). ## Как работает синхронизация Мониторинг — центральный сервер, ПринтМенеджеры работают в подчинённом режиме. По умолчанию синхронизация выполняется **1 раз в час**. Изменения вступают в силу не мгновенно. ## Диагностика ### Шаг 1. Проверить доступность ПринтМенеджера с Мониторингом - Порты между Мониторингом и ПринтМенеджер должны быть открыты (8000, 8010, 8080). - Сертификаты должны быть актуальны с обеих сторон. ### Шаг 2. Запустить синхронизацию вручную Нажмите **«Синхронизировать»** в карточке нужного ПринтМенеджера или иконку синхронизации в таблице. ### Шаг 3. Проверить Docker-контейнеры ``` cd /opt/printum && sudo docker-compose ps cd /opt/printmanager && sudo docker-compose ps ``` Все контейнеры должны быть в статусе `Up`. ## Связанные страницы - [Расписание синхронизации с доменом](http://wiki.printum.io/books/4-integracii/page/raspisanie-sinxronizacii-s-domenom) # Ошибка подключения к почтовому серверу ## Симптом Уведомления не приходят по почте, тестовое письмо не отправляется, пользователи не могут восстановить пароль. ## Диагностика ### Шаг 1. Отправить тестовое письмо Перейдите в **Настройки → Интеграции → Почта**. Введите адрес в поле **«Почта для тестового письма»** и нажмите **«Отправить тестовое письмо»**. ### Шаг 2. Проверить параметры подключения | Параметр | Что проверить | | :--- | :--- | | SMTP-сервер | Адрес доступен с сервера Мониторинга | | Порт | Порт открыт в firewall (25, 465, 587) | | Логин/Пароль | Учётные данные корректны | | Адрес отправителя | Должен совпадать с логином (требование большинства SMTP-серверов) | | TLS/SSL | Соответствует конфигурации сервера | ## Что проверить перед эскалацией - Тестовое письмо успешно отправлено - Порт SMTP открыт - Логин и пароль корректны ## Связанные страницы - [Настройка подключения к почтовому серверу](http://wiki.printum.io/books/4-integracii/page/nastroika-podkliuceniia-k-poctovomu-serveru) # Лицензия истекла — что происходит и что делать ### Симптомы - Система отправила уведомление: «Срок действия лицензии истекает» или «Срок действия лицензии истёк». - В ЛК отображается предупреждение об истечении лицензии. - Часть функционала может быть ограничена. --- ### Что происходит при истечении лицензии **Годовые лицензии:** после истечения срока ПО перестаёт функционировать. Необходимо срочное продление. **Бессрочные лицензии:** включают 1 год гарантийной технической поддержки. После истечения поддержки система продолжает работать, но обновления и обращения в ТП становятся недоступны. Для восстановления поддержки — приобрести продление. > **Примечание:** Уведомления об истечении отправляются заблаговременно — реагировать нужно до истечения, а не после. --- ### Что делать Продлить лицензию по стандартной процедуре. Обратится на sales@printum.io --- ### Важно про перерыв в продлении Если продление оформлено с перерывом, новый срок технической поддержки исчисляется с момента окончания предыдущего периода — а не с даты оформления. То есть перерыв не «сдвигает» начало нового периода. --- ### Как проверить результат ЛК → Настройки → Общие → Организации: в списке лицензий отображается обновлённый срок действия. --- ### Когда эскалировать - Система полностью недоступна. Войти в ЛК невозможно. - Новый ключ введён, но срок не обновился. - Новый ключ введён, срок действия обновился, но опрос устройств не происходит более установленного времени сканирования сети и печать на устройствах не осуществляется. Обратиться напрямую: support@printum.io — указать название организации и идентификатор, а так же описать какие действия уже были проделаны. --- ### Связанные страницы - [Как активировать или продлить лицензию](https://wiki.printum.io/books/5-upravlenie-sistemoi/page/kak-aktivirovat-ili-prodlit-licenziiu) # Ошибка проверки SSL-сертификата: self signed certificate in certificate chain ## Симптом В логах ПринтМенеджера появляется ошибка: ```text [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain ``` Синхронизация Мониторинга и ПринтМенеджера не выполняется. ## Причина В файл серверного сертификата включён корневой сертификат удостоверяющего центра. Корневой сертификат должен храниться отдельным файлом и передаваться как `SSL_CERT_CA`. ## Диагностика Проверить, сколько сертификатов содержится в файле `server.crt`: ```bash grep -c "BEGIN CERTIFICATE" /path/to/server.crt ``` Норма: 1 (серверный сертификат) или 2 (серверный + промежуточный CA). Ошибка: 3 и более — скорее всего, включён корневой сертификат. ## Решение Разделить сертификаты: - `server.crt` — только серверный сертификат (и промежуточный CA, если есть). - `ca.crt` — только корневой сертификат. Переустановить с корректно разделёнными файлами: ```bash sudo curl -L https://s3.printum.io/box/monitoring/install.sh | \ sudo -E SSL_CERT=/path/server.crt \ SSL_KEY=/path/server.key \ SSL_CERT_CA=/path/ca.crt bash -s agent ``` --- ## Связанные страницы - [Требования к сертификатам безопасности](https://wiki.printum.io/books/3-ustanovka/page/trebovaniia-k-sertifikatam-bezopasnosti) # Ошибка проверки SSL-сертификата: unable to get local issuer certificate ## Симптом В логах компонентов появляется ошибка: ```text [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate ``` ## Причины Не удалось проверить цепочку доверия SSL-сертификата. Возможные причины: - Отсутствие поля **Subject Alternative Name (SAN)** в сертификате сервера. - Отсутствие данных о поставщике (центр сертификации, CA) в сертификате сервера. ## Диагностика #### Проверьте наличие SAN: ``` openssl x509 -in /path/to/server.crt -noout -ext subjectAltName ``` Норма: вывод содержит `DNS:` или `IP:` записи. Ошибка: пустой вывод или `No extensions in certificate` — SAN отсутствует. Решением является перевыпуск сертификата с полем SAN. В SAN указать все адреса сервера: ``` DNS:server.example.com DNS:server IP:10.0.0.1 ``` #### Проверьте наличие данных о поставщике сертификата. В Windows откройте данные по сертификату, перейдите во вкладку «Путь сертификации» и обратите внимание на цепочку: сертификат сервера должен быть вторым от CA-сертификата. Если CA-сертификата в цепочке нет - возникнет ошибке проверки сертификата сервера. [![Screenshot_1.png](https://docs.printum.io/uploads/images/gallery/2026-07/scaled-1680-/screenshot-1.png)](https://docs.printum.io/uploads/images/gallery/2026-07/screenshot-1.png) Решением является перевыпуск сертификата с корректной цепочкой сертификации (наличие данных о центре сертификации). После перевыпуска, нужно внедрить сертификаты методом обновления Мониторинга и\или ПринтМенеджера. Пример офлайн обновления с указанием переменных для установки собственных сертификатов: ``` sudo -E SSL_CERT=/path/server.crt SSL_KEY=/path/server.key SSL_CERT_CA=/path/ca.crt ./install.sh ``` --- ## Связанные страницы - [Требования к сертификатам безопасности](https://docs.printum.io/books/8-spravocnik/page/trebovaniia-k-sertifikatam-bezopasnosti) # BrokenPipeError — задания не передаются из CUPS в ПМ (Linux) ### Симптомы - Пользователь отправил задание на печать — в CUPS на АРМ статус `Job completed`. - В очереди ПринтМенеджер и на МФУ задания нет. - Служба клиента ПМ запущена `active (running)`. - В логах клиента ПМ: ``` BrokenPipeError: [Errno 32] Broken pipe ``` --- ### Причина Клиент ПМ считывает задание из CUPS, но соединение обрывается до того, как задание передано в ПринтМенеджер. Типичные причины: 1. **Несовместимость ОС** — после обновления Astra Linux (например, 1.7.7 → 1.7.9) изменилась версия Python или системных библиотек, с которыми работает клиент. 2. **Конфликт с CUPS** — на АРМ установлен конкурирующий сервис печати (PrintXpert, SafeQ и др.). 3. **Ошибка конфигурации CUPS** — в CUPS на АРМ присутствуют параметры, запрещающие отправку заданий или добавление принтеров. --- ### Диагностика **Шаг 1. Проверить логи клиента ПМ:** ```bash sudo cat /var/log/printum/printmanager-client | grep -i "broken\|error\|pipe" ``` Зафиксировать полный текст ошибки — строки до и после `BrokenPipeError`. **Шаг 2. Проверить версию ОС:** ```bash cat /etc/os-release ``` **Шаг 3. Проверить наличие конкурирующих сервисов печати:** ```bash systemctl list-units | grep -i "print\|cups\|spool" ``` Если есть активные сервисы кроме `cupsd` и `printum-printmanager-client` — вероятен конфликт. **Шаг 4. Проверить доступность CUPS:** ```bash lpstat -r ``` Норма: `scheduler is running`. --- ### Решение #### Переустановка клиента ПМ (первый шаг) Переустановка не меняет настройки — `settings.yml` сохраняется. **Шаг 1.** Остановить службу ```bash sudo systemctl stop printum-printmanager-client.service ``` **Шаг 2.** Переустановить по инструкции из разделов [Удаление клиента ПМ на Linux](https://wiki.printum.io/books/3-ustanovka/page/udalenie-klienta-pm-na-linux) **и** [Клиент ПМ на Linux — установка и проверка](http://wiki.printum.io/books/3-ustanovka/page/klient-pm-na-linux-ustanovka-i-proverka) \ **Шаг 3.** Проверить статус после установки ```bash sudo systemctl status printum-printmanager-client.service ``` #### Конфликт с другим ПО управления печатью Деактивировать конкурирующий сервис: ```bash sudo systemctl stop <имя_сервиса> sudo systemctl disable <имя_сервиса> ``` После этого перезапустить клиент ПМ и проверить передачу заданий. #### После обновления ОС Переустановка клиента ПМ с актуальным дистрибутивом решает проблему несовместимости. Если не помогло — эскалировать в ТП с логами и версией ОС. --- ### Как проверить результат ```bash sudo tail /var/log/printum/printmanager-client.log -f ``` Ошибок `BrokenPipeError` нет. Отправить тестовое задание — оно должно появиться в очереди ПринтМенеджер. --- ### Когда эскалировать - Переустановка не помогла. - ОС обновлялась перед появлением проблемы. - Конкурирующих сервисов нет, но ошибка сохраняется. Приложить к заявке: файл логов Клиента ПМ с ошибкой, версию ОС (`cat /etc/os-release`), версию клиента ПМ, версию ПринтМенеджер. --- ### Связанные страницы - [Клиент ПМ на Linux — установка и проверка](https://wiki.printum.io/books/3-ustanovka/page/klient-pm-na-linux-ustanovka-i-proverka) - [Клиент ПМ перестал работать после обновления Astra Linux](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/klient-pm-perestal-rabotat-posle-obnovleniia-astra-linux) - [Как диагностировать проблемы печати по этапам пути задания](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/kak-diagnostirovat-problemy-pecati-po-etapam) # Встроенное приложение — диагностика проблем ### Как устанавливается приложение Автоматическая установка из Личного кабинета (кнопка «Установить приложение»): - Xerox, Konica Minolta, HP, Sharp, Ricoh Ручная установка через интерфейс МФУ с токеном: - Kyocera, Lexmark, Pantum, Fplus, Lexmark, Avision Настройка не требующая установки пакета приложений: - Brother, Epson Для получения инструкций по конкретному вендору и модели необходимо направить запрос в Техническую поддержку: support@printum.io --- ### Предусловия для работы приложения Перед диагностикой убедиться, что выполнены все условия: - Устройство добавлено в Мониторинг и опрашивается (статус не серый). - У устройства есть лицензия **M** (мониторинг) + **PM** (управление печатью). - Существует свободный слот лицензии **EMB** (встроенное приложение) - Синхронизация Мониторинг–ПринтМенеджер выполнена (`Личный кабинет → Настройки → Интеграции → ПринтМенеджер`). - МФУ доступен по сети с сервера ПринтМенеджера (проверить `ping ` с сервера). - Версия прошивки МФУ соответствует требованиям (запросить у ТП список совместимых прошивок). --- ### Алгоритм диагностики **Шаг 1. Проверить лицензии** ЛК → Управление → Устройства → развернуть карточку → вкладка «Лицензии». Должны быть активны: M, PM, EMB. Если EMB отсутствует — нажать «Установить приложение» или «Сгенерировать токен». **Шаг 2. Проверить синхронизацию** Если приложение установлено, но настройки (пользователи, правила, PIN-коды) не применяются — запустить синхронизацию Мониторинг–ПринтМенеджер вручную. **Шаг 3. Проверить логи ПринтМенеджер** * Запустить логирование в интерактивном режиме ```bash cd /opt/printmanager sudo docker-compose logs -f --tail=100 ``` * Выполнить запрос из встроенного приложения, например: авторизоваться. * В логах проверить наличие запросов в контейнере printmanager-web_1 **Шаг 4. Проверить доступность ПринтМенеджер с устройства** МФУ должен иметь сетевой доступ к серверу ПринтМенеджер. Проверить с сервера ПринтМенеджер: ```bash ping curl -k http:/// ``` Если МФУ недоступен с сервера ПринтМенеджера — сетевая проблема, решается на стороне заказчика. **Шаг 5. Переустановить приложение** Если предыдущие шаги не дали результата: 1. В ЛК → Управление → Устройства → «Удалить приложение» (или «Удалить токен»). 2. Перезагрузить МФУ. 3. Установить заново. --- ### Навигация по конкретным проблемам | Симптом | Статья | |---|---| | Приложение не устанавливается, ошибка при установке | [Встроенное приложение не устанавливается](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/vstroennoe-prilozenie-ne-ustanavlivaetsia) | | Белый экран или приложение не открывается | [Белый экран во встроенном приложении](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/belyi-ekran-ili-prilozenie-ne-otkryvaetsia-na-mfu) | | Пользователь авторизовался, но заданий нет | [Задания не отображаются в приложении](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/polzovatel-avtorizovalsia-no-zadaniia-ne-otobrazaiutsia) | | Авторизация по карте не работает | [Авторизация по карте не работает во встроенном приложении](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/avtorizaciia-po-karte-ne-rabotaet-vo-vstroennom-prilozenii) | | Ricoh: приложение постоянно запрашивает токен | [Ricoh — постоянный запрос токена](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/postoiannyi-zapros-tokena-na-mfu-ricoh) | | Xerox: сканирование/копирование не работает без ошибок | [Xerox — сканирование не работает, ошибок нет](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/xerox-skanirovanie-ili-kopirovanie-ne-rabotaet-osibok-net) | --- ### Что приложить при эскалации в ТП - Вендор и модель МФУ, версия прошивки. - Версия приложения (есть в интерфейсе МФУ). - Версии Мониторинга и ПринтМенеджера. - Логи системы Printum. - Описание симптома: что именно происходит на экране МФУ. # Контейнеры Unhealthy после обновления в конфигурации с балансировщиком ### Симптомы После обновления ПринтМенеджер в схеме с балансировщиком: - Один или несколько контейнеров `printmanager-app` запускаются со статусом `unhealthy`. - Нода недоступна через HAProxy (статус `DOWN` в панели HAProxy). - Печать работает частично или не работает совсем. --- ### Причины Три наиболее частые: 1. **NFS не смонтирован** — volume `printmanager_media` недоступен, контейнер не может запуститься. 2. **Redis потерял master** — после одновременного перезапуска нод Redis sentinel не успел выбрать нового мастера. 3. **Ошибка прав в printmanager-ftpd** — контейнер завершился с ошибкой при записи PID-файла. --- ### Диагностика **Шаг 1. Проверить статус всех контейнеров на проблемной ноде:** ```bash cd /opt/printmanager sudo docker-compose ps ``` Зафиксировать какие контейнеры в статусе `unhealthy` или `Exit`. **Шаг 2. Проверить монтирование NFS:** Проверьте, что NFS хранилище работает корректно на каждом сервере с ПринтМенеджерами: 1. Создайте файл test.txt таким образом: ```bash cd /opt/printmanager sudo docker-compose exec app touch /opt/app/public/media/test.txt ``` 2. Проверьте, что файл появился в NFS хранилище. 3. Удалите этот файл таким образом ```bash cd /opt/printmanager/ sudo docker-compose exec app rm /opt/app/public/media/test.txt ``` 4. Убедитесь, что файл test.txt был удален из NFS хранилища. **Шаг 3. Проверить логи `printmanager-app`:** ```bash cd /opt/printmanager/ sudo docker-compose logs app --tail=100 ``` Признак NFS-проблемы: ``` failed to mount local volume: connection refused, port=2049, addr=127.0.0.1 ``` **Шаг 4. Проверить `printmanager-redis` и `printmanager-redis-sentinel`:** ```bash cd /opt/printmanager/ sudo docker-compose logs redis redis-sentinel --tail=50 ``` Признак проблемы Redis: ``` Connection with master lost MASTER <-> REPLICA sync started +sdown master +tilt mode entered ``` **Шаг 5. Проверить `printmanager-ftpd`:** ```bash cd /opt/printmanager/ sudo docker-compose logs ftpd --tail=50 ``` Признак проблемы ftpd: ``` Permission denied при записи PID ``` --- ### Решение #### NFS не смонтирован Проверить, запущен ли stunnel (если NFS проброшен через stunnel): ```bash systemctl status stunnel ``` Если stunnel не запущен: ```bash systemctl start stunnel ``` После этого перезапустить ПринтМенеджер: ```bash cd /opt/printmanager/ sudo docker-compose down && sudo docker-compose up -d ``` #### Redis не выбрал мастера Подождать 1–6 минут — sentinel должен автоматически выбрать нового мастера. Если не восстановился: ```bash cd /opt/printmanager/ sudo docker-compose down && sudo docker-compose up -d ``` Проверить логи через 1 минуту: ```bash sudo docker-compose logs redis-sentinel --tail=30 ``` Норма: ```bash # Sentinel ID is # +monitor master redis 6379 quorum 2 * +slave slave :6379 6379 @ redis 6379 * +sentinel sentinel 26379 @ redis 6379 ``` #### Ошибка прав в printmanager-ftpd ```bash cd /opt/printmanager/ sudo docker-compose down && sudo docker-compose up -d ``` Если ошибка повторяется — передать логи в ТП. --- ### Как проверить результат ```bash sudo docker-compose ps ``` Все контейнеры в статусе `Up`. В панели HAProxy нода отображается как `UP`. Тестовое задание успешно печатается. --- ### Когда эскалировать - Причина не определяется по логам. - NFS недоступен по сетевым причинам (не связано с stunnel). - Redis не восстанавливается после перезапуска. - Проблема воспроизводится на всех нодах одновременно. Приложить к заявке: вывод `docker-compose ps` со всех нод, логи всех нод ПринтМенеджера, версии М и ПринтМенеджер. --- ### Связанные страницы - [Как обновить Printum](https://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/kak-obnovit-printum) - [Как работает отказоустойчивый ПринтМенеджер](https://wiki.printum.io/books/1-arxitektura-i-koncepcii/page/kak-rabotaet-otkazoustoicivyi-printmenedzer) - [Восстановление из резервной копии](https://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/vosstanovlenie-iz-rezervnoi-kopii) # Ошибка «Provided license key instead of activation key» ### Симптомы При попытке активировать лицензию в `Личный кабинет → Настройки → Общие → Организации система` или в `Личный кабинет → Первый запуск → Активация лицензии` показывает ошибку: ``` Provided license key instead of activation key ``` Или в письме от Технической поддержки приходит лицензионнвй ключ, но при вводе система его не принимает. --- ### Причина Перепутаны два разных значения: - **Токен активации** — генерируется в Личном кабинете, отправляется в ТП. Выглядит как строка UUID. - **Лицензионный ключ** — выдаётся ТП в ответ на токен. Вводится в поле «Указать лицензионный ключ». Выклядит как длинная строка Base64/JWT. Ошибка возникает когда в поле лицензионного ключа вводится токен активации (или наоборот), либо когда вводится токен активации из другой системы или организации. --- ### Решение **Шаг 1.** В Личный кабинет → Настройки → Общие → Организации нажать **«Токен активации»** и скопировать актуальный токен именно этой системы. **Шаг 2.** Отправить этот токен в Техническую поддержку (support@printum.io) с названием организации. **Шаг 3.** Полученный от Технической поддержки ключ ввести в поле **«Указать лицензионный ключ»** → «Сохранить». --- ### Как проверить результат В списке лицензий карточки организации отображаются типы лицензий, количество и срок действия. --- ### Когда эскалировать - Ключ введён корректно (получен от ТП в ответ на токен этой системы), но ошибка сохраняется. - Система не позволяет открыть раздел «Организации». --- ### Связанные страницы - [Как активировать или продлить лицензию](https://wiki.printum.io/books/5-upravlenie-sistemoi/page/kak-aktivirovat-ili-prodlit-licenziiu) # Синхронизация М–ПМ завершается ошибкой 403 после обновления ### Симптомы В различных системных отчетах ПринтМенеджера `https://:8080/config/web/reports` после обновления: ``` Bad response from monitoring 403 with error: ``` Принтеры не синхронизируются из Мониторинга в ПринтМенеджер. Задания на МФУ не приходят. --- ### Причина После обновления Мониторинга или ПринтМенеджер значение `MONITORING_KEY` перестало совпадать между компонентами. Это происходит если при обновлении ключ был пересоздан или не перенесён корректно. --- ### Решение 1. В панели администратора Мониторинга → Принтменеджеры → Принтменеджеры: вписать новое значение в поле `Кодовый ключ`, установите чек-бокс `Валидация` и сохраните. 2. В панели администратора ПринтМенеджер → Настройки → Настройки синхронизации с Мониторингом: вставить тот же ключ в поле `MONITORING_KEY`, сохранить. 3. Запустить синхронизацию вручную: панель администратора Мониторинга → Принтменеджеры → Принтменеджеры → «Синхронизировать сейчас». --- ### Как проверить результат Синхронизация завершается без ошибок. В различных системных отчетах ПринМенеджера нет `403`. Принтеры из Мониторинга появились в панели ПринтМенеджера. --- ### Когда эскалировать - Ключи совпадают, но ошибка 403 сохраняется. - Нет доступа к панели администратора ПринтМенеджер. Приложить к заявке: версии Мониторинга и ПринтМенеджер и логи обоих системы. --- ### Связанные страницы - [Как обновить Printum](http://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/kak-obnovit-printum) - [Как работает синхронизация Мониторинга и ПринтМенеджера](http://wiki.printum.io/books/1-arxitektura-i-koncepcii/page/kak-rabotaet-sinxronizaciia-monitoringa-i-printmenedzera) # Счётчики не обновляются после обновления Мониторинга ### Симптомы - После обновления Мониторинга счётчики принтеров заморожены на дате обновления. - В Личном Кабинете → "Отчёты по устройствам" - дата последнего опроса не меняется. - Агент мониторинга работает, ошибок в админке Мониторинга нет. --- ### Причина Две наиболее частые: 1. **Агент не перезапустился корректно** после обновления — продолжает работать старая версия или агент завис. 2. **Ошибка чтения данных в ClickHouse** — при крупном обновлении (например, 4.1 → 4.3) формат хранения данных изменился, агент получает ошибку при записи или чтении. --- ### Диагностика Проверить статус контейнера агента: ```bash sudo systemctl status printum-agent.service ``` Проверить логи агента в интерактивном режиме: ```bash cd /opt/printum-agent/ tail agent.log -f ``` Признак проблемы 1 (агент завис): ``` # Ошибки по запуску периодических задач на опрос и сканирование: level=error msg="get /agent/poll_tasks failed level=error msg="get /agent/scan_tasks failed ``` Проверить работу периодической задачи по обработке регистров принтеров (periodic_update_register_of_printers_in_snmp): ```bash cd /opt/printum/ sudo docker-compose logs -f --tail=5 worker-low ``` Признак проблемы 2 (ClickHouse): ``` [: ERROR/ForkPoolWorker-26] Task apps.printer.tasks.periodic_update_register_of_printers_in_snmp[] raised unexpected: ServerException('DB::Exception: Unknown codec family code: 0... ``` --- ### Решение #### Агент не перезапустился ```bash sudo systemctl restart printum-agent.service ``` Подождать 2–3 минуты, проверить счётчики в ЛК. #### Ошибка ClickHouse Не устраняется самостоятельно. Требует вмешательства на уровне БД. Передать в ТП: - Логи агента системы Мониторинга. - Версию Мониторинга до и после обновления. - Вывод `sudo docker-compose ps`. --- ### Как проверить результат - В ЛК → Отчёты по устройствам: дата последнего опроса обновилась. - Отправить тестовое задание на печать — счётчик вырос. --- ### Когда эскалировать - В логах ошибка ClickHouse (`Unknown codec family code` или `ServerException`). - Агент запускается, но данные не поступают более 30 минут. --- ### Связанные страницы - [Как обновить Printum](http://wiki.printum.io/books/6-obnovlenie-i-obsluzivanie/page/kak-obnovit-printum) - [Процессы в Мониторинге](http://wiki.printum.io/books/1-arxitektura-i-koncepcii/page/processy-v-monitoringe) # Файл сканирования не приходит на email ## Симптомы - Пользователь выполнил сканирование на email во встроенном приложении — операция завершилась без ошибок на экране МФУ. - Письмо со сканом не пришло. - Кнопка «Сканировать на e-mail» в приложении неактивна. --- ### Диагностика **Шаг 1. Проверить SMTP-настройки ПринтМенеджера** Перейдите в панель администратора ПринтМенеджера → Constance → Настройки → Настройки электронной почты (`https://:8080/config/constance/config/`). Проверьте корректность данных в следующий полях: - EMAIL_HOST - адрес SMTP-сервера. - EMAIL_PORT - порт SMTP-сервера. - EMAIL_FROM - почтовый адрес отправителя. - EMAIL_HOST_USER - имя УЗ электронной почты отправителя. - EMAIL_HOST_PASSWORD - пароль УЗ электронной почты отправителя. - EMAIL_USE_TLS - включение TLS-шифрования. - EMAIL_USE_SSL - включение SSL-шифрования. - EMAIL_SUPPORT - почтовый адрес технической поддержки. Если данные введены не верно, то выполнить настройку в Личном кабинете → `Настройки → Интеграции → Почта`, после чего провести синхронизацию между Мониторингом и ПринтМенеджером в Личном кабинете → `Настройки → Интеграции → ПМ`. Отправьте тестовое письмо. Если тестовое письмо не приходит — проблема в SMTP-настройках, а не в сканировании. > **Примечание** Типичные ошибки в логах при неверных SMTP-настройках: >``` > Email message to <адрес> was not sent: authentication error > ``` **Шаг 2. Проверить email пользователя** Перейдите в Личный кабинет → `Управление → Пользователи → карточка пользователя → поле «E-mail»`. Если email не заполнен — кнопка отправки в приложении будет неактивна или при сканировании ничего не произайдёт. Проверьте, что при выгрузке пользователей из домена был сопоставлен атрибут, например: для AD - mail = email, и что в домене у целевого пользователя существует почта. Проверьте, что адрес почты пользователя попал в карточку пользователя в панели администратора ПринтМенеджера: `Управление печатью → Сотрудники → карточка пользователя`. **Шаг 3. Проверить задание в ПринтМенеджере** Перейдите в панель администратора ПринтМенеджера → `Управление печатью → Задания печати`: найти задание сканирования. Если задания нет — файл не дошёл с МФУ до ПринтМенеджера (проблема в приложении или сети, а не в email). **Шаг 4. Проверить логи** Запустите чтение логов в интерактивном режиме: ``` cd /opt/printmanager sudo docker-compose logs -f --tail=10 ``` Выполните сканирование в почту и посмотрите, какие данные отправляет приложение в ПринтМенеджер. **Шаг 5. Проверить логи FTP-контейнера** ``` cd /opt/printmanager && sudo docker-compose logs -f --tail=10 ftpd ``` Контейнер `ftpd` отвечает за временное хранилище файлов сканирования. Ошибки здесь означают, что файл не был сохранён перед отправкой на email. **Шаг 6. Проверить правила пользователя** Перейдите в Личный кабинет → Управление → Пользователи → карточка пользователя → Принтеры и правила. Если существует правило с действием «Запретить сканирование в почту в приложении» и оно применено на целевого пользователя, то пользователю будет недоступно меню сканирования в почту. **Шаг 7. Проверить параметр сканирования на email другого сотрудника** Если сканирование выполняется на email другого сотрудника (из приложения на МФУ Xerox, Sharp, Konica Minolta) — проверьте, включён ли параметр `SCAN_TO_ANOTHER_MAIL` в панели администратора ПринтМенеджера, раздел **«Настройки сканирования»** (`https://:8080/config/constance/config/`). **Шаг 8. Проверка ограничения на размер вложений на SMTP-сервере** Проверьте отправку письма со сканом одного листа в чёрно-белом режиме и с низким DPI. Если такое письмо доставляется, а письмо с более «тяжёлым» вложением — нет, то, вероятно, на SMTP-сервере установлено ограничение на размер файлов или писем. --- ### Решение По результатам диагностики: - SMTP-настройки неверные → исправить в Личном кабинете, проверить тестовым письмом. - Email пользователя не заполнен → добавить в карточку пользователя в домене, запустить синхронизацию с доменом, запустить синхронизацию Мониторинга и ПринтМенеджера. - Задания нет в ПринтМенеджере → диагностировать встроенное приложение. - Ошибки в логах FTP-контейнера → проверить доступность и работоспособность контейнера `printmanager-ftpd` или его портов (TCP 20/21 и пр.). - Есть запрещающее правило → изменить или удалить правило. - Сканирование на email другого сотрудника не работает → включить `SCAN_TO_ANOTHER_MAIL` в настройках сканирования. --- ### Как проверить результат Выполнить сканирование на email тестового пользователя с корректно заполненным email. Письмо приходит в течение 1-2 минут. --- ### Когда эскалировать - SMTP настроен корректно (тестовое письмо доходит), email пользователя заполнен, правил нет — скан не приходит. - В логах ошибки, которые не относятся к SMTP или правам. Приложить: логи работы контейнеров ПринтМенеджера, настройки SMTP (без пароля), версии Мониторинга и ПринтМенеджера (`cat /opt/printum/.version` и `cat /opt/printmanager/.version`). --- ### Связанные страницы - [Сканирование — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/skanirovanie-diagnostika-problem) - [Большой файл сканирования не доходит](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/bolsoi-fail-skanirovaniia-ne-doxodit-po-email) # Ошибка удаления сети Docker при обновлении Мониторинга # Симптом При обновлении Мониторинга появляется ошибка: ```text error while removing network: network printum_default id <...> has active endpoints ``` ## Причина Невозможно удалить внутреннюю сеть docker, так как она занята запущенным контейнером. Из-за этого процесс обновления не может завершиться корректно. ## Решение Перезагрузите сервер и повторите обновление. # Файл сканирования не приходит в сетевую папку ## Симптомы - Пользователь выполнил сканирование в папку — операция завершилась без ошибок на МФУ. - Файл в сетевой папке не появился. - Кнопка «Сканировать в папку» в приложении неактивна. --- ### Диагностика **Шаг 1. Проверить SMB-настройки в ПринтМенеджере** Перейдите в панель администратора ПринтМенеджера → `https://:8080/config/constance/config/` → раздел «Настройки для сканирования». Проверьте, что следующие настройки указаны корректно: - `SMB_HOSTNAME` — доменное имя или IP-адрес сервера с папкой. - `SMB_USERNAME` — логин УЗ с правами записи в папку. - `SMB_PASSWORD` — пароль УЗ с правами записи в папку. Если доменное имя не разрешается DNS — замените его IP-адрес. **Шаг 2. Проверить путь к папке пользователя** Перейдите в панель администратора Мониторинга → Настройка → Пользователи → карточка пользователя → поле «Путь к папке». Если путь не заполнен — то система не будет понимать куда отправить файл после сканирования. Путь указывается в формате `\\ИмяСервера\Папка` или с шаблонными переменными. Поддерживаемые переменные: - `$DEPARTMENT$` — отдел пользователя. - `$USERNAME$` — имя пользователя. - `$LOGIN$` — логин пользователя домена. Пример: `\\ИмяСервера\$DEPARTMENT$\$USERNAME$`. **Шаг 3. Проверить права доступа** Пользователь `SMB_USERNAME` должен иметь права на запись в папку пользователя. Проверка: попробуйте записать файл в сетевую папку от имени `SMB_USERNAME` с другого компьютера. **Шаг 4. Проверить задание в ПринтМенеджере** Перейдите в панель администратора ПринтМенеджера → Управление печатью → Задания печати: задание сканирования должно появиться. Если его нет — файл не дошёл с МФУ до ПринтМенеджера. **Шаг 5. Проверить логи** Запустите чтение логов в интерактивном режиме: ``` cd /opt/printmanager && sudo docker-compose logs -f --tail=10 ``` Выполнитее задание сканирования и проверьте логи на наличие ошибок. **Шаг 6. Проверить правила** Перейдите в Личный кабинет → Управление → Пользователи → карточка пользователя → Принтеры и правила. Если существует правило с действием «Запретить сканирование в папку в приложении» и оно применено на целевого пользователя, то пользователю будет недоступно меню сканирования в папку. --- ### Частые ситуации #### Доменное имя SMB-сервера не резолвится с сервера ПринтМенеджера Заменить `SMB_HOSTNAME` на IP-адрес в настройках ПринтМенеджера. #### Ошибка прав доступа В логах есть записи вида `Permission denied` или `Access denied` при выполнении задания сканирования. Проверить: пользователь `SMB_USERNAME` должен иметь права на запись именно в ту папку, которая указана в карточке пользователя. Права на родительскую папку без прав на дочернюю не дают доступ на запись файлов в дочернюю папку. #### Шифрование SMB несовместимо Если включён `SCAN_SMB_ENCRYPT`, SMB-сервер должен поддерживать SMBv3 или выше. На старых серверах (Windows Server 2008, Samba старых версий) шифрование может не работать. Отключите `SCAN_SMB_ENCRYPT` для проверки. #### Сканирование на папку другого сотрудника (Konica Minolta) Проверить, включён ли параметр `SCAN_TO_ANOTHER_SMB` в Настройках сканирования ПринтМенеджера (`https://:8080/config/constance/config/` → раздел «Настройки сканирования»). --- ### Как проверить результат Выполнить сканирование в папку тестового пользователя. Файл появляется в указанной сетевой папке в течение 1-2 минут. --- ### Когда эскалировать - SMB-настройки верные, путь заполнен, права есть — файл не появляется. - В логах ошибки, не связанные с правами или доменным именем сервера SMB-папки. Приложить: логи системы Printum (`bash /opt/printmanager/logs.sh`), настройки SMB (без пароля), путь к папке пользователя, версии Мониторинга и ПринтМенеджера (`cat /opt/printum/.version` и `cat /opt/printmanager/.version`). --- ### Связанные страницы - [Сканирование — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/skanirovanie-diagnostika-problem) # Не находится принтер или МФУ # Симптом Принтер или МФУ не появляются в личном кабинете в разделе **Управление → Устройства** и **Отчеты → По устройствам**. # Что проверить ## 1. Настройки локации Проверьте, что IP-адрес устройства: - указан явно в настройках локации; - либо входит в диапазон IP-адресов, указанный в настройках локации. ## 2. Настройки сетевого агента Проверьте, что локация назначена сетевому агенту. Для этого перейдите: **Настройки → Интеграции → Сетевые агенты** Локация с устройствами должна: * быть отмечена чек-боксом у агента; * либо входить в другую локацию, назначенную агенту. ## 3. Доступность устройства Проверьте, что устройство доступно по сети. На компьютере, находящемся в одной сети с устройством: 1. Откройте браузер. 2. Введите IP-адрес устройства. Если веб-интерфейс устройства открывается, переходите к следующему шагу. ## 4. Работа SNMP Убедитесь, что на устройстве включена передача данных по протоколу SNMP. Проверьте ответ устройства командой: ```bash snmpwalk -v 2c -c public ``` или ```bash snmpwalk -v 1 -c public ``` Если устройство не отвечает: * проверьте настройки SNMP на устройстве; * убедитесь, что используется правильная community string; * включите поддержку SNMP, если она отключена. ## 5. Идентификация устройства Если: * IP-адрес указан корректно; * устройство доступно по сети; * SNMP работает; но устройство по-прежнему не определяется корректно, возможно требуется дополнительная настройка параметров SNMP для данной модели устройства. Проверьте ошибки идентификации: Перейдите в раздел **Инвентаризация → Устройства** панели администратора Мониторинга. Найдите устройство по IP-адресу и посмотрите содержимое столбца **Ошибки идентификации**. При обращении в техническую поддержку обязательно приложите эти данные. # Белый экран или приложение не открывается на МФУ ### Симптомы - После нажатия иконки приложения на панели МФУ — белый экран или пустой экран без интерфейса. - Приложение открывается, но экран авторизации не появляется. - После ввода PIN-кода — белый экран вместо списка заданий. --- ### Причины и решения #### МФУ не может подключиться к серверу ПринтМенеджер Белый экран — наиболее частый признак того, что приложение не получает ответ от ПринтМенеджера. Проверить сетевой доступ МФУ к ПринтМенеджеру: - МФУ должен иметь доступ к серверу ПринтМенеджер по порту 8080 (или 1631 для CUPS) - если есть функция на МФУ. - Если функции icmp нет на МФУ, то проверить с рабочего места в той же подсети: `curl -k https://:8080/`. - Проверить статус контейнеров ПринтМенеджер: ```bash cd /opt/printmanager sudo docker-compose ps ``` Все контейнеры должны быть `Up`. - Проверить доступность административной панели ПринтМенеджера: `https://:8080/config` --- #### Несовместимая версия прошивки На некоторых моделях (особенно Pantum) после обновления прошивки приложение перестаёт открываться. Или, наоборот, устаревшая прошивка несовместима с текущей версией приложения. Решение: запросить у ТП информацию о поддерживаемой и совместимой версии прошивки для конкретной модели. Пригласить сервисного инженера для прошивки. --- #### Приложение не переустановлено после смены прошивки После обновления прошивки МФУ встроенное приложение необходимо переустановить. Решение: 1. Личный кабинет → Управление → Устройства → МФУ → «Удалить приложение». 2. Перезагрузить МФУ. 3. Установить приложение заново. --- #### Конфликт со сторонним ПО на МФУ Белый экран при авторизации по PIN-коду может быть вызван сторонними приложениями, установленными на МФУ (например, Device Software Manager). Решение: 1. Открыть веб-интерфейс МФУ → раздел установленных приложений. 2. Удалить сторонние приложения, не связанные с Printum. 3. Перезагрузить МФУ. --- ### Как проверить результат После перезагрузки МФУ открыть приложение — экран авторизации отображается корректно. Авторизация по PIN или карте выполняется успешно. --- ### Когда эскалировать - МФУ доступен по сети, контейнеры ПринтМенеджер работают, прошивка совместимая — белый экран сохраняется. - Проблема воспроизводится только на одной модели МФУ. Приложить к заявке: вендор, модель, версия прошивки, версии М и ПринтМенеджер, версия приложения, логи системы Printum. --- ### Связанные страницы - [Встроенное приложение — диагностика проблем](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/vstroennoe-prilozenie-diagnostika-problem) - [Ricoh — постоянный запрос токена](https://wiki.printum.io/books/7-ustranenie-neispravnostei/page/postoiannyi-zapros-tokena-na-mfu-ricoh) # Печать дополнительной технической страницы при бесклиентской печати # Симптом При использовании бесклиентской печати вместе с документом печатается дополнительная страница с технической информацией. Проблема может наблюдаться на устройствах: - Konica Minolta; - Kyocera. # Решение Используйте драйвер **HP Universal Printing PS**. 1. Скачайте драйвер **HP Universal Printing PS** с официального сайта HP. 2. Удалите существующий принтер. Для этого перейдите в раздел **Параметры Windows → Принтеры и сканеры**, выберите принтер, используемый для бесклиентской печати, и нажмите **Удалить устройство**. 3. Выполните повторную установку принтера, используя скачанный драйвер.При выборе драйвера из файлов архива укажите файл "hpbuio200l.inf". 4. Проверьте печать. Отправьте тестовое задание на печать и убедитесь, что дополнительная техническая страница больше не печатается. # Документ копируется с обрезанными краями # Симптом При копировании часть изображения или документа обрезается по краям листа. ## Причина Большинство принтеров и МФУ имеют непечатаемые области по краям листа. Поэтому при печати документ может выводиться без масштабирования и часть содержимого, попадающая в непечатаемую область, будет обрезана. ## Решение Включите автоматическое масштабирование документа под размер листа. Для этого: 1. Откройте панель администратора ПринтМенеджера. 2. Перейдите в раздел **Настройки**. 3. Откройте подраздел **Настройки печати**. 4. Включите параметр: ```text FIT_TO_PAGE ``` После включения параметра изображения и документы будут автоматически масштабироваться под область печати выбранного формата бумаги. # Команда docker-compose up -d завершается ошибкой # Симптом При запуске контейнеров появляется ошибка: ```text ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information. If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). ``` # Причина Docker Compose не успевает выполнить запуск контейнеров за отведённое время и завершает операцию по таймауту. ## Решение Увеличьте таймаут ожидания запуска контейнеров. Вместо стандартной команды: ```bash docker-compose up -d ``` используйте: ```bash COMPOSE_HTTP_TIMEOUT=300 docker-compose up -d ``` Значение `300` задаёт таймаут ожидания в секундах. # На устройстве Xerox не работает сканирование или копирование без отображения ошибки # Симптом На устройстве Xerox не выполняется сканирование или копирование. При этом: - процесс запускается; - явных сообщений об ошибках на экране нет; - документ не сканируется или операция не завершается. # Причина Одной из возможных причин является невозможность автоматического определения формата оригинала. Проблема может возникнуть, если: - выбран формат оригинала **Автоопределение**; - на стекле сканера отсутствует документ; - устройство не может определить размер документа по другим причинам. # Проверка Во время выполнения операции обратите внимание на информационные сообщения и статусы, отображаемые на устройстве. Если среди сообщений присутствует статус: ```text InputScanSizeNotDetermined ``` значит устройство не смогло определить формат оригинала. # Решение Вместо автоматического определения формата выберите размер оригинала вручную. После выбора формата повторите операцию. # Проблемы со сканированием больших файлов на Konica Minolta и Kyocera # Симптом На некоторых моделях Konica Minolta и Kyocera могут возникать проблемы при сканировании больших файлов. Проблема чаще проявляется при высоких настройках качества сканирования, например при разрешении **600 DPI** и выше. # Причина При сканировании больших файлов устройство может испытывать сложности с передачей файла сканирования в ПринтМенеджер по текущему протоколу. В этом случае необходимо изменить протокол передачи файлов сканирования. # Решение Измените протокол передачи файлов сканирования на FTP. 1. Откройте настройки ПринтМенеджера. Перейдите в панель администратора ПринтМенеджера: ```text https://<адрес_принтменеджера>:8080/config/constance/config/ ``` 2. Откройте настройки приложения для Konica Minolta. Перейдите в раздел **Настройка приложения для принтеров KONICA MINOLTA**. 3. Измените протокол передачи. В поле **KONICA_TRANSFER_PROTOCOL** укажите значение **FTP**. 4. Сохраните изменения и повторите сканирование большого файла. # Типовые ошибки Клиента ПМ # Назначение Данная статья содержит наиболее распространённые ошибки Клиента ПМ и рекомендации по их устранению. | Ошибка | Причина | Решение | | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `No user {'i.sokolov'} is authorized, removing all printers.` | Сотрудник с именем `i.sokolov`, авторизованный в операционной системе Windows, не авторизован в системе управления печатью. | Откройте раздел **Управление-Пользователи** в веб-интерфейсе. Убедитесь, что сотрудник существует и имеет правильный SID. Также проверьте, что параметр `access_token` введён правильно. | | `Error in VirtualPrintersUpdater: HTTPSConnectionPool(host='192.168.1.1', port=8080): Max retries exceeded with url: /direct_printers/` | Программа не смогла подключиться к серверу с адресом `192.168.1.1` и портом `8080`. | Проверьте, что сервер доступен по указанному адресу с данного компьютера. | | `Error in VirtualPrintersUpdater: (1789, 'LookupAccountName', 'Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом.')` | Программа не смогла подключиться к домену для получения необходимых данных. | Проверьте соединение с доменом. Если ошибка возникает при отправке документа от локальной учётной записи пользователя, убедитесь, что пользователь входит в рабочую группу `WORKGROUP`, а не в какую-либо другую. | | `AssertionError: Adding printer Printum means critical error. Reinstall this printer manually or application entirely.` | При старте службы программа не нашла принтер **Printum** с драйвером **Printum XPS**. Либо принтер с таким именем отсутствует, либо для него установлен неверный драйвер. | Удалите такой принтер вручную и переустановите программу. | | `http.client.RemoteDisconnected: Remote end closed connection without response` | Ошибка встречается в отказоустойчивой конфигурации, если в конфигурационном файле Клиента ПМ указан параметр `use_cups_ssl: false`. | Измените значение параметра `use_cups_ssl`. | # Статус "Ошибка - печать" при бесклиентской печати # Симптом При отправке заданий на бесклиентскую печать в очереди печати отображается состояние: ```text Ошибка – печать ``` ### Причина Из-за групповых политик принтер может использовать порт типа **TCP/IP**. ### Проверка 1. Откройте **Свойства принтера**. 2. Перейдите на вкладку **Порты**. 3. Проверьте, какой порт используется принтером. Для бесклиентской печати должен быть отмечен порт с описанием: ```text Интернет порт ``` Если вместо этого отмечен порт с описанием: ```text Стандартный порт TCP/IP ``` выполните действия ниже. ### Решение 1. Отметьте бесклиентский принтер и нажмите **Удалить устройство**. 2. Перезагрузите компьютер. 3. Откройте командную строку от имени администратора. 4. Откройте окно управления печатью с помощью команды: ```cmd printui /s /t2 ``` 5. В открывшемся окне перейдите на вкладку **Порты**. 6. Найдите TCP/IP-порт и нажмите **Удалить порт**. 7. Перезагрузите АРМ. 8. Заново добавьте принтер. # При отложенной печати появляется ошибка «Файл недоступен» # Симптом При попытке распечатать документ из очереди отложенной печати появляется сообщение: ```text Файл недоступен ``` # Причина Проблема может быть связана с недоступностью сервера хранения файлов или ошибками в его настройке. # Проверка На каждом сервере ПринтМенеджера выполните команду: ```bash sudo cat /opt/printmanager/.env ``` Убедитесь, что указаны следующие параметры: ```text DRIVER_OPTS_DEVICE=":NFS_FOLDER_PATH" ``` где `NFS_FOLDER_PATH` — путь к директории на NFS-сервере. ```text DRIVER_OPTS_O="addr=NFS_ADDR,nolock,soft,rw" ``` где `NFS_ADDR` — IP-адрес или доменное имя NFS-сервера. ```text DRIVER_OPTS_TYPE="nfs" ``` Если вместо этого указаны настройки: ```text DRIVER_OPTS_TYPE=none DRIVER_OPTS_O=bind DRIVER_OPTS_DEVICE=/opt/printmanager/volumes/media ``` замените их на настройки NFS. Если параметры указаны верно, убедитесь, что: * сервер NFS доступен; * из директории `NFS_FOLDER_PATH` можно прочитать файл; * в директорию `NFS_FOLDER_PATH` можно записать файл. # Ошибка `too many clients already` при подключении к PostgreSQL # Симптом В логе контейнера `printmanager-app` появляется ошибка: ```text django.db.utils.OperationalError: connection to server at "DB_HOST", port POSTGRES_PORT failed: FATAL: sorry, too many clients already ``` где: * `DB_HOST` — IP-адрес или доменное имя сервера базы данных; * `POSTGRES_PORT` — порт PostgreSQL. # Причина Превышено максимально допустимое количество подключений к базе данных PostgreSQL. # Решение Увеличьте значение параметра `max_connections` в конфигурации PostgreSQL. Порядок настройки описан в разделе **«Установка базы данных PostgreSQL»**. # Не удается подключить бесклиентскую печать на Windows Server При добавлении принтера Printum для бесклиентской печати на Windows Server может появиться ошибка: > **«ОС Windows не удается подключиться к принтеру»**. Проблема может возникнуть, даже если сервер ПринтМенеджера доступен с Windows Server и адрес принтера открывается через браузер или `curl`. В этом случае проверьте наличие компонентов Windows, необходимых для подключения интернет-принтера. ## Проверка доступности ПринтМенеджера 1. На Windows Server откройте в браузере адрес принтера Printum: ```text https://ip_pm:1631/printers/Printum ``` где `ip_pm` — адрес, на котором доступен ПринтМенеджер. 2. Если используется HTTPS, убедитесь, что корневой сертификат Printum добавлен в хранилище **«Доверенные корневые центры сертификации»**. 3. Проверьте доступность адреса принтера с помощью `curl`. Если сервер отвечает по указанному адресу, но при добавлении принтера Windows сообщает, что не удается подключиться к принтеру, перейдите к проверке компонентов Windows. ## Проверка WebClient Откройте PowerShell от имени администратора и выполните: ```powershell Get-WindowsFeature Web-Client ``` Проверьте состояние компонента **Web-Client**. Если компонент отсутствует, установите его: ```powershell Install-WindowsFeature Web-Client ``` После установки перезагрузите Windows Server. Повторно добавьте принтер Printum по адресу: ```text https://ip_pm:1631/printers/Printum ``` > **Важно.** Успешное открытие адреса Printum в браузере или получение ответа HTTP 200 через `curl` подтверждает сетевую доступность ресурса, но само по себе не подтверждает наличие WebClient, необходимого Windows для подключения интернет-принтера. ## Если проблема сохраняется Проверьте компонент **Internet Printing Client**, необходимый для работы с интернет-принтерами. ## Результат Проблема устранена, если: - принтер Printum успешно добавляется в Windows; - ошибка **«ОС Windows не удается подключиться к принтеру»** не появляется; - в свойствах принтера на вкладке **«Порты»** используется **«Интернет порт»**. Если подключение не выполняется после проверки сетевой доступности, сертификата, **WebClient**, **Internet Printing Client** и типа порта, соберите сведения об установленной версии Windows Server и результатах выполненных проверок и передайте их в службу технической поддержки.