Docker на OpenVZ выдаёт Operation not permitted: почему нужен KVM

Почему Docker пишет Operation not permitted, хотя в VPS есть root

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

Типичный тупик выглядит так: Docker установился без ошибок, docker.service находится в состоянии active, образы скачиваются, но при создании контейнера появляется OCI runtime create failed, а ближе к концу сообщения — Operation not permitted. В другом случае hello-world запускается нормально, но один сервис Compose падает, как только пытается применить sysctl, создать особую сеть, обратиться к device или получить дополнительную capability. Переустановка Docker в такой ситуации почти ничего не проверяет.

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

Минимальный тест выглядит так:

whoami
id
systemctl status docker --no-pager
docker version
docker info
docker run --rm hello-world

Если docker info даже не получает ответ от daemon, сначала разберитесь с запуском самого dockerd:

journalctl -u docker --no-pager -n 100

Если daemon работает, но минимальный контейнер не создаётся, полезны и сообщения containerd:

journalctl -u containerd --no-pager -n 100

Если hello-world запускается, это только базовая проверка. Такой контейнер почти не тестирует сложные volumes, нестандартные namespaces, bridge-сеть, дополнительные capabilities, devices и системные параметры. Один успешный контейнер — слабый тест.

Например, вполне возможна ситуация, когда обычный Nginx в Docker работает, а VPN-контейнер или сервис мониторинга, которому нужен NET_ADMIN, падает. Это не противоречие: второй image требует от ядра больше возможностей.

Не любую ошибку permissions нужно списывать на виртуализацию. Если приложение пытается прочитать каталог другого пользователя, bind mount указывает не туда или файлы принадлежат неверному UID, проблема находится в обычных Unix-правах. OpenVZ становится серьёзным подозреваемым, когда отказ возникает при создании namespace, cgroup, mount, сетевого интерфейса, правила netfilter, device или другого системного объекта.

Как проверить, действительно ли VPS работает на OpenVZ

Связывать Operation not permitted с OpenVZ имеет смысл только после подтверждения типа виртуализации. Название «Linux VPS» не говорит, используется ли OpenVZ, Virtuozzo Containers, KVM или другая технология.

Быстрее всего начать с:

systemd-detect-virt

Типичные варианты вывода могут выглядеть так:

openvz

или:

kvm

Если команда явно возвращает openvz, направление диагностики уже понятно. При kvm искать именно OpenVZ-ограничение бессмысленно: нужно проверять Docker, гостевое ядро, firewall, cgroups и приложение внутри KVM.

Если systemd-detect-virt отвечает none или результат выглядит неожиданно, одной команды недостаточно. Сопоставьте ещё несколько признаков:

hostnamectl
uname -r
test -d /proc/vz && echo "OpenVZ/Virtuozzo marker found"

Если установлена утилита virt-what:

virt-what

Достаточным подтверждением обычно можно считать согласованную картину: systemd-detect-virt определяет OpenVZ, присутствуют характерные маркеры контейнерной среды, а провайдер указывает OpenVZ или Virtuozzo Containers для этого VPS. Если одна команда говорит одно, а остальные признаки другое, не стройте дальнейшую диагностику на предположении.

В поддержке подобное часто всплывает только после установки Docker. Nginx, PHP, MySQL, cron и SSH годами могут не требовать тех функций ядра, на которых ломается вложенная контейнеризация. Пользователь впервые узнаёт о типе VPS именно тогда, когда приложение просит возможность, которой root внутри контейнера не управляет.

Какие возможности Linux нужны Docker и что OpenVZ может ограничить

Docker зависит не только от dockerd. При создании контейнера задействуются механизмы ядра Linux: namespaces изолируют процессы и сеть, cgroups управляют ресурсами, capabilities разрешают отдельные привилегированные действия, storage driver работает с файловыми слоями, а Docker networking использует сетевые namespaces, bridge и netfilter.

Поэтому состояния «Docker установлен» и «Docker может использовать всё необходимое для этого Compose-проекта» — разные вещи.

Зачем Docker нужны namespaces и что проверять при EPERM

