Too many levels of symbolic links ошибка - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

1. Overview

In this article, we’ll have a look at how to solve the “Too many levels of symbolic links” error when we want to use a symlink.

2. Using the ln Command To Create Symbolic Links

To create a symlink using the ln command, we need to pass the –s or –symbolic option:

$ ln -s A B

The GNU manual for ln shows the source as TARGET and the destination as LINK_NAME:

ln [OPTION]... [-T] TARGET LINK_NAME

This naming convention might be confusing for some people, so it’s probably helpful to remind ourselves that ln is like cp and mv: the source (A) needs to come first, followed by the destination (B).

Or we can just say it naturally: We are creating a symbolic link to A, and we want to call it B.

Let’s say we have the following directory structure:

$ tree --noreport -fp
.
└── [drwxr-xr-x] ./topdir
    ├── [drwxr-xr-x] ./topdir/source
    └── [drwxr-xr-x] ./topdir/outputdir

We then create a symlink and expect that the created outputdir/source symlink will point to the source directory:

$ cd /topdir
$ ln -s source outputdir
$ tree --noreport -fp
.
├── [drwxr-xr-x] ./source
└── [drwxr-xr-x] ./outputdir
    └── [lrwxrwxrwx] ./outputdir/source -> source

The symlink was created, but it is actually broken.

We can find all broken symlinks with the find command:

$ find -L -xtype l
find: ‘./test/outputdir/source’: Too many levels of symbolic links

The reason for this error is that symbolic links with relative sources are always relative to the symlink directory, not the directory from where we created the link.

So, the symlink /topdir/outputdir/source that we just created points to /topdir/outputdir/source instead of /topdir/source.

Let’s take a look at another example.

Let’s say we have this directory structure. Then, after we create the symlink, we can check if the symlink is good:

$ cd /topdir
$ tree --noreport -fp
.
└── [drwxr-xr-x] ./test
    ├── [drwxr-xr-x] ./test/source
    └── [drwxr-xr-x] ./test/outputdir
 
$ ln -s test/source test/outputdir
$ tree --noreport -fp
.
└── [drwxr-xr-x] ./test
    ├── [drwxr-xr-x] ./test/source
    └── [drwxr-xr-x] ./test/outputdir
        └── [lrwxrwxrwx] ./test/outputdir/source -> test/source
 
$ find -L -xtype l
./test/outputdir/source

The symlink that we just created – /topdir/test/outputdir/source – is also broken because it’s pointing to a non-existent directory.

Instead of pointing to /topdir/test/source, it is pointing to /topdir/test/outputdir/test/source.

There are two ways to fix this. Let’s have a look in the next sections.

4. Use an Absolute Path

We can use an absolute path for the source parameter:

$ cd /topdir
$ ln -s "$(pwd)/source" outputdir
$ tree --noreport -fp
.
├── [drwxr-xr-x] ./source
└── [drwxr-xr-x] ./outputdir
    └── [lrwxrwxrwx] ./outputdir/source -> /topdir/source

Let’s verify that the link is working:

$ cd /topdir
$ touch /topdir/source/sample.txt
$ tree --noreport -fp
.
├── [drwxr-xr-x] ./source
│   └── [-rw-r--r--] ./source/sample.txt
└── [drwxr-xr-x] ./outputdir
    └── [lrwxrwxrwx] ./outputdir/source -> /topdir/source
$ cd outputdir/source
$ ls -l
total 0
-rw-r--r-- 1 baeldung baeldung 0 Aug 3 20:51 sample.txt

As we can see above, we’ve successfully used the symlink to access the source directory and list all the files.

The downside of making symlinks to absolute paths is that they are easily broken when the directory names change.

5. Use a Relative Path

Another way to solve the error is to use a relative path for the source parameter:

$ cd /topdir
$ ln -s ../source outputdir
$ tree --noreport -fp
.
├── [drwxr-xr-x] ./source
│   └── [-rw-r--r--] ./source/sample.txt
└── [drwxr-xr-x] ./outputdir
    └── [lrwxrwxrwx] ./outputdir/source -> ../source
