Linux EXDEV (18) 診断：ハードリンク作成エラーの原因究明と修復編

df -T /src/path /dst/path stat -c '%d %n' /src/path /dst/path findmnt -T /src/path findmnt -T /dst/path

選択と行動
ハードリンク必須でなければ、symlink または copy へ要件を寄せる
ハードリンク必須なら、同一ファイルシステム側へ配置を寄せられないかを見る
構成変更は最小変更で済むかを先に比較する

選択と行動
見えているパスではなく、実体のマウント境界を確認する
手順で吸収できるのか、構成修正が必要なのかを分けて考える
監査や運用ルールが絡むなら、権限変更より先に整理する

選択と行動
コンテナ内の見え方とホスト側の実体差分を先に揃える
イメージ修正だけでなく、volume や成果物配置の見直しも候補に入れる
再デプロイ後に再発しない直し方かを確認する

選択と行動
強引な chmod や chown に寄らず、変更前に影響範囲を見積もる
リンク方式の変更で要件を満たせるかを確認する
判断材料が不足するなら、迷ったら相談のほうが早く収束しやすい

【注意】Linux の EXDEV (18) は、見た目が単純でも、共有ストレージ、コンテナ、監査要件、本番データの配置が絡むと判断を誤りやすい障害です。自分で修理や復旧作業を進める前に、読み取り中心で状況を確認し、個別案件では株式会社情報工学研究所のような専門事業者へご相談ください。

第1章：なぜ ln が失敗するのか――EXDEV (18) は「権限不足」ではなく境界のサイン

Linux で ln を実行した際に Invalid cross-device link や EXDEV (18) が出ると、つい「権限が足りないのではないか」「sudo でやり直せば通るのではないか」と考えがちです。しかし、Linux の link(2) は、EXDEV を「元のパスと新しいパスが同じ mounted filesystem 上にない」ときのエラーとして定義しています。つまり、最初に疑うべきは権限ではなく、マウント境界、配置、名前空間、あるいは共有ストレージの見え方です。ここを取り違えると、不要な権限変更や運用変更が広がり、障害のクールダウンどころか影響範囲を広げる判断になりかねません。

ここで押さえたいのは、hard link の性質です。GNU Coreutils の説明でも、hard link は既存ファイルに対する別名であり、元ファイルとリンク先は実質的に同じ inode を共有します。inode を共有する以上、別の mounted filesystem をまたいで新しい hard link を作ることはできません。逆に言えば、同じ inode を共有できない配置であれば、権限が十分でも hard link は成立しません。この前提を外してしまうと、「権限を上げたのに直らない」「一時的にコピーへ変えたら別の整合性問題が出た」といった、現場にとって説明しづらい二次障害が起きやすくなります。

実務では、さらに厄介な誤解があります。それは、「同じストレージに載っているのだから hard link できるはずだ」という感覚です。Linux が判定に使うのは、見た目の近さではなく、実際の mount 境界です。link(2) の説明には、Linux では同じ filesystem が複数箇所に mount されていても、異なる mount をまたぐ link() は動作しないとあります。つまり、bind mount、複数 mount、コンテナの mount namespace、共有ボリュームの切り方によっては、運用者の感覚では「同じ場所」でも、カーネルにとっては「別の境界」です。この差を見落とすと、障害の収束に必要な論点整理が遅れます。

まず行うべき安全な初動

EXDEV の初動で大切なのは、書き込み系の対処へ急がず、読み取り中心で事実を揃えることです。findmnt --target は指定したファイルまたはディレクトリに対して、そのパスが属する filesystem を表示できます。また、stat の %d は device number（st_dev）を確認できます。現場では、元ファイルとリンク作成先の両方に対してこの二つを取るだけでも、「境界をまたいでいるのか」「見えている mount が違うのか」の輪郭がかなり明確になります。問題が configuration 起因か、単純なコマンド起因かを早めに分けられるため、社内説明でも話が整理しやすくなります。

df -T /path/to/source /path/to/dest stat -c '%d %n' /path/to/source /path/to/dest findmnt -T /path/to/source findmnt -T /path/to/dest

ここで数字や mount 情報が一致しないなら、「hard link を作る前提そのものが合っていない」可能性が高いと考えてよいでしょう。この段階では、無理に workaround を当てるより、要件確認のほうが重要です。対象が単なる作業ディレクトリであれば symlink や copy へ設計を寄せる余地がありますが、inode 共有を前提にした処理、バックアップ、監査ログ、配布物管理、容量管理が絡む場合は話が変わります。一般論としての「直し方」は存在しても、個別案件で安全かどうかは構成次第です。そこが、運用現場で一般論の限界が現れるところです。

「権限不足」との見分け方

権限まわりで hard link が失敗する場合、Linux の link(2) は EPERM や関連する権限制約を返し得ます。たとえば Linux 3.6 以降は /proc/sys/fs/protected_hardlinks による制限があり、条件に合わない hard link 作成は EPERM になり得ます。逆に、今回の論点である EXDEV は「権限が足りない」ではなく「同じ mounted filesystem ではない」です。エラー番号の意味を読み違えないことが、ダメージコントロールの第一歩です。ここを正確に把握しておくと、無関係な権限変更を避けやすくなり、監査や変更管理の観点でも筋のよい対応になります。

特に、共有ストレージ、コンテナ、本番データ、監査要件が絡む環境では、「とりあえず root で再実行」や「一旦 copy で逃がす」という判断が、後から別の整合性問題や説明コストを生みます。hard link が必要なのか、単に同名参照が欲しいのか、あるいは配置設計を見直すべきなのかは、案件ごとに前提が異なります。こうした場面では、個別構成を見ないまま一般論で押し切るより、株式会社情報工学研究所のように現場構成を踏まえて診断できる専門家へ相談したほうが、結果として収束が早くなることが少なくありません。ご相談は問い合わせフォーム（https://jouhou.main.jp/?page_id=26983）または 0120-838-831 から受け付けています。