Namespaces дают контейнеру отдельное представление процессов, сети, mount-точек, hostname и других ресурсов. Docker обычно задействует PID, network, mount, IPC и UTS namespaces, а некоторые конфигурации используют и user namespaces.

Посмотреть существующие namespaces можно так:

lsns
readlink /proc/1/ns/mnt
readlink /proc/self/ns/net

Здесь есть важная граница: lsns показывает существующие namespaces, но не отвечает на вопрос, разрешено ли Docker создать любой новый namespace с нужными параметрами. Поэтому при ошибке вида failed to create ... namespace: operation not permitted лог runc/containerd обычно информативнее самого списка lsns.

Если EPERM возникает ещё на стадии container create, до запуска entrypoint приложения, смотреть код Node.js, PHP или сам веб-сервис рано. Процесс приложения ещё не успел стартовать.

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

Docker использует cgroups для учёта и ограничения CPU, RAM, количества процессов и других ресурсов. Начните с информации, которую видит сам daemon:

docker info | grep -i -E 'Cgroup Driver|Cgroup Version'
mount | grep cgroup
stat -fc %T /sys/fs/cgroup

На системе с cgroup v2 последняя команда обычно показывает:

cgroup2fs

Для cgroup v1 картина mount будет другой, поэтому один stat не нужно использовать как универсальный тест. Смотрите все три результата вместе.

Нормальная ситуация: Docker определяет Cgroup Driver и Cgroup Version, hierarchy смонтирована, а контейнеры с обычными resource limits создаются. Наличие /sys/fs/cgroup само по себе ещё ничего не гарантирует. Каталог может существовать, но нужная операция записи внутри внешнего OpenVZ-контейнера будет запрещена.

Сильнее говорят логи:

failed to create cgroup
permission denied
read-only file system
operation not permitted

Формулировка зависит от runtime и окружения, но диагностическая мысль одна: если Docker на стадии создания контейнера не может создать или изменить cgroup, проверка chmod каталога приложения к этой ошибке отношения не имеет.

Отдельный тест можно сделать на контейнере с ограничением памяти:

docker run --rm --memory=128m alpine echo ok

Если обычный контейнер работает, а создание контейнера с resource limit стабильно падает на cgroup-операции, это полезный признак. Он ещё не доказывает вину OpenVZ без проверки логов и виртуализации, но сильно сужает область поиска.

Как проверить Linux capabilities, а не только UID 0

Linux разбивает традиционные полномочия root на отдельные capabilities. CAP_NET_ADMIN, например, нужна для многих операций с сетевыми интерфейсами и маршрутизацией; CAP_SYS_ADMIN охватывает широкий набор чувствительных системных действий.

Сырой набор capabilities текущего процесса можно увидеть так:

grep '^Cap' /proc/self/status

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

CapInh:
CapPrm:
CapEff:
CapBnd:

Значения там представлены битовыми масками. Для человека такой hex-вывод неудобен: по строке вроде CapEff нельзя на глаз надёжно понять, есть ли CAP_NET_ADMIN. Намного удобнее:

capsh --print

Если нужно декодировать конкретную маску, можно использовать:

capsh --decode=<hex-mask>

Смотрите прежде всего на effective/bounding set и на capability, которой требует проблемный контейнер. Если Docker-контейнеру добавляют NET_ADMIN, а внешний OpenVZ-контейнер сам не может выполнить нужную сетевую операцию, внутренний --cap-add не создаст это право из воздуха.

Как отличить capability-проблему от обычной ошибки приложения

Хороший признак — место возникновения ошибки. Если Compose создаёт контейнер, запускает процесс, а уже приложение пишет Permission denied при чтении /app/config, сначала проверяйте UID/GID и права файлов. Если runc падает до запуска процесса на mount, setns, mknod, network или sysctl, область поиска уже другая.

Ещё один сценарий: hello-world работает, обычный Nginx работает, а контейнер с VPN или сетевым мониторингом падает только без NET_ADMIN. Это не значит, что Docker «то работает, то нет». Просто разные images требуют разные kernel-возможности.

После ошибки cgroup нет смысла начинать с chmod каталога сайта. После отказа iptables не нужно первым делом менять storage driver. Чем точнее определена системная операция, тем меньше случайных изменений придётся делать на сервере.