$ ls outputdir/source -l
lrwxrwxrwx 1 baeldung baeldung 9 Aug 3 21:11 outputdir/source -> ../source

We can use the -r or –relative option for the ln command to generate the source path automatically:

$ cd /topdir
$ ln -sr source outputdir
$ tree --noreport -fp
.
├── [drwxr-xr-x] ./source
│   └── [-rw-r--r--] ./source/sample.txt
└── [drwxr-xr-x] ./outputdir
    └── [lrwxrwxrwx] ./outputdir/source -> ../source
$ ls outputdir/source -l
lrwxrwxrwx 1 baeldung baeldung 9 Aug 3 21:11 outputdir/source -> ../source

We have successfully used the symlink to access the source directory and list all the files.

6. Conclusion

In this article, we’ve seen that symbolic links with relative sources are always relative to the symlink directory, not the directory from where we created the link. There are two ways to solve the “Too many levels of symbolic links” error. We can pass the source parameter as either an absolute or relative path.

Источник

As requested, I’m creating another issue for this error.

Some relevant links that go even more in depth on it, in previous posts (in mo particular order):

version 2.2.0.0: Error while creating mount source path ‘/host_mnt/c/code’: mkdir /host_mnt/c/code: file exists #5516 (comment)
version 2.2.0.0: Error while creating mount source path ‘/host_mnt/c/code’: mkdir /host_mnt/c/code: file exists #5516 (comment)
version 2.2.0.0: Error while creating mount source path ‘/host_mnt/c/code’: mkdir /host_mnt/c/code: file exists #5516 (comment)
docker: Error response from daemon: error creating overlay mount to /var/lib/docker/overlay2/<string-of numbers>fb-init/merged: too many levels of symbolic links. phpmyadmin/docker#267

An additional aside:
In the above link I mention/show that the docker run php:apache container is one of them that also gives this error; it seems after the latest Docker update, it no longer does; however, the docker run wordpress:apache does still give the same overlay error.

I have tried with the latest version of my channel (Stable or Edge)
I have uploaded Diagnostics
Diagnostics ID: 2ECBE1F4-ADE2-4D97-8082-505598CFAE53/20200213120818

Expected behavior

No overlay error while trying to create certain containers. (Apparently not happening to all containers, as I can run many others, though I haven’t picked out a pattern yet).

Actual behavior

Getting an overlay error.

Information

See below

Windows Version: See below
Docker Desktop Version: See below
Are you running inside a virtualized Windows e.g. on a cloud server or on a mac VM: It’s running in Docker Desktop (Hyper-V)

Unfortunately for me, I still have the same issue with an overlay error (which I don’t really understand).

I just installed:

Using this Compose (I left out the MySQL service, to focus on the problem container):

version: '2'

services:

  phpmyadmin:
    container_name: phpmyadmin
    image: 'phpmyadmin/phpmyadmin:latest'
    restart: unless-stopped
    environment:
      - TZ='America/Chicago'
      - "PMA_HOST=mysql"
      - "MYSQL_ROOT_PASSWORD=RlL1#2Z%^W"
      - "PMA_ABSOLUTE_URI=https://my.domain.rocks:3112/phpmyadmin/"
    volumes:
      - "/f/Sites/Web/.config/PHPMyAdmin/Files:/Files:rw,shared"    
      - "/f/Sites/Web/.config/PHPMyAdmin/config.user.inc.php:/etc/phpmyadmin/config.user.inc.php"
      - "/f/Sites/Web/.config/PHPMyAdmin/apache2.conf:/etc/apache2/apache2.conf"
      - "/f/Sites/Web/.config/PHPMyAdmin/Themes/:/var/www/html/themes/"
    depends_on:
      - mysql
    networks:
      - odb

networks:
  odb:
    external:
      name: my-db

Gives me this error (which is the same is the previous Docker Edge version):

