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/
Or
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
I am running virtualenv burrito and getting an error that there are too many levels of symbolic links. I have no idea what that means.
mkvirtualenv --python /usr/local/bin/Python3 mantis
Error:
Running virtualenv with interpreter /usr/local/bin/Python3
Using base prefix '/Library/Frameworks/Python.framework/Versions/3.4'
New python executable in mantis/bin/Python3
Also creating executable in mantis/bin/python
Traceback (most recent call last):
File "/Users/croberts/.venvburrito/lib/python2.7/site-packages/virtualenv.py", line 2352, in <module>
main()
File "/Users/croberts/.venvburrito/lib/python2.7/site-packages/virtualenv.py", line 825, in main
symlink=options.symlink)
File "/Users/croberts/.venvburrito/lib/python2.7/site-packages/virtualenv.py", line 985, in create_environment
site_packages=site_packages, clear=clear, symlink=symlink))
File "/Users/croberts/.venvburrito/lib/python2.7/site-packages/virtualenv.py", line 1439, in install_python
raise e
File "/Users/croberts/.venvburrito/lib/python2.7/site-packages/virtualenv.py", line 1431, in install_python
stdout=subprocess.PIPE)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/subprocess.py", line 859, in __init__
restore_signals, start_new_session)
File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/subprocess.py", line 1457, in _execute_child
raise child_exception_type(errno_num, err_msg)
OSError: [Errno 62] Too many levels of symbolic links
I was getting this error before and solved it by doing Python3.4 instead of Python3. Now it won’t work no matter which python I try to use. Even if I try to use the default (2.7)
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).
That’s because the service name is actually ssh.service, not sshd.service.
Do this instead:
systemctl enable ssh.service
Explanation
When you install openssh-server, the service is automatically enabled in systemd. During the enabling process, a symbolic link for an enabled sshd.service is also created. This symbolic link goes away if you do systemctl disable ssh.service or systemctl disable sshd.service.
You can see the symbolic link is reportedly created here:
root@node51 [~]# systemctl enable ssh.service
Synchronizing state of ssh.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable ssh
Created symlink from /etc/systemd/system/sshd.service to /lib/systemd/system/ssh.service.
Because of systemd’s design, systemd will not enable a service that is a symbolic link.
This is discussed on Red Hat Bugzilla.
I suggest you use rsync rather than cp to backup data as you want to do it. Rsync has a few options to deal with symlinks. A sym(bolic) link is simply a link to another file. It is a bit like a ‘shortcut’ in windows language.
-l, --links copy symlinks as symlinks
-L, --copy-links transform symlink into referent file/dir
--copy-unsafe-links only "unsafe" symlinks are transformed
--safe-links ignore symlinks that point outside the tree
-k, --copy-dirlinks transform symlink to dir into referent dir
-K, --keep-dirlinks treat symlinked dir on receiver as dir
-H, --hard-links preserve hard links
Here is an easy example:
sudo rsync --verbose --recursive --links --perms --executability --owner --group --times /media/some-user-name/the-c-drive-you-want /media/some-user-name/the-external-drive
Use the option --dry-run for a hypothetical run that does not write anything to your external drive.
Read the man rsync for more information on the different options.