Repository navigation
creating venv Python3.13 on CIFS mounted drive fails ENODATA #133951
Description
Activity
I have the same issue when trying to use
--copiesto create a venv on fs without symlink support. It looks like venv always tries to create a lib64 -> lib symlink on linux platform, even with--copiesoption.git search in the code finds me lines 194-199 in
venv/__init__.py:if ((sys.maxsize > 2**32) and (os.name == 'posix') and (sys.platform != 'darwin')): link_path = os.path.join(env_dir, 'lib64') if not os.path.exists(link_path): # Issue #21643 os.symlink('lib', link_path)(note no test for "is --copies set")
and a reference to the following bug report: #98975 , which this issue may be a duplicate of. That issue also presents a workaround to avoid the ENODATA; mkdir the lib64 directory by hand before making the venv:
# mkdir -p venv/lib64 # Workaround # python -m venv venv --copiesSee also #63007 (comment) , from when --copies became an option. While correct, it doesn't solve the issue "what if the filesystem does not support symlinks?"
Looking for a code change that would lead to this behavior between 3.10 and 3.13, by best guess for the origin of the issue is 48d9262, which may have led to a
libdirectory not being present.The problematic code pointed above was introduced to fix GH-65396 (or issue 21197, as mentioned in the code). As of 48d9262, it shouldn't be needed, as we now get the lib directory path from sysconfig, instead of building it manually. Instead of hardcoding
liband then symlinking or copying it tolib64, we should now be usinglib64directly, in the first place. This makes the manuallib64symlink unnecessary.Additionally, the
(sys.maxsize > 2**32) and (os.name == 'posix') and (sys.platform != 'darwin')conditional does not accurately indicate the usage oflib64, instead oflib, as the directory name, so removing it from the code would be nice.Note: If I am correct, this also means that
libis used instead oflib64as the directory name in your system installation.Does it mean we can just simply remove the symlink creation?
Note: If I am correct, this also means that lib is used instead of lib64 as the directory name in your system installation.
I guess it is because
sys.platlibdirislibin 64-bit debian. So thelibis used instead oflib64.I think so.
My main worry about that change is backwards compatibility.
From my comment on the PR, #137139 (review):
There's a possibility it would break user code when users are hardcoding the path, or not using the
venvscheme. Though, the code is already fundamentally broken in both those situations, so I agree with this change.To mitigate breakage, we could simply omit the symlink when symlinks aren't available, but since it should only impact code that is already somehow broken, I think just removing the symlink creation entirely is reasonable.
- marked
test_peg_generatorfailures on some buildbots #139604 as a duplicate of this issueon Oct 5, 2025 - added a commit that references this issue
on Oct 6, 2025 My main worry about that change is backwards compatibility.
Mine is too.
AFAIK, issues with thelib/lib64split were usually found (and ideally fixed) by distro packagers on systems where the distinction matters. Distros don't use venvs; they're also invested in getting the packaging details just right.By removing the symlink from venvs, we shift the burden of “doing the right thing“ to regular users & library maintainers. Supporting systems that separate
lib/lib64will get harder.
I think forcing people to do the pedantically correct thing is rather unfriendly. OTOH, the pedantically correct thing is required to support symlink-less filesystems...IMO, this needs a What's New entry (if not a revert). @Cycloctane, do you want to write one?
FWIW:
since it should only impact code that is already somehow broken
This is generally not a good reason to break things. People often write code for specific environments, where platform-specific and assumption-laden solutions will work just fine.
IMO, this needs a What's New entry (if not a revert). Cycloctane, do you want to write one?
I would like to add this to 3.15 whatsnew if it is not going to be reverted.
Reacted by Petr ViktorinThank you!
Bug report
Bug description:
My Ubuntu environment has been running with my Python projects on a Synaptic NAS (mounted as cifs) for several years. Relevant line from
/etc/fstab://DiskStation.local/home /media/data/[user] cifs uid=1000,forceuid,iocharset=utf8,vers=3.0,credentials=[credsfile] 0 0Now with upgrade to python3.13, when I try to create or upgrade a venv, I get:
python -m venv venv_test->Error: [Errno 61] No data available: 'lib' -> '/media/data/[user]/test/venv_test/lib64'Some investigation leads me to "can't create symlinks on a cifs drive", as shown:
ln -s venv_test/lib venv_test/lib64->ln: failed to create symbolic link 'venv_test/lib64': No data availableSo, I try with
--copiesinstead:python -m venv --copies venv_test->Error: [Errno 61] No data available: 'lib' -> '/media/data/[user]/test/venv_test/lib64'As I said, this used to work in python 3.10. If it won't work by design now, fine; I can put the venvs off that drive. But the error message should be more clear, or at least there should be a way to get more verbose information.
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs