pip в venv указывает на системный и падает: noexec в Ubuntu 24.04 — как исправить

Почему в Ubuntu 24.04 pip в venv не запускается и указывает на системный: раздел смонтирован с noexec. Что делать, чтобы импорт NumPy работал. Решение и обход.

Когда виртуальная среда вроде бы активирована, но pip отказывается работать, причина может оказаться вовсе не в Python. В Ubuntu 24.04 с Python 3.12 venv, созданный на точке монтирования с запретом на выполнение, приводит к тому, что pip возвращается к системной копии, а скомпилированные колёса падают на этапе импорта. Симптомы поначалу сбивают с толку: Python из venv запускается, pip указывает на глобальный, а попытка выполнить pip из venv заканчивается «Permission denied». Если обойтись через python -m pip, установка NumPy вроде проходит — пока импорт не рушится с ошибкой сопоставления сегмента разделяемого объекта.

Как воспроизвести проблему

Действия начинаются в каталоге на смонтированном разделе под /mnt:

python3 -m venv .venv
source ./.venv/bin/activate
which pip
which python
./.venv/bin/pip install numpy

Вывод демонстрирует несоответствие и невозможность выполнить pip из venv:

(.venv) $ which pip
/usr/bin/pip
(.venv) $ which python
/mnt/DATA/AUC/Research Assistant/Pedestrian-Estimation-Dataset-Annotation/test/.venv/bin/python
(.venv) $ ./.venv/bin/pip install numpy
bash: ./.venv/bin/pip: Permission denied

Установка через интерпретатор срабатывает:

python -m pip install numpy

Но в этой среде импорт скомпилированного расширения, такого как NumPy, падает:

ImportError: ... _multiarray_umath.cpython-312-x86_64-linux-gnu.so: failed to map segment from shared object
...
ImportError: Error importing numpy: you should not try to import numpy from
        its source directory; please exit the numpy source tree, and relaunch
        your python interpreter from there.

Минимальный скрипт, запускающий этап импорта, уже воспроизводит ошибку:

# файл: run_infer.py
import numpy as nx
print(nx.__version__)

Что на самом деле происходит

Дело не в pip, не в Python и не в NumPy. Виноваты параметры монтирования файловой системы. Среда находится по пути под /mnt, который смонтирован с noexec. Этот флаг запрещает запуск бинарников и скриптов с этого тома, независимо от прав на файлы. Поэтому оболочка не воспринимает .venv/bin/pip как исполняемый файл и подставляет /usr/bin/pip. Даже если вызвать pip из venv по пути, ядро отклонит запуск с «Permission denied».

Та же ограничительная опция ломает загрузку скомпилированных расширений, отсюда «failed to map segment from shared object» при импорте NumPy. В описанной конфигурации устройство отформатировано в NTFS и смонтировано через fuseblk с noexec. Проверка параметров монтирования проясняет картину:

mount | grep -F /mnt

Пример вывода, подтверждающий проблему, содержит флаг noexec:

(rw,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,user,x-gvfs-show)

Как это исправить

Есть два простых пути. Первый — работать в рамках текущего ограничения, вызывая pip через интерпретатор: ядро запускает разрешённый python, а сам модуль выполняется как скрипт:

python .venv/bin/pip <args>

эквивалентно:

python -m pip <args>

Второй — убрать ограничение в корне. Если venv (и проект) лежат на файловой системе, смонтированной с noexec, перемонтируйте её с exec, чтобы можно было запускать исполняемые файлы и подключаемые библиотеки. Запись в fstab до изменения выглядела так:

UUID=349264BD926484E8 /mnt/DATA  auto rw,user,uid=1000,gid=1000,dmask=0002,fmask=0002,nosuid,nodev,nofail,x-gvfs-show 0 0

Добавление exec разрешает выполнение на этом разделе:

UUID=349264BD926484E8 /mnt/DATA  auto rw,user,exec,uid=1000,gid=1000,dmask=0002,fmask=0002,nosuid,nodev,nofail,x-gvfs-show 0 0

После правки и перемонтирования pip из venv запускается нормально, а импорт NumPy проходит без ошибок. В качестве альтернативы можно пересоздать виртуальную среду на файловой системе без noexec.

Почему это важно

Виртуальные среды опираются на обёртки и entry points в каталоге bin внутри venv. Если файловая система под ними запрещает выполнение, привычные гарантии изоляции незаметно нарушаются. Оболочка тихо подменяет pip на системный, и установки «утекают» за пределы среды. Скомпилированные колёса подключают разделяемые объекты при импорте; с noexec загрузчик не может корректно отобразить сегменты, и это проявляется как загадочные ImportError. Правильные опции монтирования возвращают ожидаемое поведение и предотвращают трудноотлавливаемые ошибки во время работы.

Итоги

Если в активированной venv pip разрешается в системный бинарник или запуск pip из venv падает с «Permission denied», сначала проверьте параметры монтирования. Быстрый просмотр mount | grep -F /mnt часто покажет noexec на внешних носителях или NTFS-разделах. Временно пользуйтесь python -m pip, а затем перемонтируйте раздел с exec либо перенесите среду на файловую систему без noexec. Когда выполнение разрешено, pip и скомпилированные расширения вроде NumPy работают как ожидалось, а виртуальная среда остаётся действительно изолированной.