Pip suddenly giving permission denied error in virtual environments

So, I’ve been working on a shared linux box for several months, using several virtual environments to work with my code. All of a sudden, I’m getting a permission denied error inside my venvs when trying to use pip. Everything I can think of appears to be pointing to the correct place inside my venv, but when I try to do something as simple as a

pip list

I get a whole schwack of traceback, ending with:

  File "/home/fieldip1/repos/ns-orion-cmdb-integration/.venv/lib64/python3.11/site-packages/pip/_internal/metadata/importlib/_envs.py", line 96, in find_linked
    if not path.is_dir():
  File "/usr/lib64/python3.11/pathlib.py", line 1250, in is_dir
    return S_ISDIR(self.stat().st_mode)
  File "/usr/lib64/python3.11/pathlib.py", line 1013, in stat
    return os.stat(self, follow_symlinks=follow_symlinks)
PermissionError: [Errno 13] Permission denied: '/home/UsernameDeleted/DevOps/local'

(where UsernameDeleted is the name of another use on the box.) I assume he did something wrong by accident, but don’t know why it’s impacting my environments. If I am NOT in a venv, pip list will return a general set of installed packages. But if I am in ANY of my virtual environments, I get the above error when I try to do anything related to pip.

Any suggestions where to start looking?



Another user changing their home directory permissions to deny others access wouldn’t really be “wrong”, but highlights the issue of using anyone’s home directory as the location for a shared resource.

If multiple people need access to DevOps/local, it should probably be somewhere like /usr/local/share.


That’s the weird part. To my knowledge there’s no reason for anything under his home directory to be shared to me, and previously wasn’t. I have no idea why, when I run pip, it’s trying to access his directory - I can find nothing in any of my paths, nor environment that points to him.

Hm, that is strange. Do you get this same problem if you create a new virtual environment? (And if it does, can you verify what Python actually got used to create the venv?) As a last resort, I would suggest simply re-creating the existing venvs.

Check ls -lahR /home/UsernameDeleted/DevOps/local from both users to see if there’s anything unexpected in how the privileges are set up. Check if you set some weird umask. Finally, check if maybe there’s some selinux labels that are too restrictive. The underlying permission error is coming from the OS, after all.

You say they are “your” venvs, but:

  • where are they actually located in the filesystem?
  • how did they get created?
  • how are you activating them?

(In particular, is fieldip1 the user you currently have logged in, or is it some kind of shared account, or just what?)

1 Like

Also check not only subdirs, but also the parent directories — they should all remain accessible to your current user. Some people run commands with sudo by accident, and then some files are created with root and aren’t accessible to the low-privileged uses.

But in general, the above recommendation is correct — put stuff under your user if you don’t want external factos to mess with it.

That’s just it - it shouldn’t matter that the path is too restrictive, because there shouldn’t be anything pointing to it. It’s not an issue with permissions, but rather an issue that something is pointing to the wrong place…

Indeed they are my venvs. The venvs are located inside my home directory (the fieldip1 user). It’s not shared, it belongs only to me.

As it turns out, we found the issue. While I’m not 100% clear on what he did, the guy (UsernameDeleted) had added his path to the python path somewhere. Not sure exactly where, since I couldn’t find any reference to it in my environment, nor python. But perhaps I just missed it. From him:

“I think i know what this is about. I have added the path to the python path to streamline package imports in my code. I’ll remove it and see if that fixes your errors.”

and when he did, the errors went away…