Как по тексту ошибки определить, что именно блокирует Docker

Operation not permitted — финальное сообщение об отказе, а не диагноз. В длинной цепочке docker compose → dockerd → containerd → runc полезная часть обычно находится в той же строке или несколькими строками выше: нужно найти действие, которое выполнялось непосредственно перед EPERM.

Для Compose-проекта удобнее получить ошибку в foreground:

docker compose up

После неудачной попытки:

docker ps -a
docker inspect <container>
journalctl -u docker --no-pager -n 100
journalctl -u containerd --no-pager -n 100

Не зацикливайтесь на всей многострочной ошибке целиком. Сначала классифицируйте операцию.

Например, общий рисунок ошибки storage может выглядеть так:

... failed to mount overlay ...
... operation not permitted

А сетевой сбой — так:

... iptables ...
... permission denied ...
... failed to create network ...

Это не строки, которые нужно искать буквально символ в символ: формулировки меняются между версиями Docker, containerd, runc и окружениями. Смысл примеров — показать, какую операцию нужно вычленить из сообщения.

Если лог говорит о cgroup, переходите к cgroups. Если падает iptables, storage пока можно отложить. Если контейнер создан, но entrypoint завершился с кодом 1, сначала нужен docker logs, а не исследование OpenVZ.

События Docker иногда помогают увидеть порядок действий:

docker events

Это удобно, когда Compose одновременно поднимает несколько сервисов и один из них быстро создаётся, падает и перезапускается.

Если после локализации выяснилось, что проблема связана с владельцем bind mount, OpenVZ может быть вообще ни при чём. Если один и тот же тест на подтверждённом OpenVZ стабильно падает на kernel-операции, недоступной root внутри VPS, версия с ограничением хоста становится намного убедительнее.

Почему файловая система и storage driver становятся проблемой на OpenVZ

Docker хранит слои образов и writable layer контейнеров через storage backend, который зависит от ядра и файловой системы. В OpenVZ пользователь видит не всё окружение, на котором фактически выполняются эти операции: часть возможностей определяется хост-нодой.

Как определить storage driver и прочитать результат

Начните с:

docker info

Или получите только driver:

docker info | grep -i "Storage Driver"
docker info --format '{{.Driver}}'

Например, результат может быть:

Storage Driver: overlay2

Сам по себе overlay2 не говорит о проблеме. Важна связка: какой driver используется, на какой операции Docker падает и что пишет daemon/runtime.

Проверить, известно ли ядру OverlayFS:

grep overlay /proc/filesystems

Если строка overlay присутствует, ядро знает эту файловую систему. Но это не подтверждает, что конкретному OpenVZ-контейнеру разрешено вложенное использование OverlayFS во всех нужных Docker-сценариях.

Как выглядит проблема именно с storage

Если docker.service не запускается, сначала смотрите daemon log:

systemctl status docker --no-pager
journalctl -u docker --no-pager -n 150

Подозрительны ошибки, в которых рядом находятся storage driver, overlay, mount, snapshot или создание layer. Если daemon запускается, но конкретный контейнер падает при создании writable layer, полезная запись может появиться уже во время docker run или docker compose up.

Диагностическая картина может быть такой:

Storage Driver: overlay2
...
failed to mount overlay ...
operation not permitted

Здесь проверка storage оправданна. Если вместо этого лог говорит:

bind source path does not exist

или приложение получает Permission denied на конкретном каталоге, сначала смотрите сам bind mount, путь и UID/GID. Это другой класс проблемы.

Как отличить проблему storage driver от bind mount

Полезный пограничный случай: named volume работает, а bind mount падает. Это скорее направляет диагностику к пути на host filesystem, владельцу файлов, SELinux/AppArmor в тех системах, где они участвуют, и параметрам самого mount, а не к OverlayFS как таковому.

Посмотреть mounts контейнера:

docker inspect <container>

Для named volume:

docker volume inspect <volume_name>

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

Почему vfs полезен как тест, но плох как универсальный рецепт

Старый совет «переключить Docker на vfs» иногда действительно помогает локализовать проблему. Если ошибка, связанная с OverlayFS, исчезла после смены driver, это сильная подсказка. Но vfs не добавляет OpenVZ недоступные namespaces, cgroups, netfilter или capabilities и обычно имеет значительно менее эффективную модель хранения данных.