{«message»:»Status: failed to register layer: error creating overlay mount to /var/lib/docker/overlay2/a54d40ac5df89eb2c2c9737db85772fe5782ea47c693ceba2eb1889ec2d7f25e/merged: too many levels of symbolic links, Code: 1″,»details»:»Status: failed to register layer: error creating overlay mount to /var/lib/docker/overlay2/a54d40ac5df89eb2c2c9737db85772fe5782ea47c693ceba2eb1889ec2d7f25e/merged: too many levels of symbolic links, Code: 1″}

For what it might also be worth, since I don’t know if the 2 are related in any way, but I’m just throwing it out there, I also get this error when trying to create an Adminer container, and mount a local CSS file to the container:

{«message»:»Error response from daemon: error while creating mount source path ‘/c/Servers/Docker/Containers/Adminer/pepa-linha-dark/adminer.css’: mkdir /c/Servers/Docker/Containers/Adminer/pepa-linha-dark/adminer.css: file exists»,»details»:»Error response from daemon: error while creating mount source path ‘/c/Servers/Docker/Containers/Adminer/pepa-linha-dark/adminer.css’: mkdir /c/Servers/Docker/Containers/Adminer/pepa-linha-dark/adminer.css: file exists»}

I’m running on Win 10 x64 (Version 10.0.18363.657])

Источник

I am trying to install numpy in a virtual environment that I created. I used the following series of commands to create and activate and then installing a local version of numpy (all these after cd-ing into the project folder).

virtualenv venv
source venv/bin/activate
pip install numpy

However, after the last command, I get this error:

bash: /home/fieldsofgold/Desktop/test/venv/bin/pip: /home/fieldsofgold/Desktop/test/venv/bin/python: bad interpreter: Too many levels of symbolic links

Could anyone please help me solve it and let me know what could be going wrong?

I am using Ubuntu 14.04 in VirtualBox, and the python version is 2.7.6.

asked Jul 29, 2015 at 9:13

QPTRQPTR

1,6207 gold badges26 silver badges47 bronze badges

I had the same issue, and solved it simply by removing the old env file with rm -rf env. Then I created a new environment with virtualenv env, followed by installing the requirements, normally pip install -r requirements.txt, then I was able to run my app successfully.

tripleee

174k33 gold badges271 silver badges313 bronze badges

answered Dec 3, 2016 at 17:54

You may have python running in some other instance of terminal. Make sure to close all additional instances of terminals

answered Nov 4, 2015 at 1:55

When I tried to install Tensorflow by Virtualenv, I confronted this question too. I just removed the old env, then built a new env. It works.

When I type which pip, it returns /Users/xiang/tensorflow/bin/pip. Which is exactly the path in the new env I built.

Stephen Rauch♦

47.5k31 gold badges106 silver badges135 bronze badges

answered Jul 24, 2018 at 0:41

ShawnZhuShawnZhu

691 silver badge2 bronze badges

This error is occurs ’cause time you start a new process, in my case virtual environment for django project one copy is made and when they becomes to many you get this error.
Just remove the old env and create a new environment.

answered Sep 28, 2017 at 9:28

I can vaguely speculate that the reason for this is that you have a virtualenv pointing to itself. I can further vaguely speculate that this would happen if you attempt to create a virtualenv, but then somehow decide to do it again without running deactivate. Then you have python in the virtualenv pointing back to … python in (effectively) the same virtualenv by a symbolic link.

Since this is speculative, I hope someone who actually has this problem can confirm or deny that this is what happened.

Anyway, if this is the case, the other answers here saying remove the env and start over are basically correct, but remember to deactivate first.

answered Dec 18, 2017 at 6:10

tripleeetripleee

174k33 gold badges271 silver badges313 bronze badges

I had this. In my case I am not sure what happened but my python2 had been replaced by a link so I had:

ls -l
lrwxrwxrwx 1 <me> staff    7 Oct 23 14:04 python -> python2
lrwxrwxrwx 1 <me> staff    6 Nov  6 14:28 python2 -> python
lrwxrwxrwx 1 <me> staff    7 Oct 23 14:04 python2.7 -> python2