第1章の結論は明確です。EXDEV (18) は、まず「境界」を見るべきエラーです。hard link は inode を共有する仕組みであり、Linux の link(2) は異なる mounted filesystem をまたぐ作成を認めていません。したがって、最初に行うべきことは権限変更ではなく、mount、device number、namespace、ストレージ構成の事実確認です。この順番を守るだけで、誤対応のノイズカットと被害最小化につながります。

第2章：まず疑うべき分断点――別ファイルシステム・共有ストレージ・コンテナの伏線

EXDEV (18) を見たとき、現場で本当に難しいのは「何が別なのか」が目視だけでは分かりにくい点です。パスの並びだけを見ると同じディレクトリ階層の近くに見えても、Linux から見ると mount の境界が異なることがあります。link(2) の説明には、元のパスと新しいパスが同じ mounted filesystem 上にない場合に EXDEV になること、さらに Linux では同じ filesystem が複数箇所に mount されていても、異なる mount をまたぐ hard link はできないことが明記されています。つまり、分断点は「物理ディスクが同じかどうか」ではなく、「いま見えている名前空間で同じ mount として扱われているかどうか」です。ここを押さえるだけで、切り分けの精度が大きく変わります。

まず典型的なのが、別ファイルシステムをまたいでいるケースです。これは最も教科書的ですが、実務では意外に見落とされます。たとえば /var/data と /backup/data が同じサーバ上にあり、運用担当者から見ると「同じマシン内のパス」に見えていても、片方が別ボリューム、別 LV、別 mount であれば hard link は成立しません。GNU Coreutils の ln の説明でも、hard link は file system boundary を越えられないとされています。したがって、まず確認すべきは「同一ホストか」ではなく、「同一 mounted filesystem か」です。ここを曖昧にしたまま対処すると、関係のない権限変更や一時ファイルの退避で場を整えたつもりが、根本条件は何も変わっていない、ということが起こります。

見落としやすい分断点 1：bind mount と複数 mount

次に厄介なのが、bind mount や同一 filesystem の複数 mount です。運用上は「同じ実体を別の場所に見せているだけ」と考えたくなりますが、Linux の link(2) の説明はこの点に明確で、同じ filesystem が複数箇所に mount されている場合でも、異なる mount 間の hard link は失敗し得ます。現場では、アプリケーション都合で見せるパスを整理した結果、同じ内容が複数の経路から見える構成は珍しくありません。そのため、「見えているディレクトリが近い」「実体は同じに見える」という印象だけで判断すると、論点がずれます。hard link の成否を決めるのは、ファイルの見た目の近さではなく、カーネルが認識している mount の境界です。

このタイプの障害では、df -T だけで判断すると情報が足りないことがあります。findmnt は /proc/self/mountinfo などを使って mount 情報を検索できるため、対象パスごとに「どの mount に属しているか」を追いやすい点が実務向きです。また、stat では st_dev や mount point 関連の表示を確認できるため、複数の情報を突き合わせると「パスの見え方」と「実際の境界」の差が見えやすくなります。単一コマンドで断定せず、複数の読み取り結果を重ねて判断するほうが、後から説明責任を果たしやすく、運用上も収束が早くなります。

見落としやすい分断点 2：コンテナと mount namespace

コンテナが絡むと、この問題はさらに説明しにくくなります。mount namespace は、プロセスごとに「どの mount 一覧を見るか」を分離する仕組みです。man page でも、異なる mount namespace に属するプロセスは、それぞれ異なる single-directory hierarchy を見ると説明されています。つまり、コンテナ内から見た /data と、ホスト側で見た /data は、名前が同じでも同じ mount 構成とは限りません。現場で「同じパスなのに、なぜ片方だけ失敗するのか」という混乱が起きやすいのは、この差があるためです。コンテナ内の再現結果だけで結論を出すのではなく、ホスト側の mount 情報と突き合わせることが、余計な試行錯誤にブレーキをかける近道です。

特に CI 実行基盤、Kubernetes の volume、コンテナイメージ上のパス、永続ボリュームの切り分けが入ってくると、障害の発生箇所と実体の配置が一致しないことがあります。その場合、「コンテナ内でコマンドが動くか」だけを見ても、設計として hard link が成立し得るかどうかは判断しきれません。コンテナ側で一時的に別方式へ逃がせたとしても、再デプロイ後に同じ構成へ戻れば再発するおそれがあります。再現確認の結果をそのまま修復方針に結びつけず、構成の層を分けて考えることが重要です。

見落としやすい分断点 3：overlayfs では stat の読み方に注意が必要

overlayfs が入ると、切り分けはさらに慎重さが必要です。Linux カーネルの overlayfs 文書では、ディレクトリは overlay filesystem の st_dev を返す一方、非ディレクトリオブジェクトは lower filesystem または upper filesystem の st_dev を返し得ること、st_ino は st_dev と組み合わせて扱う必要があること、場合によってはその値がオブジェクトの寿命の中で変化し得ることが説明されています。つまり、overlayfs 上では stat の数値だけを単純比較しても、通常の単層 filesystem と同じ感覚では読めません。読み取り確認そのものは有効ですが、stat だけで断定せず、findmnt、コンテナ構成、upper/lower の整理を合わせて行うほうが安全です。

