7. Устранение неисправностей

Ошибка	Причина	Решение
Ошибка подключения / `Connection refused`	Неверный адрес или порт домена, либо LDAP недоступен	Проверьте `ldap://адрес:389`, сетевую доступность и порт `389` или `636`.
Неверный пароль / `Invalid credentials`	Неверный логин или пароль доменной учётной записи	Проверьте учётные данные. Учётная запись должна иметь права на чтение домена.
Нет пользователей при импорте	Неверный стартовый уровень поиска или фильтр	Исправьте Стартовый уровень поиска и Фильтр в настройках домена.
`certificate verify failed`	Ошибка проверки сертификата при использовании LDAPS	Проверьте сертификат LDAP-сервера и цепочку доверия сертификатов.

Шаг 3. Проверить расписание синхронизации

В разделе «Расписание» карточки домена убедитесь, что расписание синхронизации настроено.

При необходимости запустите синхронизацию вручную.

Шаг 4. Проверить обязательные атрибуты

В разделе «Атрибуты» карточки домена убедитесь, что заполнены все обязательные атрибуты:

Логин;
Фамилия;
Имя;
Идентификатор в домене;
Email.

Что приложить к обращению в поддержку

вывод команды:

bash /opt/printum/logs.sh

версию системы:

cat /opt/printum/.version

описание сценария и шагов воспроизведения;
ОС сервера.

Связанные страницы

Проблемы печати

Задание не появляется в очереди печати

Симптом

Пользователь отправил документ на печать, но задание не появляется в разделе Управление → Задания личного кабинета и в разделе Печать встроенного приложения на МФУ.

Условия возникновения

Используется отложенная печать через клиента ПринтМенеджера.

Диагностика

Шаг 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
Описание сценария и шагов воспроизведения
ОС рабочей станции и сервера

Связанные страницы

Проблемы печати

Задание не распечатывается

Симптом

Задание появилось в очереди Printum, пользователь авторизовался на МФУ, но документ не вышел на печать.

Диагностика

Шаг 1. Проверить статус задания в CUPS

Откройте CUPS: https://<ip_сервера>:1631
Перейдите во вкладку «Задания» и найдите задание.
Если задание отсутствует — проблема на стороне клиента ПринтМенеджер (см. «Задание не появляется в очереди»).
Если статус отличается от «напечатано» (например, Broken pipe) — проблема в подключении CUPS к принтеру.

Шаг 2. Проверить протокол подключения в CUPS

Перейдите во вкладку «Принтеры» в CUPS.
Сравните адрес и метод подключения устройства (ipp, ipps, socket).
Если метод отличается от поддерживаемого для вендора — измените протокол в карточке устройства в 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
Описание сценария и шагов воспроизведения
ОС сервера

Связанные страницы

Проблемы печати

Медленная печать или долгая обработка документов

Симптом

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

Диагностика и решение

Шаг 1. Включить PostScript-печать (для бесклиентской печати)

Если проблема наблюдается при бесклиентской печати, попробуйте включить режим PostScript-печати. В панели администратора ПринтМенеджера Системные настройки → Настройки печати включите параметр USE_PS_PRINTING.

Подробности настройки и ограничения режима описаны в статье «Использование PostScript-печати».

Шаг 2. Проверить драйвер печати

Если включение PostScript-печати не помогло, попробуйте заменить драйвер печати на стороне сервера. Вместо драйвера Generic PostScript Printer используйте:

родной драйвер производителя устройства;
драйвер для конкретной модели;
Generic PCL.

Связанные статьи

Проблемы печати

Не печатаются схемы в PDF при отложенной печати

Симптом

PDF-документы со схемами или чертежами не печатаются или отображаются некорректно при отложенной печати без клиента ПМ.

Решения

Шаг 1. Попробовать другой браузер/приложение

Если печать идёт из Chrome или Yandex Browser — попробуйте Firefox. Разные приложения по-разному растеризуют PDF.

Шаг 2. Отключить пересылку PostScript в драйвере (Windows 10)

Пуск → Параметры → Устройства → Принтеры и сканеры.
Выберите принтер Printum → Управление → Настройки печати → вкладка «Дополнительно».
Откройте Драйвер (+) → Пересылка PostScript → Выключено → ОК.

Предупреждение: это может ухудшить качество печати других документов.

Связанные страницы

Проблемы печати

Проблемы с печатью из Office 2010

Симптомы

Цветные документы, распечатанные из Microsoft Office 2010 через Клиент ПМ, выходят в чёрно-белом виде.

Решение

Перейдите в папку с установленным Клиентом ПМ:

C:\Program Files\printum\printmanager_client

Откройте файл settings.yml.
Измените следующие строки:

use_gs_conversion: true
use_pdf_color_analysis: true

Сохраните файл и перезапустите службу Printum Optimize Service (через компонент services).

Что проверить перед эскалацией

Параметры use_gs_conversion и use_pdf_color_analysis установлены в true.
Служба Printum Optimize Service перезапущена.
Проверена печать цветного документа после изменений.

Проблемы печати

Проблемы с печатью из LibreOffice

Симптомы

При отправке задания печати из LibreOffice через Клиент ПМ в очереди печати появляется дополнительная копия задания (задание отправляется дважды).

Решение

Откройте LibreOffice и перейдите в настройки (Alt+F12).
В разделе «LibreOffice» откройте подраздел «Печать».
Включите галочку «Задания печати в формате PDF».

Проблемы печати

Встала печать после обновления — Bad response from monitoring 500

Симптомы

После обновления Мониторинга или ПринтМенеджера печать перестала работать на всех или части устройств.
В логах ПринтМенеджер или на почту администраторов приходят ошибки вида:
```
Bad response from monitoring 500
```
Синхронизация Мониторинг–ПринтМенеджер завершается с ошибкой.

Причина

После обновления Мониторинга изменился адрес, порт или протокол синхронизации. ПринтМенеджер продолжает обращаться по старым параметрам — получает 500 вместо корректного ответа.

Диагностика

Проверить логи ПринтМенеджер:

cd /opt/printmanager
sudo docker-compose logs printum_worker-high --tail=100 | grep -i "bad response\|monitoring"

Проверить доступность Мониторинга с сервера ПринтМенеджер:

curl -k https://<адрес_М>:8001/api/health/

Норма: ответ 200. Ошибка: connection refused, timeout, 500.

Решение

1. Проверить настройки синхронизации в Личном кабинете

Настройки → Интеграции → ПринтМенеджеры: убедиться, что адрес М и порт указаны корректно.

2. Проверить .env ПринтМенеджер

grep MONITORING_ADDRESS /opt/printmanager/.env

Адрес должен совпадать с актуальным адресом сервера Мониторинга.

3. Перезапустить ПринтМенеджер

cd /opt/printmanager
sudo docker-compose down && sudo docker-compose up -d

4. Запустить синхронизацию вручную

Как проверить результат

Синхронизация завершается без ошибок.
Задания уходят на МФУ.
Логи не содержат Bad response from monitoring.

Связанные страницы

Проблемы печати

Пользователь авторизовался, но задания не отображаются

Симптомы

Авторизация на МФУ прошла успешно.
Экран очереди пуст — нет ни одного задания.
Задания были отправлены с АРМ, но до МФУ не дошли.

Решение

Шаг 1. Проверить, есть ли задание в очереди ПринтМенеджер

Панель администратора ПринтМенеджер → Администрирование → Очередь. Задание должно быть там.
Если задания нет в ПринтМенеджер — проблема на стороне формирования задания или обработки задания в ПринтМенеджере. См. Как диагностировать проблемы печати.
Если задание есть в ПринтМенеджер, но не отображается на МФУ — идём дальше.

Шаг 2. Проверить, кому принадлежит задание

Задание должно принадлежать тому же пользователю, под которым выполнена авторизация. Логин пользователя на АРМ и логин пользователя в Printum должны совпадать вплоть до регистра. Более подробно см. Задание отправлено но не появилось на сервере

Шаг 3. Проверить синхронизацию Мониторинг–ПринтМенеджер

Настройки пользователя (в том числе привязка карты, PIN-код) передаются из Мониторинга в ПринтМенеджер при синхронизации. Если пользователь был добавлен или изменён недавно — синхронизация могла не выполниться. Запустить синхронизацию вручную.

Связанные страницы

Проблемы авторизации

Пользователь не может авторизоваться на МФУ по карте

Симптом

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

Диагностика

Шаг 1. Проверить наличие карты в системе

Перейдите в Управление → Пользователи, откройте карточку пользователя → вкладка «Авторизация». Убедитесь, что карта привязана к учётной записи.

Шаг 2. Проверить способы добавления карты

Самостоятельная привязка на МФУ (рекомендуется): встроенное приложение предложит привязку при первом прикладывании. Введите PIN-код и нажмите «Привязать».
Импорт из домена: убедитесь, что атрибут карты указан в настройках синхронизации с доменом.
Ручной ввод: администратор добавляет карту в карточке пользователя.
Импорт из файла: загрузка CSV/XLS через панель администратора Мониторинга → «Карты авторизации» → «Импорт».

Шаг 3. Проверить картридер

Убедитесь, что тип картридера соответствует стандарту карты (MIFARE, HID, EM-Marine и др.).
Проверьте физическое подключение картридера к МФУ.
Протестируйте другую карту того же стандарта.

Шаг 4. Проверить совместимость

Возможны нюансы в сочетаниях «картридер ↔ модель принтера». Проверьте рекомендованный список картридеров (по запросу в поддержку Printum).

Что проверить перед эскалацией

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

Связанные страницы

Проблемы авторизации

Пользователь не может авторизоваться на МФУ по PIN

Симптом

Пользователь вводит PIN-код на экране МФУ, но авторизация не происходит или отображается ошибка.

Диагностика

Шаг 1. Убедиться, что PIN-код сгенерирован

Перейдите в Управление → Пользователи → Все, откройте карточку пользователя → вкладка «Авторизация». PIN-код должен быть сгенерирован и отправлен на e-mail пользователя.

Шаг 2. Перегенерировать PIN-код

