I have achieved my "goal" several times before but am running into an issue I have not yet experienced before. I have a webserver setup with Nginx on Ubuntu 12.04 LTS. I have my system setup the way I normally would and am attempting to create a symbolic link for the site "virtual host" from the sites-available to the sites-enabled directory. Typically, this is achieve with the following from the primary nginx directory (as root):

ln -s /etc/nginx/sites-available/site.com /etc/nginx/sites-enabled/site.com

While I can move into the enabled directory and view the symbolic link has "worked", when I try and edit the file directly in the sites-enabled directory I see the file is blank and treated as a new file. As a result, my server does not work as expected and pages do not load. When I simply hard copy or hard link the file into the directory:

ln /etc/nginx/sites-available/site.com /etc/nginx/sites-enabled/site.com

It works without any issue. I however am stuck with two copies of the same file and no symbolic link.

What the heck gives?

Note: here is the structure of my current Nginx directory:

root@site.com:/etc/nginx# ls -l
total 44
drwxr-xr-x 2 root root 4096 Mar  4 17:28 conf.d
-rw-r--r-- 1 root root  964 Feb 12 08:41 fastcgi_params
-rw-r--r-- 1 root root 2837 Feb 12 08:41 koi-utf
-rw-r--r-- 1 root root 2223 Feb 12 08:41 koi-win
-rw-r--r-- 1 root root 3463 Feb 12 08:41 mime.types
-rw-r--r-- 1 root root 1022 Mar  4 21:15 nginx.conf
-rw-r--r-- 1 root root  596 Feb 12 08:41 scgi_params
drwxr-xr-x 2 root root 4096 Mar  4 21:15 sites-available
drwxr-xr-x 2 root root 4096 Mar  4 21:19 sites-enabled
-rw-r--r-- 1 root root  623 Feb 12 08:41 uwsgi_params
-rw-r--r-- 1 root root 3610 Feb 12 08:41 win-utf

Thank you for your help ahead of time!

Edit 1: Showing the contents of the sites-enabled folder with ls -l:

root@site.com:/etc/nginx/sites-enabled# ls -l
total 0
lrwxrwxrwx 1 root root 3 Mar  5 10:23 www -> www

Final Answer

So after help from the @Insyte and @Michael Hampton, I figured out how to reproduce my error occassionally. The scenario played out as follows:

root@site.com:/etc/nginx# cd sites-available
root@site.com:/etc/nginx/sites-available# ls
root@site.com:/etc/nginx/sites-available# ln -s www /etc/nginx/sites-enabled/www
root@site.com:/etc/nginx/sites-available# cd /etc/nginx/sites-enabled
root@site.com:/etc/nginx/sites-enabled# ls -l
total 0
lrwxrwxrwx 1 root root 3 Mar  5 10:48 www -> www

I am not aware of "why" but turns out that if I use full absolute paths each time then the issue does not exist.

  • 1
    Can you show us the result of ls -l on one of these "empty" files?
    – Andrew B
    Mar 5, 2013 at 5:31
  • @AndrewB - This has been added
    – JM4
    Mar 5, 2013 at 16:27
  • 1
    +1 thanks, using absolute paths worked for me as well. Aug 22, 2013 at 17:49
  • +1 This worked for me. Can anyone please explain why does this works on providing an absolute path and does not on providing a short path? Mar 23, 2020 at 15:22

3 Answers 3


So what you have there is a symbolic link that links back to itself. I don't see how that's possible with the command you listed at the top of your question, so I suspect this particular symbolic link was created differently.

I can replicate your scenario like this:

sazerac:~ insyte$ cd testlinks/
sazerac:~/testlinks insyte$ ls
sazerac:~/testlinks insyte$ ln -s www www
sazerac:~/testlinks insyte$ ls -l
total 8
lrwxr-xr-x  1 insyte  staff  3 Mar  5 10:33 www -> www

Let's try an experiment. Execute the following commands exactly as listed:

echo "hello insyte" > /etc/nginx/sites-available/insyte
ln -s /etc/nginx/sites-available/insyte /etc/nginx/sites-enabled
ls -l /etc/nginx/sites-enabled|grep insyte
cat /etc/nginx/sites-enabled/insyte
  • so I think I figured out what is going on and really appreciate your help. I'll post my final findings in the OP above.
    – JM4
    Mar 5, 2013 at 16:45

You've somehow managed to create a symbolic link that links to itself. I didn't even know you could do that, but I'm quite sure it won't have the result you want.

To fix it, remove the symlink and recreate it correctly.

rm -f /etc/nginx/sites-enabled/www

Or just use the -f option to ln and it may remove the invalid symlink for you.

ln -fs /etc/nginx/sites-available/www /etc/nginx/sites-enabled/www
  • thanks for the suggestion but I attempted this before exactly and got: root@site.com:/etc/nginx/sites-enabled# ln -fs /etc/nginx/sites-available/www /etc/nginx/sites-enabled/www ln: accessing `/etc/nginx/sites-enabled/www': Too many levels of symbolic links
    – JM4
    Mar 5, 2013 at 16:37
  • You'll probably have to delete it yourself, then. Mar 5, 2013 at 16:37
  • see final answer in my OP. I was not aware a full path had to be used each time (and fairly certain I did given the OP had a full path stated but I was able to reproduce my error above.
    – JM4
    Mar 5, 2013 at 16:51
  • 2
    The symlink is created exactly as you specify, whether it's a relative or absolute path. If relative, it will be relative to the directory the symlink is created in, not the directory you were in when you created it. Mar 5, 2013 at 16:54
  • this helped me instantly
    – KawaiKx
    Nov 12, 2020 at 6:01

Out of habit:

  • I always use ln -sfn to ensure any old links are updated without trouble.
  • I always use an absolute path:
ln -sfn /absolute/path/to/original /absolute/path/to/link

That keeps me out of much trouble.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.