この点は、現場リーダーや情シスの方が関係者へ説明する場面でも重要です。数値が同じだった、違っていた、という一点だけでは、なぜ hard link が成立しないのかを十分に説明できないことがあります。特に監査要件や本番データが絡む場合は、「確認したコマンド」と同じくらい「その結果をどう解釈したか」が問われます。一般論としての手順を知っていても、個別案件の mount 設計、コンテナ設計、共有ストレージ運用まで踏まえる必要があるなら、構成を見ながら判断したほうが結果的に早くクールダウンしやすくなります。そうした場面では、株式会社情報工学研究所への相談をご検討いただくのが現実的です。問い合わせフォームは https://jouhou.main.jp/?page_id=26983、お電話は 0120-838-831 です。

第2章で押さえたいのは、EXDEV の「原因候補」は一つではないものの、どれも最終的には境界の問題に収れんするという点です。別ボリューム、bind mount、共有ストレージ、コンテナ、overlayfs は、いずれも「同じ場所に見えるのに、カーネルからは同じ条件ではない」という形で現れます。したがって、最初から修理手順に飛ぶより、分断点を正しく見つけることのほうが重要です。この順番を守ることが、被害最小化と説明のしやすさの両方につながります。

第3章：再現と切り分け――stat・df・findmnt で「どこをまたいだか」を見える化する

EXDEV (18) の切り分

続きをお願い
出力は本文のみ。メタ文・挨拶・宣言・注意・確認を一切出さない。
終了マーカー（※×5）は、完結した最終回答の最終行のみ。例示・引用でも出さない。
終了マーカー（※×5）は、出し忘れていたか確認をして、出し忘れの場合はだす。
禁止文字列を“説明で書かない”構造にする、
メタ発言を完全禁止にする
次の章の説明は禁止にする

進行中の章を切れ目なく使えるように、第3章を章頭から整えて出し直します。

●●●●●

第3章：再現と切り分け――stat・df・findmnt で「どこをまたいだか」を見える化する

EXDEV (18) の切り分けで大切なのは、「hard link が作れなかった」という結果だけを見るのではなく、「どの境界をまたいだのか」を順番に見える化することです。Linux の link(2) は、元のパスと新しいパスが同じ mounted filesystem 上にないときに EXDEV を返します。しかも Linux では、同じ filesystem が複数箇所に mount されていても、異なる mount をまたぐ hard link は動作しません。したがって、切り分けの中心は「同じディスクか」ではなく、「同じ mount として見えているか」です。ここを事実ベースで押さえると、権限変更や運用変更に早く飛びつかずに済み、収束までの判断が安定します。

実務で使いやすい確認手段は、df、stat、findmnt の三つです。df は対象パスがどの filesystem に乗っているかと filesystem type を把握するのに向いており、stat は device 番号や mount point を確認できます。GNU Coreutils の stat では、%d で device 番号、%m で mount point を出力できます。さらに findmnt は mount 情報を検索するためのコマンドで、/proc/self/mountinfo などをもとに対象パスがどの mount に属しているかを追えます。三つを重ねると、見た目では同じように見えるパスでも、Linux がどう認識しているかをかなり正確に整理できます。

df -T /path/to/source /path/to/dest stat -c '%d %m %n' /path/to/source /path/to/dest findmnt -T /path/to/source findmnt -T /path/to/dest

このときの見方には順番があります。最初に df -T で、元ファイル側とリンク作成先の親ディレクトリ側が同じ filesystem type と同じ mount 系列に見えるかをざっくり確認します。次に stat -c '%d %m %n' で、それぞれの device 番号と mount point を見ます。最後に findmnt -T で、対象パスが実際にどの mount に結び付いているかを確認します。ここで %d や mount point が違う、または findmnt が別の mount を返すなら、hard link を作る前提がそもそも一致していない可能性が高いと判断できます。

たとえば、df -T では似たような結果に見えても、stat の %m が異なる場合があります。GNU Coreutils の説明では、stat の %m は df と近い mount point を出しますが、bind mount の別名を返すなど、読み方には前提があります。つまり、「df で同じに見えたから確定」ではなく、「df で全体像を見て、stat で対象パスの見え方を合わせ、findmnt で mount 情報を確定する」という使い分けが実務向きです。単一のコマンド結果を過信しないほうが、あとで説明がぶれません。

再現確認は「壊さない範囲」で十分です

EXDEV の再現確認というと、つい別のコマンドで回避策まで試したくなりますが、最初の段階では読み取り中心で十分です。なぜなら、問題の本質は「hard link が作れない理由の特定」であって、「一時的に別の方法でファイルを置けるか」の確認ではないからです。Linux の link(2) が示しているのは mount 境界の不一致であり、回避手段を先に試しても、その境界自体は変わりません。特に本番環境、共有ストレージ、監査対象ディレクトリでは、一時的な書き込みが別の説明コストを生むことがあります。最初は読み取り中心で場を整え、事実関係を揃えるほうが安全です。

そのうえで、再現確認では「どのペアで失敗するか」を整理すると効果的です。元ファイル A とリンク先候補 B、元ファイル A と別の候補 C、同じディレクトリ内での hard link、別ディレクトリでの hard link、というように条件を少しずつ変えると、境界がどこにあるかが見えやすくなります。もし同一ディレクトリでは成功し、別ディレクトリで失敗するなら、アプリケーションロジックの問題より先に mount 境界を疑うほうが自然です。逆に、同一ディレクトリでも失敗するなら、EXDEV 以外のエラー番号やファイル種別、保護設定も視野に入ります。エラー番号の意味を軸に条件差分を見ることで、議論が過熱しにくくなります。

コンテナや bind mount では「どこで実行したか」を残します

コンテナや CI 基盤が絡む場合は、コマンド結果そのものに加えて、「そのコマンドをどの namespace、どの実行環境で取ったか」を残すことが重要です。findmnt は /proc/self/mountinfo などを参照するため、取得した環境が変われば見える mount 情報も変わり得ます。つまり、ホスト側で採った結果とコンテナ内で採った結果は、どちらかが間違いというより「見ている世界が違う」ことがあります。この整理を先にしておくと、「同じコマンドなのに結果が違う」という混乱を減らしやすくなります。

実際の運用では、ここで「とりあえず symlink で置き換える」「一時的に copy に変える」という判断が検討されることがあります。しかし、その判断が安全かどうかは、inode 共有を前提にした処理があるか、バックアップや監査ログが同じ前提を持っているか、容量や同期の考え方が変わらないかで大きく異なります。一般論としての代替策は存在しても、個別案件では安全性の判断が別問題です。共有ストレージ、コンテナ、本番データ、監査要件が絡む場合は、無理にその場で構成を触るより、株式会社情報工学研究所へ相談して、読み取り結果をもとに最小変更の選択肢を整理したほうが、結果としてダメージコントロールにつながりやすくなります。ご相談は 問い合わせフォーム または 0120-838-831 で受け付けています。

第3章の要点は明確です。EXDEV (18) の切り分けは、勘や経験だけで進めるより、df で全体像、stat で対象の属性、findmnt で mount の実体を押さえる順番にすると整理しやすくなります。元と先が同じ mounted filesystem かどうかを事実で固めることができれば、修復方針の議論も落ち着きやすくなります。逆に、境界が見えないまま代替策へ進むと、あとから別の論点が増えやすくなります。切り分けの段階で場を整えておくことが、結果として被害最小化につながります。

第4章：修復方針を誤らない――ハードリンクを外す条件と最小変更で直す条件

EXDEV (18) の切り分けが終わったあとに重要になるのは、「では何に置き換えるか」ではなく、「そもそも hard link が必要な要件なのか」を見極めることです。Linux の link(2) は hard link を既存ファイルに対する新しい名前として定義しており、両者は同じファイルを指し、同じ権限と所有者を共有します。さらに、hard link は filesystem をまたげず、これが必要なら symlink(2) を使うよう man page に明記されています。つまり、EXDEV が出たときの判断は、「hard link 前提を維持すべき案件」なのか、「参照方法だけ変えれば要件を満たせる案件」なのかを分けるところから始まります。ここを曖昧にすると、その場では動いても、後から整合性や運用説明に負荷が残ります。

hard link を維持すべき代表例は、inode 共有そのものに意味があるケースです。たとえば、同一実体であることを前提にリンク数を管理している処理、更新が即座に同一実体へ反映されることを前提にした仕組み、容量計算やバックアップ設計が「複製ではなく同一 inode の別名」であることを前提にしている構成では、copy や symlink へ単純に置き換えると前提が崩れます。GNU Coreutils でも、hard link は既存ファイルへの別名であり、同じ inode を共有するため、どちらが「元」か区別できないという性質が説明されています。この性質が仕様の一部になっているなら、hard link を外す判断は慎重であるべきです。

一方で、hard link が必須ではないケースも少なくありません。単に「別の場所から同じ内容を参照したい」「配置の都合で複数の名前からアクセスしたい」「一時的な作業導線を作りたい」といった要件であれば、symlink や copy のほうが構成に合う場合があります。とくに、filesystem 境界をまたぐ必要がある構成では、hard link を成立させるために無理に配置変更や権限変更を加えるより、要件を満たす別方式へ寄せたほうが影響範囲を抑えやすくなります。Linux の symlink(2) は、新しい名前が target を指す symbolic link であることを示しており、hard link とは性質が異なりますが、cross-filesystem の制約回避という意味では有効な選択肢です。

「hard link を外してよい条件」を先に整理します

判断を落ち着かせるためには、まず「hard link を外してよい条件」を整理するのが有効です。たとえば、次のような条件がそろうなら、hard link 固定で考え続ける必要は薄くなります。

• 同一 inode であること自体が業務要件ではない
• リンク先の更新が即時に同一実体へ反映される必要がない、または別方式で担保できる
• バックアップ、監査、世代管理、容量見積もりが copy や symlink へ切り替わっても破綻しない
• 運用手順や障害復旧手順の説明が、hard link 前提でなくても成立する

この確認は、技術論だけでなく、案件の説明責任にも関わります。現場では「通ればよい」では済まないことが多く、後続の保守担当者や監査対応担当者が見たときに理解しやすい構成であることが求められます。hard link を外しても要件が満たせるなら、その判断は妥当です。しかし、そこを確認しないまま一律に copy へ寄せると、「なぜ容量が増えたのか」「なぜ片方の更新が反映されないのか」「なぜ監査資料の説明が変わったのか」といった別の論点が生まれます。修復方針は、技術的成立だけでなく、運用の納得感まで含めて決める必要があります。

「最小変更で直す条件」は、構成変更の単純さでは決まりません

現場で迷いやすいのは、「いちばん小さい変更に見えるもの」が、必ずしも最小変更ではない点です。たとえば、シェルスクリプトの ln を cp に変えるだけなら差分は小さく見えます。しかし、その結果として容量の使い方、更新反映の前提、バックアップ対象、監査の説明が変わるなら、実質的には小さくありません。逆に、配置を同一 mounted filesystem 側へ寄せる変更は一見大きく見えても、要件と運用の前提を保てるなら、長期的にはこちらのほうが小さい変更になることがあります。EXDEV の修復では、コード差分の大きさより「前提条件をどれだけ温存できるか」を軸に見るほうが、後の収束が安定します。

