12

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:

 [email protected]:/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:

 [email protected]:/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:

 [email protected]:/etc/nginx# cd sites-available [email protected]:/etc/nginx/sites-available# ls www [email protected]:/etc/nginx/sites-available# ln -s www /etc/nginx/sites-enabled/www [email protected]:/etc/nginx/sites-available# cd /etc/nginx/sites-enabled [email protected]:/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.

Improve this question
4
  • 1
    Can you show us the result of ls -l on one of these "empty" files? Commented Mar 5, 2013 at 5:31
  • @AndrewB - This has been added Commented Mar 5, 2013 at 16:27
  • 1
    +1 thanks, using absolute paths worked for me as well. Commented 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? Commented Mar 23, 2020 at 15:22

3 Answers 3

Reset to default
9

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
Improve this answer
1
  • 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. Commented Mar 5, 2013 at 16:45
6

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
Improve this answer
5
  • thanks for the suggestion but I attempted this before exactly and got: [email protected]:/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 Commented Mar 5, 2013 at 16:37
  • You'll probably have to delete it yourself, then. Commented 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. Commented 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. Commented Mar 5, 2013 at 16:54
  • this helped me instantly Commented Nov 12, 2020 at 6:01
0

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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.