When setting up SFTP access for web server directories on Debian, many administrators encounter the same frustrating scenario: symbolic links appear in FileZilla but become inaccessible. Let me walk through the technical details of why this happens and how to properly configure it.

The core issue lies in how SFTP servers handle symbolic links and permissions. Unlike regular shell access, SFTP (particularly when chrooted) imposes additional security restrictions. The symbolic link itself might be visible, but the target directory's permissions prevent traversal.

First, verify your current setup with these commands:

ls -l /home/username
# Expected output showing the symlink:
# lrwxrwxrwx 1 root root 8 May 1 10:00 www -> /var/www

ls -ld /var/www
# Check directory permissions
# Should show at least r-x for your user

Instead of just creating a symlink, we need to properly configure both the filesystem and SSH server:

# 1. Set proper ownership on /var/www
sudo chown -R username:username /var/www

# 2. Modify sshd_config to allow symlink following
sudo nano /etc/ssh/sshd_config
# Add or modify these lines:
Match User username
    ChrootDirectory /home/username
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp
    FollowSymlinks yes

For more reliable access, consider using bind mounts instead of symlinks:

# 1. Create the mount point
mkdir /home/username/www

# 2. Add to /etc/fstab
/var/www    /home/username/www    none    bind    0    0

# 3. Mount it
mount /home/username/www

After making changes, test your configuration:

sudo service ssh restart
sftp username@localhost
# Should now be able to cd into www directory

If issues persist in FileZilla specifically, try these client-side settings:

1. Go to Edit > Settings > Connection > SFTP
2. Enable "Follow symbolic links" option
3. Set "Maximum number of connections" to 1

Remember that allowing symlink following in SFTP does introduce potential security considerations. Always ensure:

• The chroot environment is properly configured
• Users don't have write access to directories containing symlinks they shouldn't follow
• Regular audits of symlinks in user directories

When configuring SFTP access for a restricted Debian user, symbolic links to system directories like /var/www often create permission challenges. The specific scenario occurs when:

1. User has jail access only to /home/username
2. A symlink points to /var/www
3. FileZilla displays "Permission Denied" when traversing the link


The key elements affecting SFTP access:

# Directory ownership (before fix)
drwxr-xr-x  5 root     root     4096 Jun 15 10:23 /var/www
lrwxrwxrwx  1 username username    8 Jun 15 10:25 /home/username/www -> /var/www


Three critical permission layers:
1. Original directory permissions (0700 for root)
2. Symlink permissions (777 is irrelevant here)
3. SFTP server configuration (often chroot)


Method 1: Proper Ownership and ACLs

# As root:
chown -R username:username /var/www
find /var/www -type d -exec chmod 755 {} \;
find /var/www -type f -exec chmod 644 {} \;

# For more granular control:
setfacl -R -m u:username:rwx /var/www


Method 2: SSH Server Configuration
Edit /etc/ssh/sshd_config:

Match User username
    ChrootDirectory /home/username
    ForceCommand internal-sftp
    AllowTCPForwarding no
    X11Forwarding no
    PermitTunnel no



Bind Mount instead of Symlink:

# /etc/fstab entry:
/var/www    /home/username/www    none    bind    0    0


Webserver Configuration Example:

# Nginx configuration showing proper permissions:
server {
    listen 80;
    root /var/www/html;
    index index.php index.html;
    
    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}



Check real-time logs when connecting:

tail -f /var/log/auth.log | grep sftp
journalctl -f -u ssh


Verify effective permissions:

namei -l /home/username/www
getfacl /var/www