このとき有効なのが、「何を変えずに残したいか」を先に固定する考え方です。たとえば、本番運用中の監査ログの見え方は変えたくない、バックアップ手順は変えたくない、リンク数に依存する処理は変えたくない、といった条件です。こうした条件を先に並べると、copy が不向きなのか、symlink なら許容できるのか、あるいは配置設計を見直すべきなのかが見えやすくなります。反対に、「EXDEV を消すこと」だけを目的にしてしまうと、あとで別の論点が増えます。障害対応は、その場の通過だけでなく、後続の運用まで見据えて歯止めをかけることが重要です。

一般論で決めにくい案件では、相談判断のほうが早いことがあります

共有ストレージ、コンテナ、本番データ、監査要件が絡むと、修復方針は一般論だけでは決めにくくなります。man page や GNU Coreutils の説明から、hard link が cross-filesystem を越えられないこと、hard link と symlink の性質が異なることまでは分かります。しかし、「この案件ではどちらへ寄せるのが安全か」「最小変更はどの選択か」は、システム構成、契約要件、保守体制、監査項目まで含めて判断しないと結論がぶれます。つまり、技術的な一般論には限界があり、個別案件では構成と運用文脈を見た判断が必要です。

そのため、読み取り中心の切り分けで境界が見えた時点で、無理にその場で構成を触るより、株式会社情報工学研究所へご相談いただくほうが現実的な場面があります。たとえば、共有ストレージ配下で hard link 前提の処理が動いている、本番系とバックアップ系で見える mount が異なる、コンテナ内の回避策が再デプロイ後も維持されるか読めない、といった案件です。こうした場合は、構成を踏まえて「hard link を維持するべきか」「外してよいか」「どこまでが最小変更か」を整理したほうが、社内調整も進めやすくなります。ご相談は 問い合わせフォーム または 0120-838-831 から受け付けています。

第4章の結論は、EXDEV の修復は「代替コマンドを選ぶ問題」ではなく、「要件を壊さずに何を残すかを決める問題」だという点にあります。hard link を外してよい案件なら、symlink や copy は有力な選択肢です。hard link が必要な案件なら、同一 mounted filesystem 上へ配置を寄せる方向で考える必要があります。大切なのは、最小変更を見誤らないことです。ここを丁寧に整理できるかどうかが、障害の軟着陸につながります。

第5章：本番で崩さない実装――mv・cp・symlink の使い分けと影響範囲の考え方

EXDEV (18) の修復で、現場がいちばん悩みやすいのは「何に置き換えれば安全か」です。ここで重要なのは、ln が失敗したからといって、mv、cp、symbolic link のどれかへ機械的に置き換えればよいわけではない、という点です。GNU Coreutils の説明では、hard link は file system boundary を越えられません。一方、symbolic link は名前で参照先を指す別の仕組みで、hard link と同じ挙動にはなりません。つまり、EXDEV の解消と要件維持は別問題です。実装の置き換えは、「エラーを消すこと」ではなく、「何が変わると困るのか」を先に整理して選ぶ必要があります。

まず mv です。mv は通常、同じ file system 内であれば rename に近い形で動きますが、GNU Coreutils の説明では、宛先が別 file system で rename できない場合、cp -a 相当でコピーしてから、成功時に元を削除する動作へ切り替わります。Linux の rename(2) でも、rename は名前の付け替えであり、既存の hard link には影響しない一方、成功条件には制約があります。したがって、ln を mv に置き換えると、一見「移動できた」ように見えても、実体としては rename ではなく copy＋delete になっている可能性があります。本番ではこの差が重要です。容量使用量、処理時間、失敗時の中途状態、監査上の説明が変わるためです。

次に cp です。cp は複製を作るため、hard link のように同じ inode を共有しません。GNU Coreutils の説明では、cp -d やそれを含む cp -a は source 側に複数の hard link がある場合の関係をコピー先でも保とうとしますが、それは「コピー後の関係」を保つ話であり、元ファイルとコピー先が同一実体になるわけではありません。つまり、更新の即時反映、リンク数、容量計算、バックアップの見え方が変わる可能性があります。単純な配布物や一時ファイルなら問題にならないこともありますが、本番データや運用スクリプトで「同じ実体であること」に意味があるなら、cp は慎重に扱うべきです。

symbolic link は、cross-filesystem の制約を避けやすい一方で、参照の前提が変わります。GNU Coreutils の説明では、symbolic link はファイルそのものではなく、名前で別の対象を指します。そのため、参照先の解決可否、相対パスか絶対パスか、削除や配布時の見え方、監査資料での説明が hard link とは異なります。たとえば、参照先が移動した場合や、マウント条件が変わった場合、hard link では起きなかった問題が symlink では起こり得ます。反対に、要件が「別名でたどれればよい」であれば、symlink のほうが構成に自然なこともあります。ここで大切なのは、hard link の代用品として見るのではなく、別の仕組みとして評価することです。

本番で見るべき影響範囲

実装の置き換えを判断する際は、少なくとも四つの観点を見ておくと整理しやすくなります。第一に、更新反映です。hard link は同じ inode を共有するため、どちらから見ても同じ実体ですが、copy は別物になり、symlink は参照先依存になります。第二に、容量と性能です。mv が同一 file system 内なら軽く済む一方、別 file system では copy 相当になり得ます。第三に、障害時の戻しやすさです。copy＋delete 型の変更は、中断時や部分失敗時の扱いを確認する必要があります。第四に、監査や保守の説明可能性です。一般論として通る方法でも、その案件の契約、バックアップ手順、運用引き継ぎで説明しづらければ、実務上はよい選択とは言えません。

この章で押さえておきたい結論は、EXDEV の修復はコマンド置換の話ではなく、影響範囲の設計の話だということです。特に、共有ストレージ、コンテナ、本番データ、監査要件が絡む案件では、「いちばん簡単に見える置き換え」が最小変更とは限りません。一般論で候補を絞ることはできますが、どれが安全かは個別構成と運用前提で変わります。判断に迷う場合は、読み取り結果をそろえたうえで、株式会社情報工学研究所へご相談いただくほうが、結果として被害最小化と収束の早さにつながりやすくなります。ご相談は 問い合わせフォーム または 0120-838-831 で承っています。

第6章：診断から再発防止へ――EXDEV を一時対応で終わらせない設計と運用

EXDEV (18) への対応で最後に大切になるのは、「今回は通った」で終わらせないことです。Linux の link(2) が示しているように、EXDEV は oldpath と newpath が同じ mounted filesystem 上にないときのエラーです。しかも Linux では、同じ filesystem が複数箇所に mount されていても、異なる mount 間の hard link は動作しません。つまり、この障害は単発のコマンドミスというより、パス設計、mount 設計、実行環境設計のどこかに「前提のずれ」が残っているサインです。応急的に別方式へ寄せて症状が静かになっても、設計上の前提が未整理のままだと、デプロイ、バックアップ、障害復旧、監査対応のどこかで再び表面化する可能性があります。 ([man7.org](https://man7.org/linux/man-pages/man2/link.2.html?utm_source=chatgpt.com))

再発防止の第一歩は、「この処理が本当に hard link を必要としているのか」を仕様として明文化することです。hard link は単なる近道ではなく、同じ inode を共有する別名です。そのため、更新反映、リンク数、容量の見え方、バックアップ時の扱いまで含めて意味を持ちます。GNU Coreutils でも、hard link は既存ファイルへの別名であり、symbolic link は名前で参照先を指す別の仕組みだと説明されています。もし要件が「同じ内容に到達できればよい」であれば、hard link 固定の設計は将来の制約になり得ます。逆に、「同じ実体であること」自体が仕様なら、その仕様に合う配置設計へ戻す必要があります。ここを文章で残しておくと、担当者が変わっても判断がぶれにくくなります。 ([gnu.org](https://www.gnu.org/s/coreutils/manual/html_node/ln-invocation.html?utm_source=chatgpt.com))

再発防止で整理したい観点

再発を防ぐには、少なくとも次の観点を設計と運用の両方で揃えておくと効果的です。

• hard link が必要な理由を、仕様・運用手順・保守メモに明記する
• 元ファイルとリンク作成先が、同一 mounted filesystem 上にある前提を構成図に落とす
• bind mount、共有ストレージ、コンテナ、overlayfs を使う場合は、どの層で見た mount 情報かを残す
• copy や symbolic link へ切り替えた場合の容量、同期、監査、復旧手順の差分を整理する
• デプロイや更改時に mount 構成が変わっても、前提が崩れないかを確認項目に入れる

これらはどれも派手な対策ではありませんが、実務では非常に効きます。EXDEV のやっかいな点は、障害が起きた瞬間だけ見ていると「コマンドを変えれば済む」と思いやすいことです。しかし、本当に必要なのは、なぜその構成で hard link を使っていたのか、将来も同じ前提が維持されるのか、という問いへの答えです。ここがあいまいなままだと、サーバー更改、コンテナ化、共有ストレージ統合、監査対応のたびに同じ論点が再燃します。障害対応をその場の抑え込みで終わらせず、設計と運用に引き戻して整理することが、長期的な収束につながります。 ([man7.org](https://man7.org/linux/man-pages/man2/link.2.html?utm_source=chatgpt.com))

一般論で止まると、個別案件では判断を誤りやすくなります

ここまで見てきたように、EXDEV の一般論は比較的はっきりしています。hard link は cross-filesystem を越えられず、mount 境界をまたぐと成立しません。symbolic link は別の仕組みであり、mv は別 filesystem では copy＋delete 相当になる場合があります。ここまでは文献で確認できます。しかし、実際の案件で難しいのは、その先です。どの方式なら契約条件、監査要件、本番運用、バックアップ、性能、将来の更改に耐えられるのかは、一般論だけでは決めきれません。つまり、知識だけでは足りず、構成と運用の文脈を合わせて診断する必要があります。 ([gnu.org](https://www.gnu.org/s/coreutils/manual/html_node/mv-invocation.html?utm_source=chatgpt.com))

たとえば、共有ストレージ配下で複数システムが同じ実体を前提にしている場合、copy への変更は見た目より大きな影響を持ちます。コンテナ内では symlink で落ち着いても、ホスト側のバックアップや監査がその前提を持っていないなら、後続で別の論点が増えます。本番データで容量見積もりが厳しい案件では、rename だと思っていた処理が実際には copy＋delete になっていた、という差が業務上の負荷になります。こうした「一般論の先」にある判断は、実案件の構成図、ログ、運用フロー、変更制約を見ながらでないと精度が上がりません。

依頼判断の目安

次のいずれかに当てはまる場合は、その場で無理に構成変更を進めるより、専門家への相談をご検討いただくほうが現実的です。

• 共有ストレージ、NAS、外部ボリューム、bind mount が絡んでいて、mount 境界の整理に確信が持てない
• コンテナ、CI、overlayfs を含むため、ホスト側との見え方の差を説明しきれない
• 本番データ、監査対象、契約要件があり、copy や symlink への変更可否を一般論では決められない
• バックアップ、容量設計、障害復旧手順まで含めて最小変更を見極めたい
• 役員、上司、顧客へ、なぜその修復方針なのかを整理して説明する必要がある

このような場面では、読み取り中心の切り分け結果を揃えたうえで、株式会社情報工学研究所への相談・依頼をご検討ください。問い合わせフォームは https://jouhou.main.jp/?page_id=26983、お電話は 0120-838-831、技術者直通は 043-422-4240 です。情報工学研究所の問い合わせページでは、24時間対応、無料の電話相談、見積診断無料が案内されています。状況整理が難しい段階でも、個別案件としてどこまでが安全な初動か、どこからが構成判断かを切り分けやすくなります。

本記事の結論は一つです。EXDEV (18) は、単なるコマンドの失敗ではなく、設計や運用の前提に境界があることを知らせるサインです。まずは読み取り中心で境界を確認し、hard link が本当に必要か、別方式に寄せてよいか、どこまでが最小変更かを整理することが大切です。そして、共有ストレージ、コンテナ、本番データ、監査要件など、一般論だけでは判断しにくい条件が重なる場合は、個別案件として専門家へ相談したほうが、結果として被害最小化と早い収束につながります。案件や構成で迷われた際は、株式会社情報工学研究所へのご相談・ご依頼をご検討ください。

はじめに

Linuxシステムにおいてハードリンク作成時に発生するエラーの一つに「EXDEV（18）」があります。このエラーは、異なるファイルシステム間でハードリンクを作成しようとした際に生じるもので、多くの管理者やシステム運用者が直面する課題の一つです。ハードリンクは、同一ファイルシステム内で複数の参照を作る便利な機能ですが、システムの構成やファイルの配置によっては、その制約によりエラーが発生します。本記事では、EXDEVエラーの原因を明確にし、現実的な解決策を提示します。システムの安定運用やデータの安全性を確保しながら問題を解決するために、必要な知識と対応手順を理解しておくことが重要です。これにより、システム管理の効率化とリスクの軽減に役立つ情報を提供します。

EXDEVエラーの根本的な原因は、異なるファイルシステム間での操作に制約があることに起因します。Linuxシステムでは、ハードリンクは同一のファイルシステム内でのみ作成可能です。これは、ハードリンクが実体のファイルの複数の参照を可能にする仕組みであり、ファイルの実体（inode）を複数のディレクトリエントリに紐付けることで実現しています。しかし、異なるファイルシステム間ではinode番号が共有されないため、ハードリンクの作成は技術的に不可能です。そのため、システムはエラーコード18（EXDEV）を返し、操作を拒否します。 このエラーは、単純にファイルをコピーして新たにハードリンクを作成しようとした場合や、異なるマウントポイント間での操作時に頻繁に発生します。例えば、外付けハードディスクやネットワークドライブを使用している場合、これらのデバイスは異なるファイルシステムとして認識されることが多く、その際にハードリンクの作成は制限されるのです。 この章では、EXDEVエラーの技術的背景とその制約について理解を深めることを目的としています。システム管理者や運用者は、なぜこのエラーが発生するのか、その根本的な理由を把握しておくことで、適切な対応策を選択できるようになります。次章では、具体的な事例や実際に遭遇したシナリオを通じて、より詳細な対応方法について解説します。

EXDEVエラーが発生する具体的なシナリオとして、システム管理者が異なるファイルシステム間でデータの整理やバックアップを行う際のケースが挙げられます。例えば、ネットワーク経由で接続されたNASやクラウドストレージにデータを移動しようとした際、既存のファイルのハードリンクを維持したい場合にこのエラーが生じることがあります。これは、ネットワークドライブや外付けデバイスが異なるファイルシステムとして認識されるためです。 また、システムのバックアップや複製作業においても、同一のファイルを複数の場所から参照させるためにハードリンクを利用したい場合がありますが、異なるファイルシステム間ではこれが制限されるため、エラーが発生します。例えば、システムのクローン作成やディスクのパーティション操作中に、ハードリンクの作成を試みると、結果としてEXDEVエラーが返されるケースもあります。 こうした状況では、単に操作を繰り返すだけでは解決できません。システム管理者は、エラーの原因を理解し、適切な対処法を選択する必要があります。具体的には、ファイルのコピーやシンボリックリンクの利用、またはファイルシステムの統合といった方法が考えられます。次章では、これらの対応策の詳細と、それぞれのメリット・デメリットについて解説します。

EXDEVエラーを解決するためには、根本的な原因を理解した上で適切な対応策を選択することが重要です。最も基本的な方法は、ハードリンクの代替手段としてシンボリックリンク（シムリンク）を使用することです。シンボリックリンクは、ファイルやディレクトリへの参照を作成する特殊なタイプのファイルであり、異なるファイルシステム間でも作成可能です。これにより、ハードリンクと同様の参照機能を実現しつつ、エラーを回避できます。 また、ファイルの実体を複製し直す方法もあります。これは、単純に対象ファイルをコピーし、新たにハードリンクを作成しようとした場所に配置するもので、異なるファイルシステム間でも問題なく動作します。ただし、これにはディスク容量や作業時間が増加する可能性があるため、状況に応じて選択する必要があります。 さらに、ファイルシステムの統合やマウント設定の見直しも一つの選択肢です。たとえば、同一のファイルシステム上にデータを配置し直すことで、ハードリンクの作成が可能となります。ただし、これはシステムの構成変更を伴うため、運用計画や影響範囲を十分に考慮した上で行う必要があります。 これらの方法の中から、システムの運用状況やデータの性質に最も適したアプローチを選ぶことが、長期的な安定運用とデータの整合性を保つためのポイントです。次の章では、具体的な操作手順や注意点について詳しく解説します。

EXDEVエラーの解決策の一つとして、最も一般的かつ効果的な方法はシンボリックリンク（シムリンク）を利用することです。シンボリックリンクは、実体のファイルやディレクトリへの参照を作成する特殊なファイルであり、異なるファイルシステム間でも作成可能です。これにより、ハードリンクの制約を回避しながら、ファイルの参照やアクセスを維持できます。具体的な操作は、コマンドラインから「ln -s」コマンドを用いてシンボリックリンクを作成します。ただし、シンボリックリンクはリンク先のファイルが移動や削除されると無効になるため、管理には注意が必要です。 次に、ファイルの実体を複製し直す方法も検討できます。これは、対象ファイルをコピーし、新たにハードリンクを作成しようとする場所に配置する方法です。異なるファイルシステム間でも問題なく動作し、リンクの制約を回避できます。ただし、この方法はディスク容量を消費し、作業時間も増加するため、大量のファイルや頻繁な操作には適さない場合があります。 また、システムの構成を見直し、データを同一のファイルシステム上に配置し直すことも選択肢です。たとえば、複数のパーティションやディスクを統合し、ハードリンクを作成可能な環境を整えることが考えられます。ただし、これはシステムの再構築や設定変更を伴うため、運用計画や影響範囲を十分に検討する必要があります。 これらの方法を選択する際には、データの性質や運用状況を考慮し、長期的な安定性とデータの整合性を確保できる手段を採用することが重要です。適切な対応策を採ることで、システムの信頼性を高め、業務への影響を最小限に抑えることが可能となります。

EXDEVエラーの根本的な解決策として、最も確実な方法はシステム構成の見直しとデータの配置場所の最適化です。特に、複数のファイルシステム間でハードリンクを作成したい場合、同一のファイルシステム内にデータを置くことが最もシンプルで効果的です。これにより、inode番号の共有が可能となり、ハードリンクの作成が制約なく行えます。例えば、システムのパーティションやディスクを再配置し、必要なデータを一つのファイルシステムに集約することが一つの解決策です。 ただし、これはシステムの再構築や大規模な設定変更を伴うため、計画的に行う必要があります。運用中のシステムに対して無理のない範囲で段階的に変更を進めることが望ましいです。データの整合性やシステムの安定性を確保しながら、作業を進めることが重要です。 また、クラウドストレージや外付けデバイスを利用している場合には、ファイルの移動や複製を行う際に、ファイルシステムの違いに注意し、必要に応じて適切な変換や設定を行うことも推奨されます。これらのアプローチは、システムの長期的な運用性とデータの安全性を高めるために役立ちます。 総じて、EXDEVエラーの根本的な解決には、システム全体の構成を理解し、最適な配置と運用方針を策定することが不可欠です。これにより、システムの信頼性を向上させ、日常の運用においても安心して管理できる環境を整えることが可能となります。

本記事では、Linuxシステムにおいてハードリンク作成時に発生するエラーの一つである「EXDEV（18）」について、その原因と解決策を詳しく解説しました。EXDEVエラーは、異なるファイルシステム間でハードリンクを作成しようとした際に生じるものであり、その根本的な原因は、ハードリンクが同一のファイルシステム内でのみ作成可能な仕組みにあります。具体的には、inode番号の共有ができない異なるファイルシステム間では、ハードリンクの作成が制限されるためです。 このエラーを解決するための方法として、シンボリックリンクの活用やファイルの複製、システム構成の見直しなどが挙げられます。それぞれの方法は、システムの運用状況やデータの性質に応じて選択されるべきです。特に、システム構成の見直しやデータの配置場所の最適化は、長期的な安定性と信頼性を確保する上で重要です。 システム管理者や運用者は、これらの知識をもとに適切な対応策を講じることで、システムの信頼性を高め、業務に支障をきたすリスクを低減できます。問題の根本原因を理解し、最適な解決策を選択することが、システムの安定運用において不可欠です。今後も、正確な情報と適切な対応を心掛けることで、システムの安全性と効率性を維持していくことが期待されます。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。

システムの安定運用とデータの安全性を確保するためには、適切な知識と対応策の理解が不可欠です。今回ご紹介したEXDEVエラーの原因と解決策は、日常のシステム管理に役立つ基本的なポイントです。もし、今回の内容に関してご不明点や実際の運用においてお困りのことがあれば、専門のサポートやアドバイスを受けることも検討してください。安心してシステムを運用し続けるためには、信頼できる情報源や専門家の意見を取り入れることも重要です。私たちは、データ復旧やシステム管理の分野で豊富な経験と実績を持っており、ご相談やご質問に丁寧に対応いたします。必要に応じて、専門的なサポートを受けることで、より確実な解決策を見つけることができます。安全なシステム運用を継続するために、まずはお気軽にお問い合わせください。

EXDEVエラーの対処にあたっては、いくつかの重要なポイントに注意を払う必要があります。まず、シンボリックリンクやファイルの複製を行う場合、リンク先の管理や更新に気を配ることが求められます。リンク先のファイルが移動または削除されると、リンクが無効になり、システムの混乱や運用上の問題を引き起こす可能性があります。次に、ファイルシステムの構成を変更する場合には、事前に十分な計画とバックアップを行うことが不可欠です。特に、大規模なシステム再構築やデータ移行では、データの整合性やシステムの安定性を確保するために、専門的な知識を持つ担当者の支援を受けることが望ましいです。 また、異なるファイルシステム間での操作は、データの整合性やセキュリティに影響を与える可能性もあります。たとえば、ファイルのコピーや移動に伴う権限設定の違いに注意し、適切なアクセス権を維持することが重要です。さらに、外付けデバイスやネットワークストレージを使用する場合には、デバイスのファイルシステムタイプやマウント設定を正しく理解し、適切な操作を行う必要があります。 これらの注意点を踏まえ、適切な対応策を選択し、慎重に作業を進めることが、トラブルを未然に防ぎ、システムの安定運用に寄与します。万一に備えて、定期的なバックアップや運用マニュアルの整備も併せて行うことを推奨します。

補足情報

※株式会社情報工学研究所は（以下、当社）は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。