Убедитесь, что e-mail пользователя указан и почтовый сервер настроен.
В карточке пользователя (вкладка «Авторизация») нажмите «Сгенерировать PIN-код»
Попросите пользователя проверить почту и использовать новый PIN.

Шаг 3. Проверить настройку SMTP

Если PIN не доходит по почте — проверьте настройки SMTP (Настройки → Интеграции → Почта). Отправьте тестовое письмо.

Шаг 4. Проверить встроенное приложение

PIN-авторизация доступна только во встроенном приложении Printum на устройстве. Убедитесь, что встроенное приложение установлено и активировано (лицензия EMB).

Важно

Администратор не видит PIN-код в открытом виде — только инициирует генерацию.

Связанные страницы

Проблемы авторизации

Пользователь не может войти в Личный кабинет

Симптом

Пользователь не может войти в веб-интерфейс Printum (Личный кабинет) по логину/паролю или доменной учётной записи.

Диагностика

Шаг 1. Проверить тип авторизации

Логин/пароль Printum: убедитесь, что пользователь существует в системе и пароль задан. При необходимости — сбросьте пароль через «Восстановить пароль» на странице входа.
Доменная УЗ / SSO: убедитесь, что SSO настроен (SAML или Kerberos) и пользователь импортирован из домена.

Шаг 2. Восстановить пароль

На странице авторизации нажмите «Восстановить пароль».
Введите e-mail, привязанный к учётной записи, нажмите «Отправить код».
Введите код из письма, задайте новый пароль.

Шаг 3. Проверить почтовый сервер

Если письмо не приходит — проверьте настройки SMTP (Настройки → Интеграции → Почта).

Шаг 4. Проверить роль пользователя

Убедитесь, что пользователю назначена роль с правом доступа к ЛК. Роль «Пользователь» имеет минимальный доступ.

Связанные страницы

Проблемы авторизации

Авторизация по карте не работает во встроенном приложении

Симптомы

Считыватель реагирует на карту (мигает, пищит), но авторизация в приложении не происходит.
После прикладывания карты — экран остаётся на стартовом, сессия закрывается или появляется ошибка.
Предложения привязать карту не появляется.

Диагностика

Шаг 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.

Связанные страницы

Проблемы авторизации

Постоянный запрос токена на МФУ Ricoh

Симптомы

Встроенное приложение на МФУ Ricoh постоянно запрашивает получение токена. Авторизация пользователей не завершается.

Возможная причина

Проблема может быть вызвана сторонними приложениями, установленными на принтере, которые взаимодействуют с устройством и конфликтуют с системой Принтум. Например, это могут быть утилиты управления, такие как Device Software Manager.

Решение

Проверьте установленные приложения:
- Откройте интерфейс управления принтером.
- Войдите в систему под логином и паролем администратора.
- Перейдите в раздел, где перечислены все установленные приложения.
Удалите сторонние приложения:
- Найдите приложения, не связанные с системой Принтум, но имеющие доступ к принтеру.
- Удалите их. Особое внимание уделите утилитам, которые могут управлять настройками устройства.
Перезагрузите принтер: после внесённых изменений выполните перезагрузку устройства, чтобы убедиться в устранении проблемы.

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

Логи и диагностические данные

Где смотреть логи

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 или путь к папке в профиле пользователя.

Диагностика

Найти задание в журнале: Управление → Задания → фильтр по пользователю и дате.
Проверить статус задания и наличие ошибки.
Проверить логи ПМ: docker-compose logs --tail=300 | grep -i scan
Проверить сетевую доступность SMTP и SMB с сервера ПМ:
- SMTP: telnet <smtp-host> <port>
- SMB: попробовать монтирование папки вручную
Проверить настройку обработки больших документов: 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
Описание сценария и шагов воспроизведения
ОС сервера

Решение

Убедиться в сетевой доступности SMTP/SMB с сервера ПМ.
Настроить обработку больших документов (SCAN_LARGE_DOC_PROCESS_METHOD): выбрать «Отправить ссылку», «Сетевую папку» или «Разделить».
Настроить максимальный размер в SCAN_MAX_SIZE на 20–25% меньше лимита почтового сервера.
Перезапустить контейнеры при застревании заданий: cd /opt/printmanager && docker-compose restart

Что проверить перед эскалацией

Версию ПринтМенеджера
Логи контейнера printmanager-app (grep scan)
Сетевую доступность SMTP и SMB с сервера
Размер сканируемого документа и лимиты SMTP
Статус задания в журнале

Связанные страницы

Проблемы обнаружения устройств

Принтер не обнаружен при сетевом сканировании

Симптом

Принтер включён и доступен в сети, но не появляется в 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-адрес в строку поиска, скопируйте данные из столбца “Ошибки идентификации”.

Связанные страницы

Проблемы обнаружения устройств

Некорректно отображаются запчасти устройства

Симптом

На вкладке «Детали» в карточке устройства отображаются неверные данные о расходных материалах или запчастях (неверный процент, неверное название).

Диагностика

Шаг 1. Проверить тип показателя

Показатели из SNMP помечены иконкой принтера (столбец «Оставшийся ресурс»).
Расчётные показатели (по объёму печати) помечены иконкой базы.

Шаг 2. Проверить OID-параметры устройства

Откройте карточку устройства → вкладка «Параметры».
Нажмите кнопку SNMP для просмотра всех SNMP-данных устройства.
Сопоставьте OID значения с ожидаемыми параметрами и исправьте при необходимости.

Шаг 3. Проверить характеристики модели

Вкладка «Характеристики» — убедитесь, что тип устройства и параметры указаны корректно.

Шаг 4.Проверка в справочниках

Проверьте наличие запчастей в справочниках. Для этого откройте панель администратора мониторинга, далее “Инвентаризация” > “Запчасти”. Откроется список запчастей. В строку поиска введите модель принтера именно так, как она отображается в личном кабинете, нажмите “Найти”.

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

Если данные по запчастям есть в справочнике, но не отображаются в личном кабинете, это может быть вызвано тем, что наименование модели в справочнике не совпадает с тем, как модель принтера указывается в SNMP-данных, получаемых от устройства. Для устранения проблемы требуется настройка интерпретации SNMP-данных или корректировка справочников. Отправьте запрос в службу технической поддержки с точным наименованием модели (именно так, как она отображается в личном кабинете).

Связанные страницы

Проблемы обнаружения устройств

Некорректный счётчик отпечатков

Симптом

Счётчик отпечатков в системе не совпадает с реальным показателем на принтере или не обновляется.

Диагностика

Шаг 1. Проверить синхронизацию SNMP-данных

Откройте карточку устройства → вкладка «Параметры» → нажмите SNMP.
Найдите корректный OID.
Во вкладке «Параметры» в строке счетчика укажите нужный OID.

Шаг 2. Проверить лицензию мониторинга

Сбор SNMP-данных требует активной лицензии типа M. Убедитесь, что лицензия назначена устройству (страница Настройки > Общие > Организации).

Связанные страницы

Проблемы обнаружения устройств

Не все устройства отображаются в системе

Симптомы

Часть принтеров и МФУ не появляется в отчёте по устройствам в Личном кабинете.
Устройства физически подключены к сети, включены и доступны, но система их не обнаруживает.

Диагностика и решение

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.

Перенесите printer_scan.py на сервер в любое место.
Зайдите в Личный кабинет, в раздел «Устройства».
Выберите необходимую локацию и нажмите кнопку «Excel».
Полученный отчёт переименуйте в Devices.xlsx и перенесите на сервер.
Из папки с приложением введите команду: sudo python3 printer_scan.py
Приложение запросит IP-адреса — введите диапазоном или подсетью.
Программа выведет устройства в 4 группы:
- IPs that are up — общий список откликнувшихся адресов.
- Checked as printers — устройства, отмеченные как принтеры.
- Doubtful devices with no snmp — устройства с выключенным SNMP.
- Not printers — устройства, не являющиеся принтерами.
При запросе сравнения со списком из ЛК — введите y и укажите полный путь до файла Devices.xlsx.
Отчёты сохраняются в формате CSV:
- netscan_with_snmp.csv — принтеры с включённым SNMP.
- netscan_without_snmp.csv — принтеры с выключенным SNMP.
- not_found_in_monitoring.csv — не найденные в мониторинге.

Что проверить перед эскалацией

IP-адрес устройства входит в диапазон локации и не исключён.
Сетевой агент назначен на локацию с устройствами.
Устройство доступно по сети (браузер, ping).
SNMP включён на устройстве (snmpwalk возвращает данные).
В обращении в поддержку указаны: ошибки идентификации, модель устройства, IP.

Связанные страницы

Проблемы обнаружения устройств

Некорректный список запчастей устройства

Симптомы

Наименования деталей отображаются на английском языке.
Тип детали отображается как «Другое».
Отсутствует парт-номер.
Данные по оставшемуся ресурсу деталей не отображаются.

Возможные причины

Данные по запчастям отсутствуют в справочнике.
Наименование модели в справочнике не совпадает с тем, как модель принтера указывается в 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.

Решение

Войдите в Личный кабинет на страницу «Управление → Устройства → Все».
Найдите нужный принтер в таблице и откройте карточку принтера.
Перейдите во вкладку «Драйвер».
В поле «Протокол» выберите «ipp». Нажмите кнопку «Сохранить».
После синхронизации Мониторинга и ПринтМенеджера изменения вступят в силу.

Что проверить перед эскалацией

Протокол изменён на ipp в карточке устройства.
Выполнена синхронизация Мониторинга и ПринтМенеджера.
Статистика проверена после следующего задания печати.

Проблемы обнаружения устройств

Локальные принтеры не отображаются в статистике

Симптомы

Локальные принтеры меняют своё название после печати документов. В статистике Мониторинга отображаются некорректные имена устройств.

Возможная причина

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

Решение

Откройте командную строку с правами администратора и перейдите в директорию:

C:\Windows\System32\spool\PRINTERS

Остановите службу диспетчера печати:

net stop spooler

Удалите все файлы в директории:

