1 15/10/2026 12 min

Quando usare un collegamento simbolico su Ubuntu

Un collegamento simbolico, o symlink, è il modo più semplice per far puntare un percorso a un altro senza duplicare dati. Su Ubuntu 22.04 e 24.04 la sintassi non cambia, ma cambiano spesso i contesti operativi: file di configurazione gestiti da systemd, directory applicative dentro /opt, mount point, script legacy e percorsi che devono restare stabili anche dopo un aggiornamento.

Il caso tipico è questo: un programma si aspetta un file in una posizione fissa, ma tu vuoi tenere il contenuto altrove. Il symlink risolve il problema senza copiare il file e senza dover modificare ogni riferimento. È utile anche per migrazioni graduali, versioning di release, compatibilità con software vecchio e standardizzazione dei percorsi tra server diversi.

La regola da tenere in testa è semplice: il collegamento simbolico è un riferimento, non una copia. Se il target sparisce, il link resta lì ma diventa rotto. Questo è un vantaggio quando vuoi separare il nome logico dalla posizione fisica, ma è anche il motivo per cui conviene sempre verificare target, permessi e path assoluti prima di usare ln -s.

Sintassi base di ln -s

Il comando da ricordare è questo:

ln -s TARGET LINK_NAME

TARGET è il file o la directory reale; LINK_NAME è il nome del collegamento che vuoi creare. Se il target è una directory, il link punterà a quella directory. Se il target è un file, il link si comporterà come alias di quel file.

Esempio pratico con un file di configurazione:

ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/app.conf

In questo caso il file reale resta in /etc/nginx/sites-available/, mentre /etc/nginx/sites-enabled/ contiene il symlink usato dal servizio. È un pattern molto comune su Ubuntu e riduce il rischio di modificare direttamente il punto di attivazione invece della sorgente della configurazione.

Creare un symlink per file e directory

Per creare un collegamento simbolico su Ubuntu 24.04 o 22.04, la procedura è identica. La differenza operativa la fa il contesto, non la distribuzione. Qui sotto ci sono i casi più comuni.

1. Collegare un file

Supponiamo di avere uno script salvato in /srv/tools/backup.sh e di volerlo richiamare da /usr/local/bin/backup:

sudo ln -s /srv/tools/backup.sh /usr/local/bin/backup

Dopo il comando, puoi verificare con:

ls -l /usr/local/bin/backup

L’output atteso mostra una freccia con il target, per esempio backup -> /srv/tools/backup.sh. Se invece vedi un file normale, hai creato o copiato altro. Se vedi un link rotto, il target non esiste o il path è sbagliato.

2. Collegare una directory

Per una directory la sintassi è la stessa. Mettiamo che tu abbia una release applicativa in /opt/app/releases/2024-10-01 e voglia esporla come versione corrente in /opt/app/current:

sudo ln -s /opt/app/releases/2024-10-01 /opt/app/current

Questo schema è comodo per i deploy: cambi il target del symlink e punti una nuova release senza toccare gli script che leggono /opt/app/current. Se il deploy fallisce, ti basta cambiare di nuovo il link al release precedente.

3. Creare un symlink relativo

Un symlink può usare un percorso assoluto o relativo. Il relativo è utile quando vuoi spostare insieme directory e link mantenendo la portabilità. Per esempio, se sei dentro /opt/app e vuoi collegare current a releases/2024-10-01:

cd /opt/app
sudo ln -s releases/2024-10-01 current

Il vantaggio è che il link resta valido se sposti l’intera directory /opt/app altrove, purché la relazione interna resti la stessa. Lo svantaggio è che un cambio di posizione non previsto può rompere il collegamento senza errori evidenti fino al primo accesso.

Come verificare che il collegamento sia corretto

La verifica non si limita a ls -l. Conviene controllare sia la presenza del link sia l’effettiva raggiungibilità del target. Una sequenza rapida è questa:

  1. Controlla la definizione del link con ls -l.
  2. Verifica il target con readlink o readlink -f.
  3. Apri il file o accedi alla directory tramite il link.
  4. Conferma i permessi su link e target, soprattutto se il servizio gira con un utente non privilegiato.

Comandi utili:

ls -l /path/to/link
readlink /path/to/link
readlink -f /path/to/link

readlink mostra il target dichiarato dal symlink; readlink -f risolve il percorso finale, seguendo anche eventuali altri link intermedi. Se il comando fallisce, il collegamento è rotto oppure il target non è raggiungibile con quel path.

Link simbolico o hard link: differenza pratica

