Как найти ошибку прав на почтовом сервере Linux

Если почтовая служба не может открыть ящик или записать сообщение, сначала проверьте точный путь хранения, владельца и права на каждом каталоге пути. Я покажу безопасный порядок диагностики для Linux-сервера с Postfix и Dovecot: от журнала и конфигурации до точечного исправления и проверки доставки.

С чего начать, если почта перестала принимать сообщения

Возьмём условный пример с сетью «Еврострой-Логистик»: после неудачной правки каталогов доставка остановилась, а в журнале появились отказы при доступе к почтовым данным. Это модель ситуации, а не опубликованный разбор реального клиента. Я не приписываю системе конкретную причину, пока не вижу её журнал и конфигурацию. Один и тот же симптом бывает при неверном владельце, закрытом для прохода родительском каталоге, заполненном диске, ошибке монтирования или сбое базы авторизации.

Сначала фиксирую время сбоя и его масштаб: не принимается входящая почта, не отправляется исходящая, не открываются ящики по IMAP или процесс вообще не запускается. Затем сохраняю нужные журналы и состояние до исправлений. Если установлен systemd, журнал службы можно посмотреть командой journalctl -u postfix --since today; для Dovecot подставляю соответствующее имя unit. Имена служб отличаются между системами, контейнерами и сборками. Для обслуживания корпоративной почты важны и журналы, и реальная схема запуска. Если unit не найден, смотрю список служб и способ запуска, а не выдумываю ему имя.

Если журнал пишет в обычные файлы, ищу системный путь для конкретного дистрибутива: встречаются /var/log/mail.log и /var/log/maillog, но ни один не обязателен везде. Важна запись процесса в момент ошибки: отказ в доступе к конкретному пути, ошибка чтения конфигурации или невозможность открыть сокет — разные задачи. Сообщение Permission denied подсказывает направление проверки, но само по себе не доказывает, что виноваты права на почтовый ящик. Сначала сохраняю точный путь и имя процесса из записи.

Я также проверяю, совпадает ли время ошибки с остановкой доставки и есть ли сообщения о диске, файловой системе или очереди. Если файловая система смонтирована только для чтения либо закончились свободные блоки и inode, chmod ничего не исправит. Перезапуски до сбора диагностических данных могут перетасовать журнал и добавить шум. Короткая пауза на фиксацию симптомов обычно экономит больше времени, чем немедленный ритуальный restart.

• Зафиксировать время и симптом сбоя
• Сохранить точный текст ошибки и путь
• Проверить состояние службы и файловой системы

Как определить настоящий путь почтового ящика

Не начинайте с предположения, что почта обязательно лежит в /var/vmail. Dovecot хранит почтовые данные там, куда указывает конфигурация конкретной установки и результат userdb. В старых конфигурациях 2.3 часто встречается mail_location; в ветке 2.4 настройки хранения разделены на mail_driver и mail_path. Поэтому пример из чужой инструкции может быть синтаксически правильным для другой версии и бесполезным для вашей; различия разобраны в статье о переходе Dovecot 2.4. Сначала выясните версию и эффективные настройки, затем сопоставляйте их с фактическим путём.

Я читаю конфигурацию Dovecot штатными средствами установленной версии, проверяю записи userdb и нахожу домашний каталог пользователя, которому соответствует проблемный ящик. В контейнерной установке путь внутри контейнера и путь на хосте могут различаться из-за volume mount. В управляемой сборке собственные скрипты и панель могут формировать конфигурацию автоматически; ручная правка снаружи способна исчезнуть при обновлении. Это не мелочь: исправить права на похожий каталог легко, а попасть в нужный — уже отдельная работа.

После определения пути проверяю не только последний каталог, но и каждую родительскую директорию. Для прохода к файлу процессу нужны права поиска на компонентах пути; право записи на самом Maildir не поможет, если процессу недоступен каталог выше. Команды namei -l /путь/к/ящику и stat /путь/к/ящику помогают увидеть цепочку и атрибуты. Подставляйте свой путь, полученный из конфигурации, а не копируйте пример буквально. Не публикуйте вывод с именами пользователей и внутренней структурой каталогов.

