【完全リファレンス】Linuxでシンボリックリンクを作成・確認・削除する方法｜ln・readlink・unlink完全ガイド

Linux サーバー運用・設定管理・デプロイで必須となるシンボリックリンク:

# 設定ファイルの管理
ln -s /home/user/dotfiles/.vimrc ~/.vimrc

# Nginx sites-enabled パターン
ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp

# Rails デプロイの current
ln -s /var/app/releases/20260620 /var/app/current

# Node.js のバージョン切り替え
ln -s /usr/local/n/versions/node/20.10.0/bin/node /usr/local/bin/node

「ファイルへのショートカット」のように振る舞い、Windows のショートカットや macOS のエイリアスに相当します。

しかし、いざ使おうとすると:

• ln -s の引数の順序（source と target のどっち？）
• ハードリンクとの違いは？
• リンク先のフルパスを確認したい
• 上書きできなくて困る（File exists エラー）
• ディレクトリへのシンボリックリンクの落とし穴
• リンク切れ（broken link）の検出
• rm と unlink どちらを使う？
• chmod で権限を変えても効かない？

など、初学者から実務者まで悩むポイントが多くあります。

本記事では、Linux でシンボリックリンクを作成・確認・削除する方法を、リファレンスとして実用的に整理します。ln -s での作成、ls -l / readlink / file での確認、rm / unlink での削除、ハードリンクとの違い、リンク切れ対応、権限の扱い、実践パターン、FAQまで完全網羅。この1本でシンボリックリンクをマスターできます。

結論：今すぐ使える基本パターン10選

時間がない方向けに、頻出パターンを先に示します。

# ① 作成（基本）
ln -s /path/to/source /path/to/link

# ② 確認
ls -l /path/to/link
readlink /path/to/link
readlink -f /path/to/link   # 最終的なリンク先

# ③ 削除
rm /path/to/link
unlink /path/to/link

# ④ 上書き（既存リンクの強制更新）
ln -sfn /new/target /path/to/link

# ⑤ ディレクトリへのリンク
ln -s /var/log/myapp ~/logs

# ⑥ カレントディレクトリにリンク作成
cd ~/bin
ln -s /opt/myapp/bin/myapp

# ⑦ 相対パスで作成
ln -s ../sibling/file.txt mylink

# ⑧ リンク切れ検出
find /path -xtype l

# ⑨ リンク切れの一括削除
find /path -xtype l -delete

# ⑩ ハードリンク（-s なし）
ln /path/to/source /path/to/hardlink

詳細は以下で順に解説します。

まず押さえる：シンボリックリンクとは

概要

シンボリックリンク（symbolic link、シムリンク、ソフトリンク） は、別のファイルやディレクトリへのパスを格納する特殊なファイル。Windows のショートカット、macOS のエイリアスに似ています。

config.symlink → /etc/myapp/config.yml
   ↑                    ↑
リンク本体          リンク先（target）

リンクにアクセスすると、自動的にリンク先のファイルへ転送されます。

シンボリックリンクの特徴

• 異なるファイルシステムを跨げる
• ディレクトリにも作れる
• リンク先が削除されるとリンク切れ（broken）
• 元ファイルとは別の inode を持つ（小さい独立ファイル）
• 内容は「リンク先のパス文字列」のみ

ハードリンクとの違い

ハードリンクは同じ inode を共有するもう一つの名前:

同じinode（実データ）
  ↓        ↓
file_a   file_b

inode の概念

ls -i file.txt
# 12345 file.txt

ln file.txt hardlink.txt
ls -i file.txt hardlink.txt
# 12345 file.txt
# 12345 hardlink.txt   ← 同じinode

ln -s file.txt symlink.txt
ls -i file.txt symlink.txt
# 12345 file.txt
# 67890 symlink.txt    ← 別inode

-i でinode 番号を表示。シンボリックリンクは別のinode を持つことが分かります。

作成方法（ln -s）

基本構文

ln -s [リンク先] [リンク名]

順序を忘れたら 「リンク先が先、リンク名が後」（cp や mv と同じ）。

例1：ファイルへのシンボリックリンク

# /etc/myapp/config.yml への symlink を作成
ln -s /etc/myapp/config.yml ~/config