Su Linux il confronto più utile non è teorico, ma operativo. Il collegamento simbolico punta a un path. L’hard link punta allo stesso inode del file originale. Questo significa che il symlink può attraversare filesystem diversi, mentre l’hard link in genere no. Inoltre l’hard link non funziona bene con directory, mentre il symlink sì.

Se devi collegare una configurazione, un eseguibile, una release o una directory intera, il symlink è quasi sempre la scelta giusta. L’hard link è più adatto quando vuoi due nomi per lo stesso file sullo stesso filesystem e non vuoi che la rimozione di uno rompa l’accesso all’altro. In ambito server, però, il symlink è molto più flessibile e leggibile nelle operazioni quotidiane.

Errori comuni su Ubuntu 22.04 e 24.04

Gli errori che si vedono più spesso sono sempre gli stessi, ma cambiano i sintomi.

  1. Target inesistente: il link viene creato, ma resta rotto. Verifica con ls -l e readlink -f.
  2. Permessi insufficienti: se non hai write sul path di destinazione, ln fallisce. Usa sudo solo quando serve e non per coprire un problema di ownership.
  3. Nome link già presente: ln -s non sovrascrive un file esistente con lo stesso nome. Prima controlla cosa c’è già in quel path.
  4. Directory di destinazione sbagliata: se il secondo argomento è una directory esistente, ln crea il link dentro quella directory usando il nome del target.

Un esempio classico di ambiguità è questo:

ln -s /etc/app.conf /tmp

Qui non stai creando un link chiamato /tmp; stai chiedendo a ln di mettere il link dentro la directory /tmp. Il risultato atteso è /tmp/app.conf se /tmp è una directory. Per evitare dubbi, specifica sempre il nome del collegamento in modo esplicito.

Sovrascrivere o aggiornare un collegamento esistente

Quando devi aggiornare un symlink, la pratica più pulita è rimuovere il vecchio link e crearne uno nuovo. Non toccare il target se non è necessario. In scenari di deploy, questo riduce il blast radius: cambi solo il puntatore, non il contenuto applicativo.

Sequenza sicura:

ls -l /opt/app/current
sudo rm /opt/app/current
sudo ln -s /opt/app/releases/2024-10-15 /opt/app/current
ls -l /opt/app/current

Se vuoi evitare finestre di inconsistenza, puoi creare il nuovo link con un nome temporaneo e poi fare uno switch atomico con mv -Tf su filesystem compatibile. Esempio:

sudo ln -s /opt/app/releases/2024-10-15 /opt/app/current.new
sudo mv -Tf /opt/app/current.new /opt/app/current

Questa tecnica è molto usata quando un servizio legge il path mentre tu aggiorni la destinazione. Riduce il rischio di vedere un path vuoto nel mezzo del cambio.

Symlink nei servizi systemd e negli script

In Ubuntu moderno molti servizi leggono file e directory da percorsi standardizzati. Un symlink può aiutare a mantenere compatibilità tra versioni o ambienti, ma va usato con criterio. Se un servizio systemd legge una configurazione da /etc/myapp/config.yml e tu vuoi mantenerla in /srv/myapp/config.yml, il symlink funziona bene, purché il servizio abbia i permessi per seguire il target.

Per esempio:

sudo ln -s /srv/myapp/config.yml /etc/myapp/config.yml
sudo systemctl restart myapp
sudo systemctl status myapp --no-pager

Se il servizio non parte, controlla il log:

journalctl -u myapp -b --no-pager

Il punto non è solo che il link esista, ma che il processo lo possa leggere. Su server con policy restrittive, AppArmor o permessi stretti sulla directory di destinazione, il symlink può essere corretto e il servizio comunque fallire per accesso negato.

Uso nei deploy: pattern current release

Uno degli usi migliori del symlink è il pattern current per i deploy. In pratica, ogni release va in una directory versionata e un link stabile indica la versione attiva. È una soluzione pulita perché separa il nome pubblico dalla versione concreta. Esempio:

/var/www/app/releases/1.0.0
/var/www/app/releases/1.0.1
/var/www/app/current -> /var/www/app/releases/1.0.1

Con questo approccio puoi preparare la nuova release, testarla localmente, cambiare il link e, se serve, tornare indietro in pochi secondi. Il rollback è banale: ripunti current alla release precedente. In ambienti web questo è spesso più sicuro che sovrascrivere file in place.

Un esempio di switch controllato:

sudo ln -sfn /var/www/app/releases/1.0.1 /var/www/app/current

L’opzione -n evita che ln tratti il link esistente come directory di destinazione, mentre -f forza la sostituzione. Usala con criterio: è comoda, ma va capita bene per non cancellare il riferimento sbagliato.

Permessi, ownership e sicurezza operativa