del *.shd
del *.spl

Запустите службу диспетчера печати:

net start spooler

Что проверить перед эскалацией

Команды выполнены с правами администратора.
Служба диспетчера печати успешно перезапущена.
Имена принтеров стабилизировались после следующих заданий печати.

Проблемы обнаружения устройств

Сканирование — диагностика проблем

Как работает сканирование в Printum

МФУ сканирует документ → встроенное приложение передаёт файл на сервер ПринтМенеджер → ПринтМенеджер формирует статистику по заданияю → ПринтМенеджер отправляет файл на email или в сетевую папку пользователя.

Из этого следует: если скан не дошёл — проблема либо в передаче файла с МФУ на ПринтМенеджер, либо в отправке с ПринтМенеджер на email/SMB.

Предусловия для работы сканирования

Перед диагностикой убедиться:

Для сканирования на email:

Почтовый сервер настроен в ПринтМенеджер: панель администратора ПринтМенеджер → Настройки → SMTP. Тестовое письмо отправляется успешно.
У пользователя заполнен email в карточке.
Синхронизация Мониторинг–ПринтМенеджер выполнена.

Для сканирования в папку (SMB):

Настроены SMB_HOSTNAME, SMB_USERNAME, SMB_PASSWORD в панели ПринтМенеджер → Настройки → Настройки сканирования.
У пользователя или отдела заполнен путь к сетевой папке.
Пользователь SMB_USERNAME имеет права на запись в папку.

Алгоритм диагностики

Шаг 1. Проверить настройки ПринтМенеджер

Панель администратора ПринтМенеджера → https://<ip_pm>:8080/config/constance/config/ → раздел «Настройки сканирования».

Для email: проверить SMTP-настройки, отправить тестовое письмо. Для SMB: проверить SMB_HOSTNAME, SMB_USERNAME, SMB_PASSWORD.

Шаг 2. Проверить карточку пользователя

Панель администратора Мониторинга → Пользователи → карточка пользователя:

Email заполнен и корректен.
Путь к сетевой папке, логин и пароль заполнен (для SMB).

Шаг 3. Проверить, не запрещено ли сканирование правилом

Личный кабинет → Управление → Пользователи → карточка пользователя → принтеры и правила. Правило «Запретить сканирование в почту» или «Запретить сканирование в папку» блокирует функцию.

Шаг 4. Проверить логи ПринтМенеджер

cd /opt/printmanager
sudo docker-compose logs --tail=100

Шаг 5. Проверить, дошёл ли файл до ПринтМенеджер

В панели администратора ПринтМенеджер → Управление печатью → Задание печати: задание сканирования должно появиться после выполнения операции на МФУ.

Если задания нет — файл не был передан с МФУ на ПринтМенеджер. Проверить сетевой доступ МФУ к серверу ПринтМенеджер и версию прошивки встроенного приложения.

Навигация по конкретным проблемам

Симптом	Статья
Скан не приходит на email	Скан не приходит на email
Скан не сохраняется в сетевую папку	Скан не сохраняется в сетевую папку
Большой файл не доходит по email	Большой файл сканирования не доходит
Konica Minolta / Kyocera: сканирование зависает при высоком DPI	Konica Minolta / Kyocera — сканирование больших файлов
Ricoh: скан не отправляется после таймаута сессии	Ricoh — скан не отправляется после таймаута сессии

Что приложить при эскалации в ТП

Вендор и модель МФУ, версия приложения.
Тип сканирования: email или SMB.
Версии Мониторинга и ПринтМенеджера.
Логи системы.
Описание: задание появляется в ПринтМенеджер или нет.

Проблемы обнаружения устройств

Konica Minolta / Kyocera — сканирование зависает при высоком DPI

Симптомы

На МФУ Konica Minolta или Kyocera при сканировании документов с высоким разрешением (DPI ≥ 600) или многостраничных документов:

Сканирование зависает или занимает очень долго.
Файл не доходит до ПринтМенеджер.
При малом DPI (150-300) сканирование работает нормально.

Причина

На некоторых моделях Konica Minolta и Kyocera при передаче больших файлов по умолчанию используется протокол, который плохо справляется с объёмными данными. Смена протокола передачи на WebDAV решает проблему.

Решение

Для Konica Minolta:

Панель администратора ПринтМенеджер → https://<ip_pm>:8080/config/constance/config/ → раздел «Настройка приложения для принтеров KONICA MINOLTA» → переменная KONICA_TRANSFER_PROTOCOL.

Изменить значение на WebDAV → сохранить.

Для Kyocera:

Панель администратора ПринтМенеджер → https://<ip_pm>:8080/config/constance/config/ → раздел «Настройка приложения для принтеров Kyocera» → переменная KYOCERA_TRANSFER_PROTOCOL.

Изменить значение на WebDAV → сохранить.

Как проверить результат

Отсканировать документ с DPI 600 на Konica Minolta или Kyocera. Файл передаётся на ПринтМенеджер без зависания и доходит до email или папки пользователя.

Когда эскалировать

Смена протокола на WebDAV не помогла.
Зависание происходит и при малом DPI.
Проблема только на одной конкретной модели.

Приложить: вендор и модель МФУ, версия прошивки, значение KONICA_TRANSFER_PROTOCOL, DPI при котором воспроизводится, логи системы Printum.

Связанные страницы

Проблемы обнаружения устройств

Ricoh — приложение постоянно запрашивает токен

Симптомы

На МФУ Ricoh встроенное приложение Printum при каждом открытии запрашивает ввод токена, несмотря на то что токен уже был введён ранее и приложение работало.

Причина

Стороннее приложение, установленное на МФУ, конфликтует с приложением Printum и сбрасывает его настройки. Наиболее часто виновник — Device Software Manager или другие утилиты управления устройством от производителя или третьих сторон.

Решение

Открыть веб-интерфейс МФУ Ricoh → войти под учётной записью администратора.
Перейти в раздел установленных приложений.
Найти и удалить все сторонние приложения, не связанные с Printum (особое внимание: Device Software Manager и аналогичные утилиты управления).
Перезагрузить МФУ.
Открыть приложение Printum — токен запрашиваться не должен.

Как проверить результат

Приложение открывается без запроса токена. Авторизация по карте или PIN-коду работает в штатном режиме.

Когда эскалировать

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

Приложить к заявке: модель МФУ Ricoh, версия прошивки, версия приложения Printum, список установленных приложений на МФУ, логи системы Printum.

Связанные страницы

Встроенное приложение — диагностика проблем

Проблемы обнаружения устройств

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.

Связанные страницы

Проблемы обнаружения устройств

Большой файл сканирования не доходит по email

Симптомы

Сканирование небольших документов работает корректно.
При сканировании многостраничных документов или с высоким DPI (300+) письмо не приходит или приходит пустое.
Почтовый сервер отклоняет письмо из-за превышения размера вложения.

Причина

Почтовые серверы имеют ограничение на размер вложения (типично 10-25 МБ). Большие сканы превышают этот лимит и отклоняются SMTP-сервером.

Решение

Настроить способ обработки больших файлов в ПринтМенеджер:

Панель администратора ПринтМенеджер → https://<ip_pm>: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.

Связанные страницы

Проблемы обнаружения устройств

Встроенное приложение не устанавливается

Симптомы

Кнопка «Установить приложение» в Личном кабинете не переключается на «Удалить приложение» — установка не завершается.
При ручной установке через PEDK или интерфейс МФУ: ошибка App installed failed, please try again later.
Токен сгенерирован, но при вводе на МФУ приложение не появляется.

Причины и решения

МФУ недоступен с сервера ПринтМенеджер

Автоматическая установка требует сетевого доступа от ПринтМенеджер к МФУ.

Проверить:

ping <ip_мфу>

Если МФУ недоступен — сетевая проблема на стороне заказчика.

Лицензия EMB не активирована или слоты исчерпаны

Проверить: Личный кабинет → Управление → Устройства → карточка устройства → вкладка «Лицензии».

Лицензия EMB должна быть активна. Если слоты исчерпаны — освободить слот у другого устройства.

Важно: для EMB обязательно нужны активные лицензии M и PM на том же устройстве.

Несовместимая версия прошивки МФУ

Некоторые версии встроенного приложения имеют требования к версии прошивки МФУ. Несовместимая прошивка — одна из наиболее частых причин ошибки App installed failed.

Проверить: запросить у Технической поддержки список совместимых прошивок для конкретной модели. Обновить прошивку МФУ при необходимости.

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

Для Pantum: прошивка TE13 совместима с текущей версией приложения (проверить актуальность в ТП).

Для Pantum: ошибка при установке через PEDK

Если используется PEDK-инсталлятор:

Убедиться, что версия PEDK актуальная (запросить у ТП).
Убедиться, что на МФУ нет ранее установленного приложения — удалить через веб-интерфейс МФУ.
Перезагрузить МФУ перед установкой.
Проверить правильность учётных данных администратора МФУ (логин/пароль).

Токен просрочен или использован

Если установка завершилась некорректно, а токен уже был введён на МФУ:

В Личном кабинете → «Удалить токен» или "Удалить приложение".
Сгенерировать новый токен или установить приложение.
Повторить установку (в случае если используется установка через usb-накопитель).

Как проверить результат

Личный кабинет → Управление → Устройства → карточка устройства: кнопка изменилась на «Удалить приложение». Приложение отображается на экране МФУ после перезагрузки.

Когда эскалировать

Прошивка совместимая, лицензии есть, МФУ доступен — но установка не проходит.
Ошибка воспроизводится на всех устройствах одной модели.
Нет совместимой прошивки для модели МФУ.

Приложить к заявке: вендор, модель, версия прошивки, версия приложения (если известна), версии Мониторинга и ПринтМенеджера, логи системы Printum.

Связанные страницы

Встроенное приложение — диагностика проблем

Проблемы обнаружения устройств

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.

Связанные страницы

Встроенное приложение — диагностика проблем

Ошибки при установке

После установки 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}}'

Если адрес контейнера пересекается с локальной сетью сервера — причина подтверждена.