# 確認
ls -l ~/config
# lrwxrwxrwx 1 user user 21 Jun 20 14:00 /home/user/config -> /etc/myapp/config.yml

l で始まるパーミッション、矢印 -> でリンク先が分かります。

例2：ディレクトリへのシンボリックリンク

ln -s /var/log/myapp ~/logs

ls -l ~/logs
# lrwxrwxrwx 1 user user 14 Jun 20 14:00 /home/user/logs -> /var/log/myapp

ディレクトリへのリンクも -s のみでOK。

カレントディレクトリへの作成

第二引数を省略すると、カレントディレクトリに同じ名前で作成:

cd ~/bin
ln -s /opt/myapp/bin/myapp
# → ~/bin/myapp が作成される

ls -l myapp
# lrwxrwxrwx 1 user user ... myapp -> /opt/myapp/bin/myapp

第二引数にディレクトリ指定

ln -s /etc/myapp/config.yml ~/
# → ~/config.yml が作成される（ディレクトリ内に同名で）

カレントディレクトリへのドット指定:

ln -s /etc/myapp/config.yml .

複数ファイルを一気にリンク

ln -s /opt/myapp/bin/* ~/bin/
# /opt/myapp/bin/ の全ファイルへのリンクを ~/bin/ に作成

各ファイル名で個別にリンクが作成されます。

相対パス vs 絶対パス

絶対パス（推奨：システム全体）

ln -s /var/log/myapp ~/logs
# どこからアクセスしても確実

相対パス（推奨：プロジェクト内、移動を考慮）

cd /var/projects
ln -s ../shared/data project1/data

ディレクトリ構造ごと移動できる。

どちらを使うか

相対パスの注意点

# ❌ よくある間違い
cd ~
ln -s ../var/log/myapp logs
# → ~/logs が ~/../var/log/myapp（つまり /var/log/myapp）を指す
# 移動先によっては解決できない

# ✅ 相対パスは「リンクが置かれる場所からの相対」
cd /path/to/somewhere
ln -s ../sibling/file mylink
# /path/to/somewhere/../sibling/file = /path/to/sibling/file

相対パスはリンク本体の場所が基準。pwd ではなく、リンクファイルがある場所からの相対パス。

確認方法

ls -l

最も基本的な確認方法:

ls -l ~/config
# lrwxrwxrwx 1 user user 21 Jun 20 14:00 /home/user/config -> /etc/myapp/config.yml

特徴:

• 先頭の l がシンボリックリンクを示す
• -> の右側がリンク先のパス（保存されている文字列そのまま）
• パーミッション rwxrwxrwx は常にこれ（実際の判定はリンク先で）

readlink（パスのみ）

リンク先のパスのみ表示:

readlink ~/config
# /etc/myapp/config.yml

スクリプトで使う時に便利。

readlink -f（最終的なリンク先）

シンボリックリンクが連鎖している場合に、最終的な実体パスを取得:

# 連鎖
ln -s /etc/myapp/config.yml a
ln -s a b
ln -s b c

readlink c
# b（直接のリンク先）

readlink -f c
# /etc/myapp/config.yml（最終的なパス）

realpath（モダンな代替）

realpath ~/config
# /etc/myapp/config.yml

readlink -f とほぼ同等。GNU coreutils 8.15+ で利用可能。

file コマンド

file ~/config
# /home/user/config: symbolic link to /etc/myapp/config.yml

ファイルタイプを判定。シンボリックリンクとリンク先を表示。

stat コマンド

stat ~/config
#   File: /home/user/config -> /etc/myapp/config.yml
#   Size: 21         Blocks: 0          IO Block: 4096   symbolic link
# Device: ...       Inode: 12345        Links: 1
# Access: (0777/lrwxrwxrwx)  Uid: (1000/user)   Gid: (1000/user)

詳細情報（inode、サイズ、権限など）。

ls -lL（リンク先の情報）

-L でリンク先（dereference）の情報を表示:

ls -l ~/config
# lrwxrwxrwx ... config -> /etc/myapp/config.yml

ls -lL ~/config
# -rw-r--r-- ... config   ← リンク先の実情報

削除方法

rm（一般的）

rm ~/config

⚠️ リンク本体だけ削除。リンク先のファイルは影響なし。

unlink

unlink ~/config

rm とほぼ同じだが、シンボリックリンク削除専用と考えてOK。

注意：末尾のスラッシュ

# ⚠️ ディレクトリへのリンクで末尾スラッシュは危険
rm -rf ~/logs/   # リンク経由でリンク先の中身を消す可能性

# ✅ 安全
rm ~/logs        # リンクのみ削除

ディレクトリリンクの削除では末尾スラッシュを付けない。

複数削除

rm ~/config ~/logs ~/data

ワイルドカード

# 特定パターンのリンク削除
find ~/bin -maxdepth 1 -type l -delete

# 注意：通常のrm は同じディレクトリ内
rm ~/bin/old_*

上書き・更新

-f オプション（強制）

ln -s /new/target ~/config
# ln: failed to create symbolic link '/home/user/config': File exists

# -f で強制上書き
ln -sf /new/target ~/config

-n オプション（重要：ディレクトリ用）

ディレクトリへの既存リンクを更新する時:

ls -l ~/current
# lrwxrwxrwx ... current -> /var/releases/v1.0

# ❌ -f だけだと「リンク先のディレクトリ内に新しいリンクを作る」
ln -sf /var/releases/v2.0 ~/current
ls -l ~/current
# lrwxrwxrwx ... current -> /var/releases/v1.0/v2.0  ← 間違い！

# ✅ -n で「リンクをディレクトリと見なさない」
ln -sfn /var/releases/v2.0 ~/current

-n（--no-dereference）は ディレクトリへのシンボリックリンクを更新する際の必須オプション。

安全な更新パターン

# 一旦削除してから作成
unlink ~/current
ln -s /var/releases/v2.0 ~/current

# または mv で原子的に
ln -s /var/releases/v2.0 ~/current.new
mv -Tf ~/current.new ~/current

Rails の Capistrano パターン

# 新リリースをデプロイ
ln -sfn /var/myapp/releases/20260620100000 /var/myapp/current

-sfn はシンボリックリンク + 強制 + ディレクトリ更新の3点セット。

ディレクトリへのリンクの落とし穴

末尾スラッシュの違い

ln -s /var/log/myapp logs

# logs（スラッシュなし）→ シンボリックリンク自体
ls -l logs
# lrwxrwxrwx ... logs -> /var/log/myapp

# logs/（スラッシュあり）→ リンク先のディレクトリ
ls -l logs/
# total 12
# -rw-r--r-- ... app.log
# ...

cd での挙動

cd ~/logs
pwd        # → /home/user/logs（シンボリックリンクのパス）
pwd -P     # → /var/log/myapp（物理パス）

pwd -P で実体のパスを取得。

cd .. の罠

cd ~/logs  # シンボリックリンク経由
pwd        # /home/user/logs
cd ..
pwd        # /home/user  ← シンボリックリンクの親
# NOT /var/log

bash の cd .. は論理パスで動作。cd -P .. で物理パス。

削除時の挙動

# ❌ 危険
rm -rf ~/logs/   # スラッシュ付き → リンク先の中身を消去

# ✅ 安全
rm ~/logs        # スラッシュなし → リンクのみ削除

リンク切れ（broken link）

リンク切れとは

リンク先が削除・移動された状態:

ln -s /tmp/exists.txt mylink
rm /tmp/exists.txt

ls -l mylink
# lrwxrwxrwx ... mylink -> /tmp/exists.txt（リンクは存在）

cat mylink
# cat: mylink: No such file or directory

リンク自体は存在するが、開けない状態。

検出方法

find で検出

# 通常のシンボリックリンクは -L で追跡可能
find /path -xtype l   # broken なリンクのみ

# あるいは -type l + -exec で確認
find /path -type l ! -exec test -e {} \; -print

-xtype l は GNU find の機能。リンク先が存在しないシンボリックリンクを検出。

symlinks コマンド

# Ubuntu/Debian
sudo apt install symlinks

symlinks -r /path
# absolute: /path/link1 -> /etc/something（絶対パスリンク）
# dangling: /path/link2 -> /tmp/deleted（リンク切れ）
# relative: /path/link3 -> ../other（相対パスリンク）

リンク切れの一括削除

# find で一括削除
find /path -xtype l -delete

# 確認しながら
find /path -xtype l -print -exec rm {} \;

リンク切れの確認スクリプト

#!/bin/bash
# check_symlinks.sh
find "$1" -type l | while read -r link; do
  if [ ! -e "$link" ]; then
    echo "BROKEN: $link -> $(readlink "$link")"
  fi
done

chmod +x check_symlinks.sh
./check_symlinks.sh /etc

権限と所有者

chmod の挙動

ln -s /etc/myapp/config.yml ~/config

chmod 600 ~/config
# → リンク先（/etc/myapp/config.yml）の権限が変わる
# シンボリックリンク自体の権限は変わらない

⚠️ chmod はリンク先に適用される。シンボリックリンク自体の権限は無視されます（Linux では使われない）。

chown の挙動

chown alice:alice ~/config
# → リンク先のオーナーが変わる

chown -h alice:alice ~/config
# → シンボリックリンク自体のオーナーを変える（-h オプション）

-h（--no-dereference）でシンボリックリンク本体を対象に。

注意：cp / mv の挙動

# cp はデフォルトで リンク先をコピー
cp ~/config /tmp/
ls -l /tmp/config
# -rw-r--r--（普通のファイル、リンクではない）

# -P でリンクをそのままコピー
cp -P ~/config /tmp/
ls -l /tmp/config
# lrwxrwxrwx ... config -> /etc/myapp/config.yml

# mv はリンクをそのまま移動
mv ~/config ~/config2
ls -l ~/config2
# lrwxrwxrwx ... config2 -> /etc/myapp/config.yml

rsync の挙動

# デフォルト：リンク先をコピー
rsync ~/config /backup/

# -l でリンクとしてコピー
rsync -l ~/config /backup/

# -L でリンク先の内容をコピー
rsync -L ~/config /backup/

find で活用

シンボリックリンクのみ検索

# シンボリックリンク全て
find /path -type l

# リンク先の名前で検索
find /path -type l -lname "*config*"

# 特定パターンのリンク
find /path -type l -name "*.yml"

リンクを追跡

# デフォルトはリンクを追跡しない
find /var/log -type f
# シンボリックリンク経由のファイルは含まれない

# -L でリンクを追跡
find -L /var/log -type f

リンク切れだけ

find /path -xtype l

詳細はLinux find オプション一覧の記事も参照。

実践パターン

パターン1：dotfiles 管理

設定ファイル（.vimrc、.bashrc 等）を Git で管理:

# Git リポジトリ
~/dotfiles/
├── .vimrc
├── .bashrc
├── .gitconfig
└── README.md

# ホームディレクトリにリンク
ln -sf ~/dotfiles/.vimrc ~/.vimrc
ln -sf ~/dotfiles/.bashrc ~/.bashrc
ln -sf ~/dotfiles/.gitconfig ~/.gitconfig

stow ツールでより自動化:

sudo apt install stow
cd ~/dotfiles
stow vim   # vim/ ディレクトリ内のファイルを ~/ にリンク

パターン2：Nginx sites-enabled パターン

# 設定を作成
sudo nano /etc/nginx/sites-available/myapp.conf

# 有効化
sudo ln -s /etc/nginx/sites-available/myapp.conf \
           /etc/nginx/sites-enabled/myapp.conf

# 無効化
sudo unlink /etc/nginx/sites-enabled/myapp.conf

# Nginx 再起動
sudo systemctl restart nginx

Apache も同じパターン（a2ensite / a2dissite コマンドあり）。

パターン3：Rails Capistrano デプロイ

/var/myapp/
├── releases/
│   ├── 20260601000000/
│   ├── 20260615000000/
│   └── 20260620000000/   ← 新リリース
├── current → releases/20260620000000   ← シンボリックリンク
└── shared/
    ├── config/
    ├── log/
    └── public/uploads/

# 切り替え（原子的）
ln -sfn /var/myapp/releases/20260620000000 /var/myapp/current

# ロールバック
ln -sfn /var/myapp/releases/20260615000000 /var/myapp/current

current を切り替えるだけでダウンタイムなしのデプロイ。

パターン4：Node.js / Ruby バージョン管理

# /usr/local/bin/ から各バージョンへ
ln -sf /opt/node/v20.10.0/bin/node /usr/local/bin/node

# バージョン切り替え
ln -sf /opt/node/v22.0.0/bin/node /usr/local/bin/node

asdf や n、nvm 等のバージョン管理ツールも内部でこの仕組みを使用。

パターン5：ログファイルの集約

# 各アプリのログを1か所に集約
mkdir -p ~/logs
ln -s /var/log/nginx/access.log ~/logs/nginx_access.log
ln -s /var/log/nginx/error.log ~/logs/nginx_error.log
ln -s /var/log/rails/production.log ~/logs/rails.log

# 一括確認
tail -f ~/logs/*.log

パターン6：プログラムの新旧バージョン共存

# /opt/myapp/v1.0/、/opt/myapp/v2.0/ がある
ln -s /opt/myapp/v1.0 /opt/myapp-stable
ln -s /opt/myapp/v2.0 /opt/myapp-beta

# 環境変数で切り替え
export PATH=/opt/myapp-stable/bin:$PATH
# または
export PATH=/opt/myapp-beta/bin:$PATH

パターン7：Docker volume の代替

# Docker 不要、シンボリックリンクで実現
ln -s /mnt/data ~/project/data

詳細はDocker no space left on device の記事も参照（Docker での扱いは別）。

パターン8：共有スクリプトへのリンク

# 全マシンで使いたいスクリプト
sudo ln -s /opt/shared/scripts/deploy.sh /usr/local/bin/deploy

PATHを汚さずに、コマンドとして呼び出し可能に。

ありがちなトラブル

File exists エラー

ln -s /new/target ~/config
# ln: failed to create symbolic link '/home/user/config': File exists

→ -f で強制上書き:

ln -sf /new/target ~/config

# ディレクトリリンクの更新なら -sfn
ln -sfn /new/dir ~/current

Too many levels of symbolic links

# リンクのループ
ln -s a b
ln -s b a
cat a
# bash: a: Too many levels of symbolic links

→ ループを検出して片方を削除:

readlink -f a
# 解決できない → ループ

Permission denied

ln -s /etc/myapp/config.yml /etc/config
# ln: failed to create symbolic link '/etc/config': Permission denied

→ sudo で:

sudo ln -s /etc/myapp/config.yml /etc/config

または書き込み権限のあるディレクトリで作成。

chmod が効かない

ln -s /etc/config.yml ~/config
chmod 600 ~/config
# シンボリックリンク本体の権限は変わらず、リンク先が変わる

→ シンボリックリンクの権限は Linux では無視される。リンク先で制御。

リンクの追跡を停止したい

# cd で追跡しない
cd -P ~/logs
pwd
# /var/log/myapp（実体）

# 一時的に
cd -P link_to_dir

Cross-device link エラー（ハードリンク）

ln /etc/passwd /tmp/passwd
# ln: failed to create hard link '/tmp/passwd' => '/etc/passwd': Invalid cross-device link

→ 別のファイルシステムなのでシンボリックリンクで:

ln -s /etc/passwd /tmp/passwd

tar でリンクとしてアーカイブ

# デフォルト：リンクとしてアーカイブ
tar czf backup.tar.gz mylink

# -h でリンク先の実体をアーカイブ
tar czfh backup.tar.gz mylink

Docker イメージ内でのリンク切れ

# COPY 元と先のパスが違う
# Dockerfile:
COPY ./app /app
# ./app 内の symlink が ../config を指すと、コンテナ内では解決不可

→ Docker では相対パスのシンボリックリンクが安全。

よくある質問（FAQ）

Q1. シンボリックリンクとハードリンクの使い分け

通常はシンボリックリンクで十分。

Q2. リンク先を変えたい

# 削除して再作成
unlink mylink
ln -s /new/target mylink

# または -sfn で
ln -sfn /new/target mylink

Q3. リンクのフルパスを取得

readlink -f mylink         # 最終的な実パス
realpath mylink            # 同上
ls -l mylink | awk '{print $NF}'   # リンク先のパス文字列

Q4. 大量のリンクを一括作成

# /opt/scripts/* を /usr/local/bin/ に
for f in /opt/scripts/*; do
  ln -sf "$f" "/usr/local/bin/$(basename "$f")"
done

または:

ln -sf /opt/scripts/* /usr/local/bin/

Q5. ディレクトリ全体をシンボリックリンクに

# /home/user/data ディレクトリを /mnt/data に移し、リンクで参照
mv /home/user/data /mnt/data
ln -s /mnt/data /home/user/data

ディスク容量逼迫時の対処に。

Q6. 相対パスか絶対パスか

迷ったら絶対パス。

Q7. リンク切れを一覧

find / -xtype l 2>/dev/null

/ から全システム検索。2>/dev/null でアクセス権限エラー抑制。

Q8. シンボリックリンクをコピー

cp -P link dest    # リンクとしてコピー
cp -L link dest    # リンク先の内容をコピー
cp -d link dest    # 同じく（cp の -P と同じ）

Q9. Windows のショートカットとの違い

Q10. 移動するとリンクは壊れる？

# 絶対パスリンク
ln -s /etc/config.yml mylink
mv mylink /tmp/
# OK（リンク先が絶対パスなので問題なし）

# 相対パスリンク
ln -s ../config.yml mylink
mv mylink /tmp/
# 壊れる可能性大（相対パスが解決できなくなる）

絶対パスなら移動しても壊れない。

Q11. Git でシンボリックリンクは扱える？

ln -s /target file
git add file
git commit -m "add symlink"
# OK、Git はリンクとして記録

Windows との互換性は要注意（GitHub などでは展開挙動が違うことも）。

Q12. シンボリックリンクが指す絶対パスを更新

# リンク先がディレクトリ移動
mv /old/location /new/location

# リンクを更新
ln -sfn /new/location /home/user/mylink

参考リンク・関連資料

公式

• ln(1) – Linux manual page – ln 公式
• symlink(7) – Linux manual page – シンボリックリンク仕様
• readlink(1) – Linux manual page – readlink 公式
• GNU Coreutils – ln/cp/mv 等

関連ツール

• GNU stow – dotfiles 管理
• symlinks – シンボリックリンク管理

関連記事（本サイト）

• Linux find オプション一覧 – リンク検索（-type l, -xtype l）
• Linux grep オプション一覧 – 文字列検索
• Linux awk 使い方 – データ加工
• crontab 書き方 例 – 定期メンテナンス
• Linuxでファイル差分を確認する方法 – diff/colordiff/vimdiff
• Linuxでプロセスをバックグラウンド実行する方法 – nohup/&/disown
• SSH host key verification failed – リモート操作
• Docker no space left on device – ディスク容量管理
• Ubuntu IPアドレス確認 – サーバー情報
• wget と curl 違い – ファイル取得
• Solid Queue 使い方 – Rails 8 のジョブシステム
• Rails 8 アップグレードガイド – Rails 全般

まとめ

Linux でシンボリックリンクを作成・確認・削除する方法、要点を再整理します。

作成（ln -s）

ln -s [リンク先] [リンク名]
ln -sf [リンク先] [リンク名]        # 強制上書き
ln -sfn [リンク先] [リンク名]       # ディレクトリリンクの更新

確認

ls -l mylink              # 基本確認
readlink mylink           # リンク先パス
readlink -f mylink        # 最終的なリンク先
file mylink               # ファイルタイプ判定
stat mylink               # 詳細情報

削除

rm mylink                 # 推奨
unlink mylink             # 同等

# 末尾スラッシュは付けない（リンク先削除リスク）

リンク切れ

find /path -xtype l       # 検出
find /path -xtype l -delete  # 一括削除

権限

chmod 600 mylink          # リンク先の権限変更
chown -h user mylink      # リンク本体のオーナー変更

ハードリンクとの違い

実践パターン

• dotfiles 管理: ln -sf ~/dotfiles/.vimrc ~/.vimrc
• Nginx sites-enabled: ln -s sites-available/conf sites-enabled/
• Rails Capistrano: ln -sfn releases/xxx current
• バージョン切り替え: ln -sf /opt/v2.0 /opt/myapp-stable

これらの知識は、Linux サーバー運用・デプロイ・設定管理・ファイル整理など、あらゆる場面で活用できます。本記事をブックマークしておけば、シンボリックリンクをスムーズに扱えるようになります。

本記事は2026年6月時点の情報をもとに、GNU Coreutils 9.x、Bash 5.x での動作確認・公式ドキュメントに基づき作成しています。ディストリビューションによって挙動が異なる場合があるため、最新の情報は man ページ（man ln、man readlink、man symlink）もあわせてご確認ください。