Il symlink non bypassa i permessi del target. Questo è un dettaglio importante: avere accesso al link non significa avere accesso al file o alla directory a cui punta. Se un servizio gira con un utente dedicato, il path reale deve essere leggibile da quell’utente, altrimenti il link è inutile.

Controlli pratici:

namei -l /path/to/link
stat /path/to/link
stat /path/to/target

namei -l è molto utile perché mostra tutti i componenti del percorso e i relativi permessi. Se un link vive in una directory accessibile ma il target no, il problema emerge subito. In troubleshooting è spesso più veloce di una lettura a occhio di ls -l.

Per sicurezza operativa, evita di usare symlink in modo opaco dentro directory scrivibili da utenti non fidati, soprattutto quando il link viene consumato da processi privilegiati. Un symlink mal posizionato può causare comportamento inatteso se uno script root segue percorsi scrivibili da altri utenti. La regola resta la stessa: minimizza le directory condivise e tieni sotto controllo ownership e accesso in scrittura.

Gestione pratica con find, test e script

Quando lavori su più server o su directory grandi, è utile cercare i symlink esistenti e capire dove puntano. Il comando find è il più comodo:

find /etc -type l -ls

Qui -type l filtra solo i link simbolici. L’output mostra i dettagli utili per audit rapido e per individuare link rotti dopo un update o una migrazione.

Se vuoi verificare in uno script che un symlink esista e punti a un target valido, una logica minima può essere questa:

if [ -L /path/to/link ] && [ -e /path/to/link ]; then echo "link valido"
else echo "link mancante o rotto"
fi

-L controlla che il path sia un symlink, mentre -e verifica che il target esista. La combinazione è pratica per monitoraggi e health check semplici. Se vuoi distinguere in modo più netto un link rotto da un file normale, puoi aggiungere logica su readlink e sul tipo di oggetto con test.

Rimozione corretta di un symlink

Rimuovere un symlink non elimina il target, a meno che tu non stia cancellando il file reale per errore. Questo è il punto più importante quando lavori in produzione. Per cancellare il link usa rm sul path del link, non sul target. Esempio:

rm /usr/local/bin/backup

Se il path è un symlink, rm elimina solo il riferimento. Se invece sei incerto, controlla prima con ls -l o file. Un controllo in più costa meno di una cancellazione sbagliata, soprattutto se il target è condiviso da altri servizi.

Checklist rapida per Ubuntu 22.04 e 24.04

Se devi creare un collegamento simbolico al volo e vuoi evitare errori banali, usa questa sequenza:

  1. Decidi se il target deve essere assoluto o relativo.
  2. Verifica che il target esista con ls -ld o stat.
  3. Controlla che la directory di destinazione sia scrivibile.
  4. Crea il link con ln -s.
  5. Verifica con ls -l e readlink -f.
  6. Testa il consumo reale del link da parte dell’applicazione o del servizio.

Se il contesto è un deploy, prepara sempre un rollback semplice: conserva la release precedente o il file originale, e aggiorna il puntatore solo dopo avere verificato che il nuovo target sia valido. In pratica, il symlink funziona bene quando è parte di una procedura reversibile, non quando viene usato come scorciatoia improvvisata.

Esempio completo end-to-end

Scenario: vuoi esporre una configurazione applicativa in /etc/myapp/config.yml, ma tenerla in /srv/myapp/config.yml per separare i dati gestiti dal resto dell’host.

  1. Verifica il target.
ls -l /srv/myapp/config.yml
  1. Assicurati che la directory di destinazione esista.
sudo mkdir -p /etc/myapp
  1. Crea il symlink.
sudo ln -s /srv/myapp/config.yml /etc/myapp/config.yml
  1. Controlla il risultato.
ls -l /etc/myapp/config.yml
readlink -f /etc/myapp/config.yml
  1. Riavvia o ricarica il servizio che usa il file, poi verifica i log.
sudo systemctl restart myapp
journalctl -u myapp -b --no-pager

Se qualcosa va storto, elimina il link e ripristina il file originale o il target precedente. Questo è il vantaggio principale dei symlink in amministrazione Linux: cambiare riferimento senza riscrivere il contenuto, con un rollback rapido e leggibile.

In sintesi operativa

Su Ubuntu 22.04 e 24.04 creare un collegamento simbolico è una cosa semplice, ma farlo bene richiede disciplina. Usa percorsi chiari, verifica sempre il target, preferisci switch reversibili quando lavori su release o configurazioni, e controlla i permessi del percorso reale. Il comando base resta ln -s TARGET LINK_NAME, ma il valore vero sta nel modo in cui lo integri nel flusso operativo: deploy, compatibilità, manutenzione e rollback.