Решение

Остановите контейнеры Printum (если проблема обнаружена после первого запуска; если конфликт известен заранее — пропустите этот шаг и шаг 5):

Мониторинг:
```
cd /opt/printum
docker-compose down
```
ПринтМенеджер:
```
cd /opt/printmanager
docker-compose down
```
Проверьте наличие файла /etc/docker/daemon.json. Если файла нет — создайте:
```
sudo nano /etc/docker/daemon.json
```
Укажите новый пул IP-адресов Docker, не пересекающийся с локальной сетью (диапазон согласуйте с сетевым администратором):
```
{
  "default-address-pools": [
    {
      "base": "x.x.x.x/x",
      "size": 26
    }
  ]
}
```
size: 26 менять не требуется.
Перезапустите Docker:
```
sudo systemctl restart docker
```
Запустите контейнеры 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: Невозможно исправить ошибки: У вас зафиксированы сломанные пакеты.

Чаще всего

Установка пакетов была прервана до завершения — например, сервер выключился или перезагрузился во время установки.

Диагностика

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

Решение

Обратитесь к документации используемой ОС по восстановлению пакетного менеджера.
Если стандартное восстановление не помогает — удалите проблемные пакеты вручную и установите их заново.
Повторите установку Printum.

Проверка результата

Команда установки/обновления пакетов (apt install или её аналог в вашем дистрибутиве) отрабатывает без сообщения о сломанных пакетах; установка Printum проходит этот шаг без остановки.

Если проблема сохраняется

Соберите перед обращением в поддержку:

логи: вывод команды, которой чинили пакеты, и её результат;
версию и дистрибутив ОС;
описание сценария: что происходило перед прерыванием установки (если известно);
результаты диагностики: полный текст ошибки пакетного менеджера.

Ошибки при установке

Timeout при установке Мониторинга

Симптомы

Установка Мониторинга останавливается с ошибкой:

Timeout error. Check docker logs. Then restart the installation.

Чаще всего

Неверно указана переменная MON_HOSTNAME при установке.

Диагностика

Проверьте значение MON_HOSTNAME, указанное при установке, и сверьте с фактическим IP-адресом/доменным именем сервера.

Решение

Укажите верное значение MON_HOSTNAME (корректный IP-адрес или доменное имя сервера).
Запустите установку заново.

Проверка результата

Установка Мониторинга проходит этот шаг без таймаута; 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.

Решение

Повторите установку.
Если ошибка повторяется — перезагрузите сервер целиком и запустите установку заново.

Проверка результата

docker ps отвечает сразу, без задержки; установка проходит этот шаг без сообщения о timeout.

Если проблема сохраняется

Соберите перед обращением в поддержку:

логи: полный текст ошибки установщика;
версию ОС и версию Docker (docker --version);
описание сценария: сколько раз повторяли установку, перезагружали ли сервер.

Ошибки при установке

Ошибка при установке ПМ с шифрованием

Симптомы

Установка ПринтМенеджера с включённым шифрованием завершается ошибкой.

Чаще всего

Не указана переменная ENV_VAULT_PASSWORD, необходимая при включённом шифровании.

Диагностика

Проверьте команду запуска установки — присутствует ли в ней ENV_VAULT_PASSWORD.

Решение

Запустите установку, явно указав пароль:

sudo ENV_VAULT_PASSWORD=<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.

Возможные причины

В порядке убывания вероятности:

Версия протокола NFS не указана явно и не совпадает с той, что использует NFS-сервер.
NFS-сервер настроен неверно или недоступен по сети с сервера ПринтМенеджера.
Права на монтирование директории на стороне NFS-сервера не позволяют смонтировать её с этого узла.

Диагностика

Проверьте возможность монтирования вручную с сервера ПринтМенеджера.
Проверьте, что NFS-сервер настроен верно и доступен по сети.
Если сеть и доступность в порядке — вероятная причина в версии протокола.

Решение

Явно укажите версию протокола 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 (без учётных данных, если есть).

Ошибки при установке

ПринтМенеджер не подключается к Мониторингу после установки

Симптомы

После установки ПринтМенеджер не устанавливает соединение с сервером Мониторинга: интеграция не работает, синхронизация не запускается.

Чаще всего

Адрес Мониторинга указан неверно либо недоступен по сети.

Возможные причины

В порядке убывания вероятности:

Адрес Мониторинга, указанный при установке ПринтМенеджера, недоступен с сервера ПринтМенеджера.
Порты 8000 и 8001 закрыты firewall'ом на одном из серверов.
Сертификат сервера Мониторинга не актуален.

Диагностика

Проверяйте по порядку:

Адрес Мониторинга доступен с сервера ПринтМенеджера.
Порты 8000 и 8001 открыты в firewall на обоих серверах.
Сертификат сервера Мониторинга не просрочен.

Решение

Адрес неверный или недоступен — укажите верный адрес Мониторинга в настройках ПМ и перезапустите синхронизацию.
Порты закрыты — откройте 8000 и 8001 в firewall на обоих серверах.
Сертификат не актуален — обновите сертификат на сервере Мониторинга.

Проверка результата

Синхронизация запускается без ошибок; ПМ появляется в списке ПМ в личном кабинете Мониторинга со статусом «активен».

Если проблема сохраняется

Соберите перед обращением в поддержку:

логи: bash /opt/printmanager/logs.sh;
версию: Мониторинга и ПМ;
описание сценария: адрес Мониторинга, указанный на ПМ;
результаты диагностики: что показали проверки из раздела «Диагностика».

Связанные страницы

Ошибки при установке

Повреждена 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 отсутствует полная цепочка сертификатов «ООО Принтум».

Возможные причины

В порядке убывания вероятности:

Сертификат «ООО Принтум» отсутствует в разделе «Доверенные издатели».
Цепочка сертификатов неполная — отсутствует промежуточный или корневой сертификат.

Диагностика

Откройте оснастку certlm.msc, проверьте раздел «Доверенные издатели» — там должен быть сертификат «ООО Принтум»:

Правой кнопкой мыши на сертификате → Открыть → вкладка «Путь сертификации» — сертификаты с ошибкой цепочки помечаются жёлтым или красным цветом:

Решение

Установите сертификаты с ошибкой в соответствующие разделы:

GlobalSign GCC R45 EV CodeSigning CA 2020 — в «Промежуточные центры сертификации».
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. Убедиться, что проблема появилась именно после обновления ОС:

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. Переустановить клиент ПМ с новым дистрибутивом:

sudo systemctl stop printum-printmanager-client.service

Установить новую версию клиента ПМ по инструкции: Клиент ПМ на Linux — установка и проверка

sudo systemctl status printum-printmanager-client.service

3. Проверить передачу заданий:

sudo journalctl -u printum-printmanager-client.service --since "5 minutes ago"

Отправить тестовое задание — оно должно появиться в очереди ПринтМенеджера.

Как проверить результат

В логах нет ошибок BrokenPipeError и Error: 401.
Тестовое задание появилось в очереди ПринтМенеджера и на МФУ.

Когда эскалировать

Обновлённый дистрибутив клиента ПМ не помог.
Проблема воспроизводится не на всех АРМах после одинакового обновления ОС.
На тестовом АРМ с той же версией ОС проблема не воспроизводится — нужна более глубокая диагностика конкретного АРМ.

Приложить к заявке: версию ОС до и после обновления, версию клиента ПМ, логи journalctl с ошибкой, результат systemctl status.

Связанные страницы

Сбой активации лицензии после простоя системы

Симптомы

После длительного простоя системы (месяц и более) при входе в ЛК отображается сообщение о сбое активации. Ранее лицензия не была активирована. При попытке повторно ввести лицензионный ключ — ошибка.

Причина

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

Решение

Шаг 1. Обратится в sales@printum.io за перевыпуском ключа лицензии для продления активации.

Шаг 2. Полученный новый ключ лицензии актививароть в Личный кабинет → Настройки → Общие → Организации. Нажать кнопку «Токен активации» и Скопировать актуальный токен.

Примечание Если Личный кабнет недоступен, что активировать лицензию через страницу первого запуска https://<address_mon>/welcome

Шаг 3. Отправить токен в ТП (support@printum.io) вместе с названием и идентификатором организации.

Шаг 4. Полученный новый ключ ввести в поле «Указать лицензионный ключ» → «Сохранить».

Как проверить результат

ЛК открывается без ошибки активации. В карточке организации отображаются типы лицензий и срок действия.

Когда эскалировать

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

Связанные страницы

Проблемы кластера и балансировщика

Задания не распечатываются в отказоустойчивой конфигурации

Симптом

В конфигурации с балансировщиком 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.

Перейдите в директорию клиента ПМ: C:\Program Files\printum\printmanager_client\
Откройте файл settings.yml с правами администратора.
Установите: use_cups_ssl: true

Шаг 3. Проверить NFS-хранилище

Убедитесь, что NFS-хранилище доступно. Недоступность NFS приводит к потере файлов заданий.

Шаг 4. Проверить синхронизацию ПринтМенеджер с Мониторингом

Запустите ручную синхронизацию в личном кабинете: Настройки → Интеграции → ПМ.

Связанные страницы

Проблемы кластера и балансировщика

Файл недоступен при отложенной печати в кластере

Симптом

Пользователь авторизовался на МФУ, но задание недоступно или файл документа отсутствует в очереди.

Причина

Файлы заданий в кластерной конфигурации хранятся на NFS-хранилище. Если NFS недоступен или неправильно смонтирован на одном из серверов ПринтМенеджер — файлы заданий не видны этому серверу.

Диагностика

Шаг 1. Проверить монтирование NFS

# На каждом сервере ПМ:
df -h | grep nfs
mount | grep nfs

Шаг 2. Проверить права доступа к папке NFS

ls -la /scratch
# Ожидаемые права: 777, владелец nobody

Шаг 3. Проверить сетевую доступность NFS-сервера

ping <NFS_ADDR>
# Проверка экспортов NFS:
showmount -e <NFS_ADDR>

Шаг 4. Перемонтировать NFS при необходимости

sudo umount /scratch
sudo mount <NFS_ADDR>:<NFS_FOLDER_PATH> /scratch

Связанные страницы

Задания не распечатываются в отказоустойчивой конфигурации

Проблемы кластера и балансировщика

Как диагностировать проблемы 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

Проверить содержимое файла:

cat /etc/resolv.conf

Необходимо убедиться:

DNS-серверы указаны корректно;
DNS-серверы доступны;
отсутствуют ошибочные записи;
указан корректный search domain (если используется).

Проверка разрешения hostname

Проверить разрешение hostname:

ping monitoring.local

Дополнительно рекомендуется выполнить:

nslookup monitoring.local

Проверить:

hostname успешно резолвится;
IP-адрес соответствует ожидаемому;
отсутствуют timeout;
ответ приходит от корректного DNS-сервера.

Проверка сетевой связности

Проверить доступность серверов:

ping printmanager.local

При использовании отказоустойчивой конфигурации необходимо проверить связность между:

Мониторингом;
всеми узлами ПринтМенеджера;
NFS-сервером;
балансировщиком;
PostgreSQL;
Redis/Sentinel.

Диагностика NFS

Проверка доступности NFS-портов

Проверить доступность NFS:

telnet nfs-server.local 2049

Если используется stunnel:

telnet nfs-server.local 20490

Ожидаемый результат:

TCP-соединение успешно устанавливается;
отсутствуют timeout;
отсутствует ошибка Connection refused.

Проверка mounted volumes

Проверка NFS volume в Docker

Проверить список Docker volumes:

docker volume ls

Найти volume, который используется ПринтМенеджером (printmanager-app).

Проверить параметры volume:

docker volume inspect <volume_name>

Проверить:

volume существует;
указан корректный NFS server;
указан корректный путь NFS export;
параметры подключения соответствуют конфигурации.

Проверка mount внутри контейнера

Зайти в контейнер ПринтМенеджера:

docker exec -it printmanager-app sh

Проверить подключённые файловые системы внутри контейнера:

df -h

Дополнительно проверить доступность каталога:

ls -la <mount_path>

Проверить:

каталог доступен из контейнера;
отсутствуют ошибки Stale file handle;
файловая система не находится в режиме read-only;
файлы создаются и читаются корректно.

Проверка сервисов NFS

На NFS-сервере проверить состояние сервисов:

systemctl status nfs-server.service

Если используется stunnel:

systemctl status stunnel.service

Проверить:

сервисы находятся в состоянии active (running);
отсутствуют restart loop;
отсутствуют ошибки systemd.

Перезапуск сервисов NFS

При необходимости выполнить перезапуск:

systemctl restart nfs-server.service

Если используется stunnel:

systemctl restart stunnel.service

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

доступность портов;
состояние mount;
доступность каталогов;
состояние контейнеров Printum.

Что делать при restart loop контейнеров

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

DNS;
NFS;
сетевую связность;
mounted volumes;
доступность PostgreSQL;
доступность Redis;
корректность hostname;
срок действия SSL-сертификатов.

После устранения проблемы выполнить перезапуск контейнеров:

cd /opt/printmanager
docker-compose down && docker-compose up -d

Дополнительная диагностика Docker

Проверить состояние контейнеров:

docker ps -a

Просмотреть логи контейнера:

cd /opt/printmanager/
docker-compose logs -f --tail=5

Важно помнить

DNS является одной из самых частых причин инфраструктурных отказов.
NFS критически важен для работы отказоустойчивой конфигурации ПринтМенеджера.
Большинство restart loop связано с инфраструктурными зависимостями.
Проверка DNS и NFS должна быть первым этапом диагностики.
В Active-Active конфигурации стабильная работа DNS и NFS обязательна для всех узлов кластера.

Связанные страницы

MissingSchema — неверные адрес или токен ПМ (клиент ПМ Linux)

Симптомы

Виртуальный принтер Printum не появляется на АРМ после установки клиента ПМ.
В логах Пр:

requests.exceptions.MissingSchema: Invalid URL '/direct_printers/': No schema supplied.
Perhaps you meant http:///direct_printers/?

Причина

При установке клиента ПМ переменные адреса ПринтМенеджер или access_token указаны неверно — без схемы (https://), с опечаткой или пустым значением.

Диагностика

Проверить текущие значения в конфигурационном файле:

cat /opt/printum/printmanager_client/settings.yml

Проверить:

server_url содержит полный адрес с протоколом: https://<pm_host>:8080 или http://<pm_host>:8010
access_token не пустой и совпадает с ключом доступа в Личном кабинете → Настройки → Интеграции → ПМ

Решение

Переустановить клиент ПМ с корректными параметрами согласно по инструкции из разделов Удаление клиента ПМ на Linux и Клиент ПМ на Linux — установка и проверка

При установке обязательно указать:

полный адрес ПринтМенеджер с протоколом и портом: https://<адрес_пм>:8080 или http://<pm_host>:8010
актуальный access_token из Личного кабинета → Настройки → Интеграции → ПМ

После установки проверить:

sudo systemctl status printum-printmanager-client.service
sudo tail /var/log/printum/printmanager-client.log -f

Как проверить результат

Виртуальный принтер Printum появился на АРМ. В логах нет MissingSchema. Тестовое задание появляется в очереди ПринтМенеджер.

Когда эскалировать

Параметры указаны корректно, но ошибка сохраняется.
Клиент ПМ не запускается после переустановки.

Связанные страницы

Клиент ПМ на Linux — установка и проверка

Проблемы Клиента ПМ

Принтеры не появляются на рабочей станции

Симптом

После установки клиента ПринтМенеджер принтер 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
Описание сценария и шагов воспроизведения
ОС рабочей станции и сервера

Связанные страницы

Задание не появляется в очереди печати

Проблемы Клиента ПМ

Задание отправлено но не появилось на сервере

Симптом

Пользователь отправил документ на принтер 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 (если регистр логина на АРМ отличается от домена).

Связанные страницы

Проблемы Клиента ПМ

Error 401 — пользователь не найден в ПМ (клиент ПМ Linux)

Симптомы

Задание отправлено на печать, но в очереди ПринтМенеджер не появляется. В логах клиента ПМ:

Job 00233 for Printum failed: 401 Client Error: Unauthorized for url: https://<pm_host>:8080/create_job

или:

ipplib.IppTransportException: Error: 401

Причина

Пользователь, авторизованный в ОС Linux, не существует в ПринтМенеджер, или не прошла синхронизация Мониторинг–ПринтМенеджер после добавления пользователя.

Диагностика

Шаг 1. Проверить, существует ли пользователь в ПринтМенеджер:

В панели администратора ПринтМенеджер → Сотрудники: найти пользователя по имени учётной записи Linux → в его карточке проверить наличие Учётной записи с указанным логином и uid.

Шаг 2. Проверить синхронизацию:

Если пользователь есть в Мониторинге, но нет в ПринтМенеджер — не прошла синхронизация Мониторинг–ПринтМенеджер.

Шаг 3. Проверить Ключ доступа ПринтМенеджера:

cat /opt/printum/printmanager_client/settings.yml | grep access_token

Токен должен совпадать с ключом доступа ПринтМенеджера, к которому подключён клиент.

Решение

Если пользователя нет в ПринтМенеджер:

Убедиться, что пользователь существует в Мониторинге.
Запустить синхронизацию домена в Личный кабинет → Настройки → Интеграции → Домены. <svg data-v-35ec99d5="" width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
Запустить синхронизацию Мониторинг–ПринтМенеджер: панель администратора М → ПринтМенеджеры → «Синхронизировать». <svg data-v-35ec99d5="" width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
Проверить, появился ли пользователь в панели ПринтМенеджер.

Если access_token неверный:

Обновить токен в settings.yml:

sudo nano /opt/printum/printmanager_client/settings.yml
# Указать актуальный access_token из Личного кабинета → Настройки → Интеграции → ПМ

sudo systemctl restart printum-printmanager-client.service

Как проверить результат

Отправить тестовое задание от пользователя. Задание появляется в очереди ПринтМенеджер. В логах нет 401.

Когда эскалировать

Пользователь есть в ПринтМенеджер, токен верный, но ошибка 401 сохраняется.
Синхронизация завершается с ошибкой.

Приложить к заявке: логи клиента ПМ, версию ПринтМенеджер, имя пользователя (без персональных данных), конфигурационный файл CUPS на АРМ.

Связанные страницы

Ошибка проверки SSL-сертификата: Hostname mismatch

Симптом

В логах ПринтМенеджера или при установке появляется ошибка:

[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;
в кластерной конфигурации или филиальной сети один сертификат используется для нескольких серверов.

Диагностика

Проверьте, для какого адреса выпущен сертификат:

openssl s_client -connect <адрес_сервера>:<порт> </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

Сравните результат с адресом, по которому компонент обращается к серверу.

Если Мониторинг и ПринтМенеджер установлены на разных серверах:

grep MONITORING_ADDRESS /opt/printmanager/.env

Если Мониторинг и ПринтМенеджер установлены на одном сервере — проверьте значение EXT_HOSTNAME в панели администратора ПринтМенеджера.

Решение

Автоматические сертификаты

Переустановка без SSL-параметров пересоздаёт сертификаты автоматически под текущий адрес:

# М
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 должны содержать адрес, по которому компонент обращается к серверу. Затем обновить с новыми файлами:

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).

Связанные страницы

Проблемы интеграций

Синхронизация Мониторинга и ПринтМенеджера не выполняется

Симптом

Изменения, сделанные в Мониторинге, не применяются на ПринтМенеджерах (пользователи, правила, принтеры не синхронизируются).

Как работает синхронизация

Мониторинг — центральный сервер, ПринтМенеджеры работают в подчинённом режиме. По умолчанию синхронизация выполняется 1 раз в час. Изменения вступают в силу не мгновенно.

Диагностика

Шаг 1. Проверить доступность ПринтМенеджера с Мониторингом

Порты между Мониторингом и ПринтМенеджер должны быть открыты (8000, 8010, 8080).
Сертификаты должны быть актуальны с обеих сторон.

Шаг 2. Запустить синхронизацию вручную

Нажмите «Синхронизировать» в карточке нужного ПринтМенеджера или иконку синхронизации в таблице.

Шаг 3. Проверить Docker-контейнеры

cd /opt/printum && sudo docker-compose ps
cd /opt/printmanager && sudo docker-compose ps

Все контейнеры должны быть в статусе Up.

Связанные страницы

Расписание синхронизации с доменом

Проблемы интеграций

Ошибка подключения к почтовому серверу

Симптом

Уведомления не приходят по почте, тестовое письмо не отправляется, пользователи не могут восстановить пароль.

Диагностика

Шаг 1. Отправить тестовое письмо

Перейдите в Настройки → Интеграции → Почта. Введите адрес в поле «Почта для тестового письма» и нажмите «Отправить тестовое письмо».

Шаг 2. Проверить параметры подключения

Параметр	Что проверить
SMTP-сервер	Адрес доступен с сервера Мониторинга
Порт	Порт открыт в firewall (25, 465, 587)
Логин/Пароль	Учётные данные корректны
Адрес отправителя	Должен совпадать с логином (требование большинства SMTP-серверов)
TLS/SSL	Соответствует конфигурации сервера

Что проверить перед эскалацией

Тестовое письмо успешно отправлено
Порт SMTP открыт
Логин и пароль корректны

Связанные страницы

Настройка подключения к почтовому серверу

Проблемы интеграций

Лицензия истекла — что происходит и что делать

Симптомы

Система отправила уведомление: «Срок действия лицензии истекает» или «Срок действия лицензии истёк».
В ЛК отображается предупреждение об истечении лицензии.
Часть функционала может быть ограничена.

Что происходит при истечении лицензии

Годовые лицензии: после истечения срока ПО перестаёт функционировать. Необходимо срочное продление.

Бессрочные лицензии: включают 1 год гарантийной технической поддержки. После истечения поддержки система продолжает работать, но обновления и обращения в ТП становятся недоступны. Для восстановления поддержки — приобрести продление.

Примечание: Уведомления об истечении отправляются заблаговременно — реагировать нужно до истечения, а не после.

Что делать

Продлить лицензию по стандартной процедуре. Обратится на sales@printum.io

Важно про перерыв в продлении

Если продление оформлено с перерывом, новый срок технической поддержки исчисляется с момента окончания предыдущего периода — а не с даты оформления. То есть перерыв не «сдвигает» начало нового периода.

Как проверить результат

ЛК → Настройки → Общие → Организации: в списке лицензий отображается обновлённый срок действия.

Когда эскалировать

Система полностью недоступна. Войти в ЛК невозможно.
Новый ключ введён, но срок не обновился.
Новый ключ введён, срок действия обновился, но опрос устройств не происходит более установленного времени сканирования сети и печать на устройствах не осуществляется.

Обратиться напрямую: support@printum.io — указать название организации и идентификатор, а так же описать какие действия уже были проделаны.

Связанные страницы

Как активировать или продлить лицензию

Ошибка проверки SSL-сертификата: self signed certificate in certificate chain

Симптом

В логах ПринтМенеджера появляется ошибка:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed:
self signed certificate in certificate chain

Синхронизация Мониторинга и ПринтМенеджера не выполняется.

Причина

В файл серверного сертификата включён корневой сертификат удостоверяющего центра.

Корневой сертификат должен храниться отдельным файлом и передаваться как SSL_CERT_CA.

Диагностика

Проверить, сколько сертификатов содержится в файле server.crt:

grep -c "BEGIN CERTIFICATE" /path/to/server.crt

Норма: 1 (серверный сертификат) или 2 (серверный + промежуточный CA). Ошибка: 3 и более — скорее всего, включён корневой сертификат.

Решение

Разделить сертификаты:

server.crt — только серверный сертификат (и промежуточный CA, если есть).
ca.crt — только корневой сертификат.

Переустановить с корректно разделёнными файлами:

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

Связанные страницы

Требования к сертификатам безопасности

Ошибка проверки SSL-сертификата: unable to get local issuer certificate

Симптом

В логах компонентов появляется ошибка:

[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-сертификата в цепочке нет - возникнет ошибке проверки сертификата сервера.

Решением является перевыпуск сертификата с корректной цепочкой сертификации (наличие данных о центре сертификации).

После перевыпуска, нужно внедрить сертификаты методом обновления Мониторинга и\или ПринтМенеджера.

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

sudo -E SSL_CERT=/path/server.crt SSL_KEY=/path/server.key SSL_CERT_CA=/path/ca.crt ./install.sh

Связанные страницы

Требования к сертификатам безопасности

BrokenPipeError — задания не передаются из CUPS в ПМ (Linux)

Симптомы

Пользователь отправил задание на печать — в CUPS на АРМ статус Job completed.
В очереди ПринтМенеджер и на МФУ задания нет.
Служба клиента ПМ запущена active (running).
В логах клиента ПМ:

BrokenPipeError: [Errno 32] Broken pipe

Причина

Клиент ПМ считывает задание из CUPS, но соединение обрывается до того, как задание передано в ПринтМенеджер. Типичные причины:

Несовместимость ОС — после обновления Astra Linux (например, 1.7.7 → 1.7.9) изменилась версия Python или системных библиотек, с которыми работает клиент.
Конфликт с CUPS — на АРМ установлен конкурирующий сервис печати (PrintXpert, SafeQ и др.).
Ошибка конфигурации CUPS — в CUPS на АРМ присутствуют параметры, запрещающие отправку заданий или добавление принтеров.

Диагностика

Шаг 1. Проверить логи клиента ПМ:

sudo cat /var/log/printum/printmanager-client | grep -i "broken\|error\|pipe"

Зафиксировать полный текст ошибки — строки до и после BrokenPipeError.

Шаг 2. Проверить версию ОС:

cat /etc/os-release

Шаг 3. Проверить наличие конкурирующих сервисов печати:

systemctl list-units | grep -i "print\|cups\|spool"

Если есть активные сервисы кроме cupsd и printum-printmanager-client — вероятен конфликт.

Шаг 4. Проверить доступность CUPS:

lpstat -r

Норма: scheduler is running.

Решение

Переустановка клиента ПМ (первый шаг)

Переустановка не меняет настройки — settings.yml сохраняется.

Шаг 1. Остановить службу

sudo systemctl stop printum-printmanager-client.service

Шаг 2. Переустановить по инструкции из разделов Удаление клиента ПМ на Linux и Клиент ПМ на Linux — установка и проверка
Шаг 3. Проверить статус после установки

sudo systemctl status printum-printmanager-client.service

Конфликт с другим ПО управления печатью

Деактивировать конкурирующий сервис:

sudo systemctl stop <имя_сервиса>
sudo systemctl disable <имя_сервиса>

После этого перезапустить клиент ПМ и проверить передачу заданий.

После обновления ОС

Переустановка клиента ПМ с актуальным дистрибутивом решает проблему несовместимости. Если не помогло — эскалировать в ТП с логами и версией ОС.

Как проверить результат

sudo tail /var/log/printum/printmanager-client.log -f

Ошибок BrokenPipeError нет. Отправить тестовое задание — оно должно появиться в очереди ПринтМенеджер.

Когда эскалировать

Переустановка не помогла.
ОС обновлялась перед появлением проблемы.
Конкурирующих сервисов нет, но ошибка сохраняется.

Приложить к заявке: файл логов Клиента ПМ с ошибкой, версию ОС (cat /etc/os-release), версию клиента ПМ, версию ПринтМенеджер.

Связанные страницы

Встроенное приложение — диагностика проблем

Как устанавливается приложение

Автоматическая установка из Личного кабинета (кнопка «Установить приложение»):

Xerox, Konica Minolta, HP, Sharp, Ricoh

Ручная установка через интерфейс МФУ с токеном:

Kyocera, Lexmark, Pantum, Fplus, Lexmark, Avision

Настройка не требующая установки пакета приложений:

Brother, Epson

Для получения инструкций по конкретному вендору и модели необходимо направить запрос в Техническую поддержку: support@printum.io

Предусловия для работы приложения

Перед диагностикой убедиться, что выполнены все условия:

Устройство добавлено в Мониторинг и опрашивается (статус не серый).
У устройства есть лицензия M (мониторинг) + PM (управление печатью).
Существует свободный слот лицензии EMB (встроенное приложение)
Синхронизация Мониторинг–ПринтМенеджер выполнена (Личный кабинет → Настройки → Интеграции → ПринтМенеджер).
МФУ доступен по сети с сервера ПринтМенеджера (проверить ping <ip_мфу> с сервера).
Версия прошивки МФУ соответствует требованиям (запросить у ТП список совместимых прошивок).

Алгоритм диагностики

Шаг 1. Проверить лицензии

ЛК → Управление → Устройства → развернуть карточку → вкладка «Лицензии».

Должны быть активны: M, PM, EMB. Если EMB отсутствует — нажать «Установить приложение» или «Сгенерировать токен».

Шаг 2. Проверить синхронизацию

Если приложение установлено, но настройки (пользователи, правила, PIN-коды) не применяются — запустить синхронизацию Мониторинг–ПринтМенеджер вручную.

Шаг 3. Проверить логи ПринтМенеджер

Запустить логирование в интерактивном режиме

cd /opt/printmanager
sudo docker-compose logs -f --tail=100

Выполнить запрос из встроенного приложения, например: авторизоваться.
В логах проверить наличие запросов в контейнере printmanager-web_1

Шаг 4. Проверить доступность ПринтМенеджер с устройства

МФУ должен иметь сетевой доступ к серверу ПринтМенеджер. Проверить с сервера ПринтМенеджер:

ping <ip_мфу>
curl -k http://<ip_мфу>/

Если МФУ недоступен с сервера ПринтМенеджера — сетевая проблема, решается на стороне заказчика.

Шаг 5. Переустановить приложение

Если предыдущие шаги не дали результата:

В ЛК → Управление → Устройства → «Удалить приложение» (или «Удалить токен»).
Перезагрузить МФУ.
Установить заново.

Навигация по конкретным проблемам

Симптом	Статья
Приложение не устанавливается, ошибка при установке	Встроенное приложение не устанавливается
Белый экран или приложение не открывается	Белый экран во встроенном приложении
Пользователь авторизовался, но заданий нет	Задания не отображаются в приложении
Авторизация по карте не работает	Авторизация по карте не работает во встроенном приложении
Ricoh: приложение постоянно запрашивает токен	Ricoh — постоянный запрос токена
Xerox: сканирование/копирование не работает без ошибок	Xerox — сканирование не работает, ошибок нет

Что приложить при эскалации в ТП

Вендор и модель МФУ, версия прошивки.
Версия приложения (есть в интерфейсе МФУ).
Версии Мониторинга и ПринтМенеджера.
Логи системы Printum.
Описание симптома: что именно происходит на экране МФУ.

Контейнеры Unhealthy после обновления в конфигурации с балансировщиком

Симптомы

После обновления ПринтМенеджер в схеме с балансировщиком:

Один или несколько контейнеров printmanager-app запускаются со статусом unhealthy.
Нода недоступна через HAProxy (статус DOWN в панели HAProxy).
Печать работает частично или не работает совсем.

Причины

Три наиболее частые:

NFS не смонтирован — volume printmanager_media недоступен, контейнер не может запуститься.
Redis потерял master — после одновременного перезапуска нод Redis sentinel не успел выбрать нового мастера.
Ошибка прав в printmanager-ftpd — контейнер завершился с ошибкой при записи PID-файла.

Диагностика

Шаг 1. Проверить статус всех контейнеров на проблемной ноде:

cd /opt/printmanager
sudo docker-compose ps

Зафиксировать какие контейнеры в статусе unhealthy или Exit.

Шаг 2. Проверить монтирование NFS:

Проверьте, что NFS хранилище работает корректно на каждом сервере с ПринтМенеджерами:

Создайте файл test.txt таким образом:

cd /opt/printmanager
sudo docker-compose exec app touch /opt/app/public/media/test.txt

Проверьте, что файл появился в NFS хранилище.
Удалите этот файл таким образом

cd /opt/printmanager/
sudo docker-compose exec app rm /opt/app/public/media/test.txt

Убедитесь, что файл test.txt был удален из NFS хранилища.

Шаг 3. Проверить логи printmanager-app:

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:

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:

cd /opt/printmanager/
sudo docker-compose logs ftpd --tail=50

Признак проблемы ftpd:

Permission denied при записи PID

Решение

NFS не смонтирован

Проверить, запущен ли stunnel (если NFS проброшен через stunnel):

systemctl status stunnel

Если stunnel не запущен:

systemctl start stunnel

После этого перезапустить ПринтМенеджер:

cd /opt/printmanager/
sudo docker-compose down && sudo docker-compose up -d

Redis не выбрал мастера

Подождать 1–6 минут — sentinel должен автоматически выбрать нового мастера. Если не восстановился:

cd /opt/printmanager/
sudo docker-compose down && sudo docker-compose up -d

Проверить логи через 1 минуту:

sudo docker-compose logs redis-sentinel --tail=30

Норма:

# Sentinel ID is <id>
# +monitor master redis <ip-address> 6379 quorum 2
* +slave slave <ip-address>:6379 <ip-address> 6379 @ redis <ip-address> 6379
* +sentinel sentinel <id> <ip-address> 26379 @ redis <ip-address> 6379

Ошибка прав в printmanager-ftpd

cd /opt/printmanager/
sudo docker-compose down && sudo docker-compose up -d

Если ошибка повторяется — передать логи в ТП.

Как проверить результат

sudo docker-compose ps

Все контейнеры в статусе Up. В панели HAProxy нода отображается как UP. Тестовое задание успешно печатается.

Когда эскалировать

Причина не определяется по логам.
NFS недоступен по сетевым причинам (не связано с stunnel).
Redis не восстанавливается после перезапуска.
Проблема воспроизводится на всех нодах одновременно.

Приложить к заявке: вывод docker-compose ps со всех нод, логи всех нод ПринтМенеджера, версии М и ПринтМенеджер.

Связанные страницы

Ошибка «Provided license key instead of activation key»

Симптомы

При попытке активировать лицензию в Личный кабинет → Настройки → Общие → Организации система или в Личный кабинет → Первый запуск → Активация лицензии показывает ошибку:

Provided license key instead of activation key

Или в письме от Технической поддержки приходит лицензионнвй ключ, но при вводе система его не принимает.

Причина

Перепутаны два разных значения:

Токен активации — генерируется в Личном кабинете, отправляется в ТП. Выглядит как строка UUID.
Лицензионный ключ — выдаётся ТП в ответ на токен. Вводится в поле «Указать лицензионный ключ». Выклядит как длинная строка Base64/JWT.

Ошибка возникает когда в поле лицензионного ключа вводится токен активации (или наоборот), либо когда вводится токен активации из другой системы или организации.

Решение

Шаг 1. В Личный кабинет → Настройки → Общие → Организации нажать «Токен активации» и скопировать актуальный токен именно этой системы.

Шаг 2. Отправить этот токен в Техническую поддержку (support@printum.io) с названием организации.

Шаг 3. Полученный от Технической поддержки ключ ввести в поле «Указать лицензионный ключ» → «Сохранить».

Как проверить результат

В списке лицензий карточки организации отображаются типы лицензий, количество и срок действия.

Когда эскалировать

Ключ введён корректно (получен от ТП в ответ на токен этой системы), но ошибка сохраняется.
Система не позволяет открыть раздел «Организации».

Связанные страницы

Как активировать или продлить лицензию

Синхронизация М–ПМ завершается ошибкой 403 после обновления

Симптомы

В различных системных отчетах ПринтМенеджера https://<address_pm>:8080/config/web/reports после обновления:

Bad response from monitoring 403 with error: <Response [403]>

Принтеры не синхронизируются из Мониторинга в ПринтМенеджер. Задания на МФУ не приходят.

Причина

После обновления Мониторинга или ПринтМенеджер значение MONITORING_KEY перестало совпадать между компонентами. Это происходит если при обновлении ключ был пересоздан или не перенесён корректно.

Решение

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

Как проверить результат

Синхронизация завершается без ошибок. В различных системных отчетах ПринМенеджера нет 403. Принтеры из Мониторинга появились в панели ПринтМенеджера.

Когда эскалировать

Ключи совпадают, но ошибка 403 сохраняется.
Нет доступа к панели администратора ПринтМенеджер.

Приложить к заявке: версии Мониторинга и ПринтМенеджер и логи обоих системы.

Связанные страницы

Счётчики не обновляются после обновления Мониторинга

Симптомы

После обновления Мониторинга счётчики принтеров заморожены на дате обновления.
В Личном Кабинете → "Отчёты по устройствам" - дата последнего опроса не меняется.
Агент мониторинга работает, ошибок в админке Мониторинга нет.

Причина

Две наиболее частые:

Агент не перезапустился корректно после обновления — продолжает работать старая версия или агент завис.
Ошибка чтения данных в ClickHouse — при крупном обновлении (например, 4.1 → 4.3) формат хранения данных изменился, агент получает ошибку при записи или чтении.

Диагностика

Проверить статус контейнера агента:

sudo systemctl status printum-agent.service

Проверить логи агента в интерактивном режиме:

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):

cd /opt/printum/
sudo docker-compose logs -f --tail=5 worker-low

Признак проблемы 2 (ClickHouse):

[<date_time>: ERROR/ForkPoolWorker-26] Task apps.printer.tasks.periodic_update_register_of_printers_in_snmp[<UUID>] raised unexpected: ServerException('DB::Exception: Unknown codec family code: 0...

Решение

Агент не перезапустился

sudo systemctl restart printum-agent.service

Подождать 2–3 минуты, проверить счётчики в ЛК.

Ошибка ClickHouse

Не устраняется самостоятельно. Требует вмешательства на уровне БД.

Передать в ТП:

Логи агента системы Мониторинга.
Версию Мониторинга до и после обновления.
Вывод sudo docker-compose ps.

Как проверить результат

В ЛК → Отчёты по устройствам: дата последнего опроса обновилась.
Отправить тестовое задание на печать — счётчик вырос.

Когда эскалировать

В логах ошибка ClickHouse (Unknown codec family code или ServerException).
Агент запускается, но данные не поступают более 30 минут.

Связанные страницы

Файл сканирования не приходит на email

Симптомы

Пользователь выполнил сканирование на email во встроенном приложении — операция завершилась без ошибок на экране МФУ.
Письмо со сканом не пришло.
Кнопка «Сканировать на e-mail» в приложении неактивна.

Диагностика

Шаг 1. Проверить SMTP-настройки ПринтМенеджера

Перейдите в панель администратора ПринтМенеджера → Constance → Настройки → Настройки электронной почты (https://<ip_pm>: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://<ip_pm>: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).

Связанные страницы

Ошибка удаления сети Docker при обновлении Мониторинга

Симптом

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

error while removing network: network printum_default id <...> has active endpoints

Причина

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

Решение

Перезагрузите сервер и повторите обновление.

Файл сканирования не приходит в сетевую папку

Симптомы

Пользователь выполнил сканирование в папку — операция завершилась без ошибок на МФУ.
Файл в сетевой папке не появился.
Кнопка «Сканировать в папку» в приложении неактивна.

Диагностика

Шаг 1. Проверить SMB-настройки в ПринтМенеджере

Перейдите в панель администратора ПринтМенеджера → https://<ip_pm>: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://<ip_pm>:8080/config/constance/config/ → раздел «Настройки сканирования»).

Как проверить результат

Выполнить сканирование в папку тестового пользователя. Файл появляется в указанной сетевой папке в течение 1-2 минут.

Когда эскалировать

SMB-настройки верные, путь заполнен, права есть — файл не появляется.
В логах ошибки, не связанные с правами или доменным именем сервера SMB-папки.

Приложить: логи системы Printum (bash /opt/printmanager/logs.sh), настройки SMB (без пароля), путь к папке пользователя, версии Мониторинга и ПринтМенеджера (cat /opt/printum/.version и cat /opt/printmanager/.version).

Связанные страницы

Сканирование — диагностика проблем

Не находится принтер или МФУ

Симптом

Принтер или МФУ не появляются в личном кабинете в разделе Управление → Устройства и Отчеты → По устройствам.

Что проверить

1. Настройки локации

Проверьте, что IP-адрес устройства:

указан явно в настройках локации;
либо входит в диапазон IP-адресов, указанный в настройках локации.

2. Настройки сетевого агента

Проверьте, что локация назначена сетевому агенту.

Для этого перейдите:

Настройки → Интеграции → Сетевые агенты

Локация с устройствами должна:

быть отмечена чек-боксом у агента;
либо входить в другую локацию, назначенную агенту.

3. Доступность устройства

Проверьте, что устройство доступно по сети. На компьютере, находящемся в одной сети с устройством:

Откройте браузер.
Введите IP-адрес устройства.

Если веб-интерфейс устройства открывается, переходите к следующему шагу.

4. Работа SNMP

Убедитесь, что на устройстве включена передача данных по протоколу SNMP. Проверьте ответ устройства командой:

snmpwalk -v 2c -c public <ip-адрес>

или

snmpwalk -v 1 -c public <ip-адрес>

Если устройство не отвечает:

проверьте настройки SNMP на устройстве;
убедитесь, что используется правильная community string;
включите поддержку SNMP, если она отключена.

5. Идентификация устройства

Если:

IP-адрес указан корректно;
устройство доступно по сети;
SNMP работает;

но устройство по-прежнему не определяется корректно, возможно требуется дополнительная настройка параметров SNMP для данной модели устройства.

Проверьте ошибки идентификации:

Перейдите в раздел Инвентаризация → Устройства панели администратора Мониторинга.

Найдите устройство по IP-адресу и посмотрите содержимое столбца Ошибки идентификации.

При обращении в техническую поддержку обязательно приложите эти данные.

Белый экран или приложение не открывается на МФУ

Симптомы

После нажатия иконки приложения на панели МФУ — белый экран или пустой экран без интерфейса.
Приложение открывается, но экран авторизации не появляется.
После ввода PIN-кода — белый экран вместо списка заданий.

Причины и решения

МФУ не может подключиться к серверу ПринтМенеджер

Белый экран — наиболее частый признак того, что приложение не получает ответ от ПринтМенеджера.

Проверить сетевой доступ МФУ к ПринтМенеджеру:

МФУ должен иметь доступ к серверу ПринтМенеджер по порту 8080 (или 1631 для CUPS) - если есть функция на МФУ.
Если функции icmp нет на МФУ, то проверить с рабочего места в той же подсети: curl -k https://<ip_пм>:8080/.
Проверить статус контейнеров ПринтМенеджер:
```
cd /opt/printmanager
sudo docker-compose ps
```
Все контейнеры должны быть Up.
Проверить доступность административной панели ПринтМенеджера: https://<ip_пм>:8080/config

Несовместимая версия прошивки

На некоторых моделях (особенно Pantum) после обновления прошивки приложение перестаёт открываться. Или, наоборот, устаревшая прошивка несовместима с текущей версией приложения.

Решение: запросить у ТП информацию о поддерживаемой и совместимой версии прошивки для конкретной модели. Пригласить сервисного инженера для прошивки.

Приложение не переустановлено после смены прошивки

После обновления прошивки МФУ встроенное приложение необходимо переустановить.

Решение:

Личный кабинет → Управление → Устройства → МФУ → «Удалить приложение».
Перезагрузить МФУ.
Установить приложение заново.

Конфликт со сторонним ПО на МФУ

Белый экран при авторизации по PIN-коду может быть вызван сторонними приложениями, установленными на МФУ (например, Device Software Manager).

Решение:

Открыть веб-интерфейс МФУ → раздел установленных приложений.
Удалить сторонние приложения, не связанные с Printum.
Перезагрузить МФУ.

Как проверить результат

После перезагрузки МФУ открыть приложение — экран авторизации отображается корректно. Авторизация по PIN или карте выполняется успешно.

Когда эскалировать

МФУ доступен по сети, контейнеры ПринтМенеджер работают, прошивка совместимая — белый экран сохраняется.
Проблема воспроизводится только на одной модели МФУ.

Приложить к заявке: вендор, модель, версия прошивки, версии М и ПринтМенеджер, версия приложения, логи системы Printum.

Связанные страницы

Печать дополнительной технической страницы при бесклиентской печати

Симптом

При использовании бесклиентской печати вместе с документом печатается дополнительная страница с технической информацией.

Проблема может наблюдаться на устройствах:

Konica Minolta;
Kyocera.

Решение

Используйте драйвер HP Universal Printing PS.

Скачайте драйвер HP Universal Printing PS с официального сайта HP.
Удалите существующий принтер. Для этого перейдите в раздел Параметры Windows → Принтеры и сканеры, выберите принтер, используемый для бесклиентской печати, и нажмите Удалить устройство.
Выполните повторную установку принтера, используя скачанный драйвер.При выборе драйвера из файлов архива укажите файл "hpbuio200l.inf".
Проверьте печать. Отправьте тестовое задание на печать и убедитесь, что дополнительная техническая страница больше не печатается.

Документ копируется с обрезанными краями

Симптом

При копировании часть изображения или документа обрезается по краям листа.

Причина

Большинство принтеров и МФУ имеют непечатаемые области по краям листа. Поэтому при печати документ может выводиться без масштабирования и часть содержимого, попадающая в непечатаемую область, будет обрезана.

Решение

Включите автоматическое масштабирование документа под размер листа.

Для этого:

Откройте панель администратора ПринтМенеджера.
Перейдите в раздел Настройки.
Откройте подраздел Настройки печати.
Включите параметр:

FIT_TO_PAGE

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

Команда docker-compose up -d завершается ошибкой

Симптом

При запуске контейнеров появляется ошибка:

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 не успевает выполнить запуск контейнеров за отведённое время и завершает операцию по таймауту.

Решение

Увеличьте таймаут ожидания запуска контейнеров. Вместо стандартной команды:

docker-compose up -d

используйте:

COMPOSE_HTTP_TIMEOUT=300 docker-compose up -d

Значение 300 задаёт таймаут ожидания в секундах.

На устройстве Xerox не работает сканирование или копирование без отображения ошибки

Симптом

На устройстве Xerox не выполняется сканирование или копирование.

При этом:

процесс запускается;
явных сообщений об ошибках на экране нет;
документ не сканируется или операция не завершается.

Причина

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

выбран формат оригинала Автоопределение;
на стекле сканера отсутствует документ;
устройство не может определить размер документа по другим причинам.

Проверка

Во время выполнения операции обратите внимание на информационные сообщения и статусы, отображаемые на устройстве.

Если среди сообщений присутствует статус:

InputScanSizeNotDetermined

значит устройство не смогло определить формат оригинала.

Решение

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

Проблемы со сканированием больших файлов на Konica Minolta и Kyocera

Симптом

На некоторых моделях Konica Minolta и Kyocera могут возникать проблемы при сканировании больших файлов. Проблема чаще проявляется при высоких настройках качества сканирования, например при разрешении 600 DPI и выше.

Причина

При сканировании больших файлов устройство может испытывать сложности с передачей файла сканирования в ПринтМенеджер по текущему протоколу. В этом случае необходимо изменить протокол передачи файлов сканирования.

Решение

Измените протокол передачи файлов сканирования на FTP.

Откройте настройки ПринтМенеджера. Перейдите в панель администратора ПринтМенеджера:

https://<адрес_принтменеджера>:8080/config/constance/config/

Откройте настройки приложения для Konica Minolta. Перейдите в раздел Настройка приложения для принтеров KONICA MINOLTA.
Измените протокол передачи. В поле KONICA_TRANSFER_PROTOCOL укажите значение FTP.
Сохраните изменения и повторите сканирование большого файла.

Типовые ошибки Клиента ПМ

Назначение

Данная статья содержит наиболее распространённые ошибки Клиента ПМ и рекомендации по их устранению.

Ошибка	Причина	Решение
`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`.

Статус "Ошибка - печать" при бесклиентской печати

Симптом

При отправке заданий на бесклиентскую печать в очереди печати отображается состояние:

Ошибка – печать

Причина

Из-за групповых политик принтер может использовать порт типа TCP/IP.

Проверка

Откройте Свойства принтера.
Перейдите на вкладку Порты.
Проверьте, какой порт используется принтером.

Для бесклиентской печати должен быть отмечен порт с описанием:

Интернет порт

Если вместо этого отмечен порт с описанием:

Стандартный порт TCP/IP

выполните действия ниже.

Решение

Отметьте бесклиентский принтер и нажмите Удалить устройство.
Перезагрузите компьютер.
Откройте командную строку от имени администратора.
Откройте окно управления печатью с помощью команды:

printui /s /t2

В открывшемся окне перейдите на вкладку Порты.
Найдите TCP/IP-порт и нажмите Удалить порт.
Перезагрузите АРМ.
Заново добавьте принтер.

При отложенной печати появляется ошибка «Файл недоступен»

Симптом

При попытке распечатать документ из очереди отложенной печати появляется сообщение:

Файл недоступен

Причина

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

Проверка

На каждом сервере ПринтМенеджера выполните команду:

sudo cat /opt/printmanager/.env

Убедитесь, что указаны следующие параметры:

DRIVER_OPTS_DEVICE=":NFS_FOLDER_PATH"

где NFS_FOLDER_PATH — путь к директории на NFS-сервере.

DRIVER_OPTS_O="addr=NFS_ADDR,nolock,soft,rw"

где NFS_ADDR — IP-адрес или доменное имя NFS-сервера.

DRIVER_OPTS_TYPE="nfs"

Если вместо этого указаны настройки:

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 появляется ошибка:

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».