Правка /etc/docker/daemon.json не может включить функцию ядра, которой управляет только физический хост. Переустановка Docker здесь тоже ничего не добавит ядру.

Если обход с другим driver сработал, повторите полный сценарий: реальный Compose, volumes, network и reboot. Работоспособность одного контейнера ещё не делает среду надёжной для всего проекта.

Почему Docker запускается, но сеть контейнеров не работает

hello-world может проходить, а docker compose up падать уже на создании bridge или правила NAT. Docker networking использует отдельные сетевые namespaces, bridge-интерфейсы, veth, forwarding и netfilter, поэтому успешный запуск процесса внутри контейнера проверяет лишь часть системы.

Типовые симптомы здесь разные:

• Compose не может создать network;
• контейнер запускается, но не выходит в интернет;
• IP-адрес снаружи доступен, а DNS-имя внутри контейнера не разрешается;
• исходящее соединение работает, но опубликованный через -p порт снаружи недоступен;
• Docker сообщает об ошибке iptables или nftables;
• не создаётся bridge или veth;
• сетевые команды внутри самого OpenVZ VPS возвращают EPERM.

Если контейнер вообще не выходит в сеть

Начните с Docker network:

docker network ls
docker network inspect bridge
ip link

В docker network inspect bridge смотрите, существует ли сеть, какой subnet ей назначен и подключён ли нужный контейнер. Сам JSON большой; здесь не нужно анализировать каждое поле. Нас интересует, создал ли Docker bridge-сеть и видит ли контейнер как её участника.

Маршрут внутри уже запущенного контейнера:

docker exec <container> ip route

Если image не содержит утилиту ip, используйте диагностический image, где она есть, вместо установки пакетов в production-контейнер только ради теста.

Проверка исходящего IP-соединения:

docker run --rm alpine ping -c 1 1.1.1.1

Неудачный ping сам по себе ещё не доказывает проблему Docker или OpenVZ: ICMP может фильтроваться. Для серьёзной диагностики результат нужно сопоставлять с маршрутами, TCP-соединением приложения и состоянием NAT.

Если IP работает, а DNS нет

Отделите DNS от маршрутизации:

docker run --rm alpine nslookup example.com

Если соединение по IP проходит, а DNS lookup нет, исследовать OverlayFS или cgroups уже нет смысла. Смотрите DNS-настройки Docker, /etc/resolv.conf внутри контейнера и доступность используемого resolver.

Если контейнер выходит наружу, но опубликованный порт недоступен

Это отдельная ветка. Сначала убедитесь, что Docker действительно опубликовал порт:

docker ps
docker port <container>

Затем проверьте, на каком адресе слушает сам сервис внутри контейнера. Приложение, привязанное только к 127.0.0.1 внутри контейнера, может создать совсем другую проблему, чем запрет netfilter.

Для firewall и NAT, в зависимости от системы:

iptables -t nat -L -n

или:

nft list ruleset

Forwarding:

sysctl net.ipv4.ip_forward

Если iptables или nft внутри подтверждённого OpenVZ VPS сами отвечают Permission denied или Operation not permitted, это сильный признак того, что сетевые полномочия среды ограничены. Но даже тогда нужно проверить конфигурацию Docker и уточнить у провайдера, разрешены ли нужные netfilter-функции для контейнера.

Другими словами, фраза «у Docker не работает сеть» слишком широкая. Отделите DNS от маршрутизации, исходящий трафик от публикации портов, а конфигурацию приложения — от возможности OpenVZ создавать bridge и правила NAT.

Почему --privileged, --cap-add и rootless Docker не всегда спасают OpenVZ

После Operation not permitted часто пробуют --privileged или добавляют конкретную capability. Иногда это действительно исправляет запуск. Но такой результат означает только то, что проблема находилась в полномочиях внутреннего Docker-контейнера, доступных Docker host.

В OpenVZ цепочка выглядит так:

Физический сервер
    |
OpenVZ/Virtuozzo container
    |
Docker daemon
    |
Docker container