The middle link is wrong, this is a circual reference, it should be the executable (had another venv to look at already). I deleted python2 and copied the actual file (in my case /bin/python2.7) to there:

rm python2
cp /bin/python2.7 python2
ls -l
lrwxrwxrwx 1 <me> staff    7 Oct 23 14:04 python -> python2
-rwxr-xr-x 1 <me> staff 7216 Dec  6 14:57 python2
lrwxrwxrwx 1 <me> staff    7 Oct 23 14:04 python2.7 -> python2

(NOTE: I can’t speak for every distro. you’ll need to work out your own version. Try this:

ls -l `which python`

and if that is a link follow it until you get to the actual executable. For me is was /bin/python -> python2 -> python2.7. Ergo I copied /bin/python2.7)

answered Dec 6, 2018 at 20:17

IngoIngo

263 bronze badges

Источник

Symlinks are relative to the parent directory of the link, not of the current directory of the ln process.

When you do:

cd /top/dir
ln -s test/src test/firefox

(where test/firefox is a directory), you’re making a test/firefox/src symlink whose target is test/src.

That test/src is relative to the test/firefox directory, so that’s a symlink to /top/dir/test/firefox/test/src.

If you wanted that symlink to be a link to /top/dir/test/src, you’d need to write:

ln -s ../src test/firefox/

ln -s /top/dir/test/src test/firefox/

though it’s generally a bad idea to make symlinks to absolute paths as they are easily broken when directories are renamed or filesystems are mounted elsewhere.

With GNU ln, you can use its -r option to let it make the calculation by itself:

$ ln -rs test/src test/firefox/
$ ls -ld test/firefox/src
lrwxrwxrwx 1 chazelas chazelas 6 Nov 29 15:59 test/firefox/src -> ../src

Источник

About the problem

You can have a problem where two or more files have the same readdir cookie.

This problem is more common when using a NFS filesystem (v3 or v4) over an EXT4 backend and with a lot of files in the same directory (more than 50000). It problem can also occur when using GlusterFS instead of NFS.

PS: This problem can occur also with only few files inside a single directory, but this last case is very very improbable.

In this case, you will see Too many levels of symbolic links errors even if you have no symlinks inside your directory. You can prove this verifying that the following command returns no output:

find /mnt/storage/aaaaaaa_aaa/bbbb/cccc_ccccc -type l

To check if you’re getting this specific problem, run the above command:

$ ls /mnt/storage/aaaaaaa_aaa/bbbb/cccc_ccccc >/dev/null
ls: reading directory .: Too many levels of symbolic links

After, check your syslog (/var/log/syslog) for entries like:

[400000.200000] NFS: directory /mnt/storage/aaaaaaa_aaa/bbbb/cccc_ccccc
contains a readdir loop. Please contact your server vendor.
The file: DDDDDDDDDD has duplicate cookie COOKIE_NUMBER.

The problem is related to the readdir function of the readdir API, that uses the readdir cookie to quickly locate a file inside a directory. The NFS server uses this API while communicating with EXT4 backends.

A complete and excellent explanation about the duplicate cookie problem (actually, a hash collision problem) can be found at Widening ext4’s readdir() cookie.

A related bug report can be found at NFS client reports a ‘readdir loop’ with a corrupt name.

If you can reboot your system, the good news is that, according to David Hedberg, this problem is already solved in newer Ubuntu kernel versions (>= 3.2.0-60-generic). You may need to update your NFS server also (the solution only works if both NFS server and Kernel are updated).

PS: If you really love Operating Systems, you can check the kernel/nfs patchs at http://comments.gmane.org — 32/64 bit llseek hashes.

Solution

Update your kernel and NFS kernel server and reboot the system:

apt-get -y dist-upgrade
reboot

If you can’t reboot the system, you can also detect the file with the duplicated readdir cookie (check your syslog) and move it to another dir (or rename it to change it’s cookie/hash).

Источник