Заявки с сайта терялись молча: права на папку в Docker и как не допустить такого

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

Как нашлась причина

Я отправлял тестовую заявку, чтобы проверить почтовые уведомления. Письмо не ушло, и по пути я посмотрел, что с записью в файл. Оказалось, что папка data, подключённая к контейнеру, на сервере принадлежала пользователю root — она была создана при первой настройке. Приложение внутри контейнера работает от обычного пользователя с идентификатором 1000, и запись падала с ошибкой EACCES. Ошибка попадала только в журнал контейнера, а посетителю возвращался успешный ответ.

Почему это опасно

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

Что исправить

Сама правка проста: сменить владельца папки на тот идентификатор, под которым работает контейнер (chown -R 1000:1000 data). Но важнее три системных изменения. Первое: после любого деплоя с томом проверяйте запись реальной тестовой заявкой, а не по открывшейся странице. Второе: ошибка записи не должна скрываться — форма обязана вернуть сбой, а в уведомления должно уйти предупреждение. Третье: заявка не должна зависеть от одного места хранения, пусть она одновременно уходит в файл, на почту и в мессенджер.

Что почитать дальше

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