--privileged расширяет права последнего уровня относительно Docker host. Он не превращает OpenVZ-контейнер в KVM и не отменяет ограничения, которые физическое ядро уже наложило на внешний контейнер.

Для диагностики можно сравнить обычный запуск и запуск с требуемой capability либо --privileged. Но такой эксперимент нужно проводить только на тестовом контейнере, которому вы доверяете.

Последняя строка не является математическим доказательством OpenVZ-проблемы. То же поведение может дать security policy или ошибка конфигурации Docker host. Но вместе с подтверждённым OpenVZ и логом, где одна и та же операция получает EPERM, это сильный диагностический признак.

Почему --cap-add имеет внешний предел

Например:

docker run --rm --cap-add NET_ADMIN <image>

может дать Docker-контейнеру NET_ADMIN относительно Docker host. Но если сам внешний OpenVZ-контейнер не получил возможность выполнить требуемую сетевую операцию, передать её дальше не получится.

Поэтому не нужно последовательно добавлять SYS_ADMIN, NET_ADMIN и остальные capabilities наугад. Сначала найдите операцию в логе и определите, какое право ей действительно требуется.

Почему rootless Docker решает другую задачу

Rootless Docker предназначен для запуска daemon и контейнеров без обычных root-привилегий и использует user namespaces. Это полезная модель безопасности, но не способ получить запрещённые внешним OpenVZ-хостом kernel-возможности.

У rootless есть собственные требования к user namespaces, subordinate UID/GID и сетевой модели. Если первоначальная ошибка никак не связана с моделью root daemon, переход в rootless добавляет новые переменные в диагностику.

Если внешний контейнер не получил нужное право от хоста, внутренний Docker-контейнер не сможет обойти эту границу одним параметром запуска.

Что меняется при переносе Docker с OpenVZ на KVM

KVM решает этот класс проблем не потому, что KVM обязательно быстрее OpenVZ. Для Docker важнее модель виртуализации: OpenVZ-контейнер использует ядро хост-системы, а KVM-виртуальная машина загружает собственное гостевое ядро Linux.

Администратор KVM VPS может обновлять своё ядро, управлять доступными внутри VM kernel modules, cgroups, sysctl, firewall и другими механизмами гостевой ОС без необходимости просить владельца OpenVZ-ноды включить функцию именно для системного контейнера.

Это не означает полный доступ к физическому серверу. KVM-гость остаётся виртуальной машиной с виртуальными CPU, RAM, дисками, сетевыми устройствами и ограничениями гипервизора. Но Docker взаимодействует с ядром собственной VM, а не работает как дополнительный уровень контейнеризации внутри ограниченного OpenVZ-контейнера.

Что KVM не исправит

После миграции легко получить ложное ощущение, что любая Docker-проблема теперь должна исчезнуть. Это не так.

На новом KVM VPS повторите тот же тест, который падал на OpenVZ. Иначе вы не узнаете, исчезло ограничение или просто изменился сценарий.

systemd-detect-virt
uname -r
docker info
docker run --rm hello-world
docker compose up -d
docker network ls

Если проблемный Compose-проект на OpenVZ стабильно получает EPERM при одной и той же kernel-операции, а после переноса на чистую KVM VM этот же сценарий проходит, причина миграции подтверждается гораздо лучше, чем общим тезисом «Docker лучше запускать на KVM».

Как перенести Docker-проект с OpenVZ на KVM без потери данных

Когда ограничение OpenVZ подтверждено, опаснее всего переносить сервер в спешке. Сам Docker-контейнер обычно можно пересоздать из image. Реальная ценность находится в Compose-конфигурации, .env, bind mounts, named volumes, базах данных, сертификатах и пользовательских файлах.

Перед миграцией зафиксируйте состояние:

docker version
docker compose version
docker ps
docker images
docker volume ls
docker network ls

Для каждого контейнера определите, откуда он получает постоянные данные. В Compose-файле ищите volumes, а named volume можно проверить так:

docker volume inspect <volume_name>

Отдельно сохраните:

• compose.yml или docker-compose.yml;
• файлы .env;
• bind-mounted каталоги;
• named volumes;
• backup баз данных;
• uploads и пользовательские файлы;
• конфигурацию Nginx, Traefik, Caddy или другого reverse proxy;
• TLS-сертификаты, если ими управляет не сам контейнер;
• secrets и ключи, которые не находятся в image.

Для MySQL, MariaDB и PostgreSQL безопаснее использовать корректный backup с учётом конкретной СУБД, а не копировать файлы работающей базы во время записи. Файлы могут скопироваться без ошибок, но состояние базы получится несогласованным.

Рабочая последовательность:

1. Зафиксировать версии Docker и Compose и список контейнеров.
2. Сохранить Compose-файлы, .env и конфигурацию.
3. Определить все bind mounts и named volumes.
4. Сделать backup базы и пользовательских данных.
5. Развернуть чистый KVM VPS.
6. Установить Docker и Compose из поддерживаемого источника.
7. Перенести конфигурацию и постоянные данные.
8. Запустить проект.
9. Проверить контейнеры, volumes, сеть, базу и HTTP/HTTPS.
10. Перезагрузить VPS и проверить автоматический запуск после reboot.
11. Только после полной проверки переключить рабочий трафик.

После запуска:

docker compose ps
docker compose logs

Статуса Up недостаточно. Выполните операцию записи в приложении, проверьте, что данные действительно попали в нужный volume, убедитесь в работе БД, откройте сервис через тот же HTTP/HTTPS-маршрут и проверьте его после reboot.

Контейнер расходный, данные — нет.

Когда перестать чинить OpenVZ и перенести Docker на KVM

Перенос оправдан, если проблемную kernel-функцию может включить только администратор OpenVZ-хоста. Если же причина находится в Compose, UID/GID, bind mount, firewall или настройке приложения внутри VPS, сначала исправьте её: KVM не нужен как лекарство от любой ошибки Docker.

Оставаться на OpenVZ можно, если провайдер официально поддерживает Docker в конкретной конфигурации, реальный Compose-проект протестирован, storage и networking работают, cgroups доступны, а приложению не нужны запрещённые kernel-функции. Само слово OpenVZ ещё не означает, что Docker обязательно сломан.

Совсем другая ситуация — сегодня проект работает, а после обновления image новый сервис требует недоступный sysctl, device или capability. Если для каждого такого изменения нужно выяснять, разрешит ли его администратор хост-ноды, workaround становится частью архитектуры. Для постоянной Docker-инфраструктуры это плохая зависимость.

Что отправить в поддержку VPS, если подозрение падает на OpenVZ

Запрос «Docker не работает, помогите» почти неизбежно потребует дополнительной переписки. Гораздо полезнее сразу приложить результаты базовой диагностики:

systemd-detect-virt
uname -r
docker version
docker info
docker run --rm hello-world
journalctl -u docker --no-pager -n 100

Если ошибка возникает только в Compose, приложите сам фрагмент ошибки из:

docker compose up

и укажите, на какой операции всё падает: cgroup, OverlayFS, iptables/nftables, sysctl, mount, device или namespace.

Вопрос поддержке лучше формулировать предметно:

«Поддерживается ли Docker внутри этого OpenVZ/Virtuozzo-контейнера и разрешена ли требуемая функция: cgroup, OverlayFS, netfilter, конкретная capability или системный параметр?»

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

Docker выдаёт Operation not permitted: проверка за 10–15 минут

• Определить виртуализацию через systemd-detect-virt и дополнительные признаки.
• Проверить состояние docker.service.
• Выполнить docker version и docker info.
• Запустить docker run --rm hello-world.
• Определить стадию сбоя: daemon, create, start, network или volume.
• Получить journalctl Docker и при необходимости containerd.
• Найти операцию непосредственно перед Operation not permitted.
• При cgroup-ошибке проверить Cgroup Driver/Version и /sys/fs/cgroup.
• При storage-ошибке определить storage driver и сопоставить его с логом mount/overlay.
• При сетевой ошибке разделить DNS, outbound, bridge/NAT и published port.
• При capability-ошибке проверить capsh --print и требования проблемного контейнера.
• Сравнить минимальный контейнер с реальным docker compose up.
• Определить, может ли нужную настройку изменить root VPS или только администратор OpenVZ-хоста.