В базе знаний есть конкретная полезная деталь: Maildir хранит сообщения отдельными файлами в структуре каталогов, а Dovecot позволяет задавать местоположение данных настройкой хранения. Это помогает понять, почему ошибка может касаться не только корня ящика, но и его подкаталога или файла. При этом формат Maildir сам по себе не назначает владельца vmail и не устанавливает универсальную маску. Отдельно полезно проверить контрольные файлы Dovecot, если отказ касается индексов или служебных данных. Такие значения задаёт конфигурация и схема запуска сервера.

• Уточнить версию Dovecot и формат хранения
• Проверить mail_location либо mail_path и userdb
• Сверить путь в контейнере и на хосте, если применимо

Как проверить владельца и права без догадок

Получив точный путь из конфигурации, сравните владельца и группу проблемного каталога с тем, под кем конкретный процесс обращается к данным. В одной установке ящики обслуживает отдельная учётная запись vmail, в другой используются иные UID/GID, ACL или контейнерные отображения пользователей. Название vmail — распространённая схема, но не стандарт, который можно назначить вслепую. Источник истины — userdb, конфигурация Dovecot, параметры службы и фактические UID/GID процесса.

Для первичного осмотра подойдут ls -ld /путь/к/ящику, stat /путь/к/ящику и namei -l /путь/к/ящику. Если на файловой системе включены ACL, дополнительно проверьте getfacl для нужных компонентов пути; обычный вывод ls -l не показывает всей картины. Если данные находятся на NFS или другом сетевом хранилище, учитывайте отображение идентификаторов и серверную политику экспорта. Локальный владелец на одном хосте не всегда равен тому пользователю, которого видит процесс в контейнере или по сети.

Отдельно разберите каталоги очереди Postfix и почтовые ящики Dovecot. В типовой сборке Postfix значение queue_directory часто указывает на /var/spool/postfix, но его можно изменить при сборке или настройке. Очередь Postfix — не каталог пользовательских ящиков; нельзя переносить на неё схему владельцев Dovecot. В базе знаний это один из наиболее практичных фактов: почтовая очередь и хранилище ящиков — разные области, и проверять их надо по своим настройкам.

Я не называю 700, 750 или 3775 универсально правильными правами для почты. Режим зависит от того, кто читает и пишет данные, какие есть группы, ACL и требования к приватности. Особенно опасно механически ставить одинаковый режим всем файлам и каталогам: файлу и каталогу могут требоваться разные биты, а изменение рекурсивно заденет индексы и служебные данные. Проверяйте эталон работающей установки той же версии или официальную инструкцию к используемому решению.

• Сверить UID/GID процесса с владельцем данных
• Проверить родительские каталоги и ACL
• Отличать очередь Postfix от хранилища ящиков

Как восстановить доступ и не повредить почту

Перед изменениями я сохраняю текущие значения владельца, группы, режимов и ACL на затронутом дереве, а также проверяю резервную копию данных. Затем определяю наименьший объект, где атрибуты расходятся с ожидаемой конфигурацией. Если ошибка относится к одному каталогу или служебному файлу, исправляю только его. Массовая операция допустима лишь после того, как подтверждены целевой путь, UID/GID, состав дерева и отсутствие ссылок на другие данные. Иначе команда исправит всё подряд — включая то, что никто не просил чинить.

Команда chown меняет владельца, chmod — биты доступа; обе могут причинить вред при неверном пути или слишком широком охвате. GNU Coreutils отдельно описывает рекурсивный режим и нюансы обхода символических ссылок. Поэтому я не предлагаю команду вроде chown -R vmail:vmail /var/vmail как стандартный рецепт: vmail может не соответствовать вашей схеме, /var/vmail может быть не тем хранилищем, а внутри могут оказаться неожиданные точки монтирования или ссылки. Сначала делаю пробный осмотр и планирую откат.

Когда ожидаемые значения подтверждены, выполняю минимальное исправление и сразу перепроверяю результат через stat, namei и при необходимости getfacl. Не добавляю лишних прав «на всякий случай». Если в ошибке фигурирует каталог очереди Postfix, сверяю фактическое значение queue_directory, а не права на Maildir. Если Dovecot не может читать конфигурацию, проверяю сам конфигурационный файл и родительский путь; владелец почтовых данных тут может быть вообще ни при чём.

