When creating symlinks for Nginx virtual hosts between sites-available and sites-enabled, you might encounter this bizarre behavior:

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

The symlink appears valid but points to itself instead of the target file. Editing the symlinked file shows an empty document.

The issue occurs due to path resolution ambiguity when:

• Creating symlinks from within sites-available directory
• Using relative paths instead of absolute paths
• Executing commands without proper working directory context

Here's how to accidentally create a broken symlink:

cd /etc/nginx/sites-available
ln -s www /etc/nginx/sites-enabled/www

The resulting symlink will be self-referential.

Method 1: Absolute Paths (Recommended)

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

Method 2: Relative Paths with Proper Context

cd /etc/nginx
ln -s sites-available/example.com sites-enabled/example.com

Always verify symlinks with these commands:

# Check symlink target
readlink -f /etc/nginx/sites-enabled/example.com

# View resolved path
ls -l /etc/nginx/sites-enabled/

For complex cases, use these troubleshooting steps:

# Check filesystem permissions
namei -l /etc/nginx/sites-enabled/example.com

# Verify inode references
stat /etc/nginx/sites-available/example.com
stat /etc/nginx/sites-enabled/example.com

# Test path resolution
realpath -s /etc/nginx/sites-enabled/example.com

• Always use absolute paths for critical system symlinks
• Implement a standardized enable/disable script:

#!/bin/bash
# nginx-site-manager
SITE=$1
ACTION=$2

case $ACTION in
    enable)
        ln -sf "/etc/nginx/sites-available/$SITE" "/etc/nginx/sites-enabled/$SITE"
        nginx -t && systemctl reload nginx
        ;;
    disable)
        rm -f "/etc/nginx/sites-enabled/$SITE"
        systemctl reload nginx
        ;;
    *)
        echo "Usage: $0 [site] [enable|disable]"
        exit 1
        ;;
esac

---

When setting up Nginx virtual hosts on Ubuntu, many developers encounter a puzzling scenario where symbolic links appear to work but don't actually function as expected. The classic command:

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

should create a working symbolic link, but sometimes results in an empty or self-referential link when viewed in the sites-enabled directory.

The key insight comes from examining the link creation process more closely. When executing the command from within the sites-available directory:

cd /etc/nginx/sites-available
ln -s www /etc/nginx/sites-enabled/www

This creates a symbolic link that points to itself rather than the actual configuration file. The ls -l output reveals the issue:

lrwxrwxrwx 1 root root 3 Mar  5 10:48 www -> www

Using full absolute paths consistently solves this problem:

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

Alternatively, if you prefer working from within the directory, use this approach:

cd /etc/nginx/sites-available
ln -s $(pwd)/site.com /etc/nginx/sites-enabled/site.com

Always verify your symbolic links with:

ls -l /etc/nginx/sites-enabled/
readlink -f /etc/nginx/sites-enabled/site.com

The proper output should show:

lrwxrwxrwx 1 root root 32 Mar  5 11:00 site.com -> /etc/nginx/sites-available/site.com

For complete reliability in your Nginx setup:

# Always use absolute paths
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

# Test configuration after changes
sudo nginx -t

# Reload configuration
sudo systemctl reload nginx

Remember that Nginx only reads configuration files from sites-enabled during server startup or reload, so proper symbolic linking is crucial.