Затем проверяю конфигурацию и запускаю только затронутую службу способом, принятым в этой установке. На systemd-хосте это может быть systemctl status postfix dovecot и перезапуск нужного unit, но контейнерную систему перезапускают через её оркестратор. После запуска читаю свежие записи журнала: исчезла ли исходная ошибка, нет ли новой ошибки конфигурации и не накопилась ли очередь. Сам факт active (running) ещё не доказывает, что письма доходят до ящиков.

• Сохранить исходные атрибуты и резервную копию
• Исправить минимальный подтверждённый участок
• Перепроверить права и журнал после запуска

Как подтвердить, что доставка восстановилась

После исправления проверяю полный сценарий, который сломался. Для входящей почты смотрю, проходит ли SMTP-сессия до приёма сообщения, попадает ли сообщение в очередь и появляется ли в целевом ящике. Для исходящей — уходит ли письмо от клиента, обрабатывает ли его Postfix и нет ли задержки или возврата. Не делаю вывод по одному успешному локальному тесту: он может не пройти тот же путь, который используют внешние отправители или пользователи.

Если клиенты подключаются по IMAP, проверяю вход в тестовый ящик и чтение нового сообщения. Доступность сетевого порта подтверждает только соединение, а не аутентификацию, права на файлы или доставку. Telnet также не проверяет TLS-сценарий; для защищённого соединения выбирают соответствующий клиент и режим. Я не перечисляю порты как обязательный чек-лист восстановления прав: сетевые настройки относятся к отдельной ветке диагностики и проверяются, если симптомы на неё указывают.

Затем сверяю журналы Postfix и Dovecot с временем контрольных отправок и проверяю очередь штатной командой конкретной установки. Если сообщение осталось в очереди, смотрю причину задержки, а не удаляю его ради красивого пустого списка. Если это резервный MX, поможет отдельный разбор карт соответствия получателей Postfix. Если Dovecot показывает ошибку индекса или формата, не стираю индексы вслепую: сначала выясняю, затронуты ли данные или только служебное состояние. Письмо — плохой кандидат на эксперимент «а вдруг починится».

Проверка DNS, SPF, DKIM и DMARC нужна, когда есть признаки проблемы доставки или отклонения внешними системами. Эти записи сами по себе не исправляют отказ локального процесса в доступе к каталогу. Я отделяю локальную доставку от сетевой и доменной: подтверждаю каждый этап по журналам. В конце фиксирую, какой путь и владелец оказались причиной, что изменено и как откатить правку. Следующий дежурный должен получить объяснимое состояние, а не загадочную команду из истории терминала.

• Проверить входящее и исходящее тестовое письмо
• Сопоставить результат с журналом и очередью
• Зафиксировать причину, изменение и откат

Как не допустить повторного сбоя прав

Я ищу, кто именно изменил атрибуты: скрипт обслуживания, перенос данных, восстановление из архива, ручная команда или смена контейнерного образа. Автоматические обновления редко «по умолчанию» переписывают владельца всего /var; если это произошло, нужен журнал конкретной операции или история конфигурационного управления. Отключать обновления целиком — плохая профилактика: так проблема с правами может смениться проблемой с давно не установленными исправлениями. Нужна конкретная причина и точное ограничение опасной операции.

Резервная копия должна включать почтовые данные, конфигурацию и пригодный способ восстановления владельцев и ACL. Важен не только факт создания архива, но и проверка восстановления на отдельной среде либо в контролируемом сценарии. После восстановления сверяйте параметры хранилища и идентификаторы пользователей с целевой системой. Архив может содержать файлы, но не гарантировать корректные UID/GID после переноса между разными системами.

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

Если система управляется панелью или контейнером, внесите найденное исправление в поддерживаемый слой конфигурации и проверьте, что обновление его не перезатирает. Ручная правка генерируемого файла — временная мера, если источник конфигурации остался прежним. А для обычного Linux-сервера полезно документировать путь хранения, способ запуска, ожидаемые UID/GID и команду просмотра журналов. Это скучный список. Зато он лучше, чем повторный поиск «куда же у нас почта складывается» во время сбоя.

Частые вопросы