インフラ作業支援ラボInfra Support Lab ← ガイド一覧← 戻る
トップ > ガイド > トラブル解決 > Failed to enable
トラブル解決ガイド｜更新日：2026年10月11日

systemctl enableでFailed to enableになる原因と確認手順

systemctl enable 自体が Failed to enable などで失敗するとき、Unitの存在・有効化方式・static / masked・権限を分けて確認します。enable成功後の自動起動失敗とは別に扱います。

このページの目的

systemctl enableコマンドそのものが失敗・警告になる場合を対象にします。enableが成功したのに再起動後に起動しない問題とは分けて確認します。

最初にやること

エラー文を残したまま、systemctl cat、systemctl is-enabled、systemctl list-unit-filesでUnitの存在と有効化方式を確認します。

設定ガイド

WantedBy=multi-user.targetとは

Unitをどのtargetへ紐づけるかと、[Install]の役割を確認します。

設定を確認 →トラブル

enableしたのに自動起動しない

enableは成功しているのに再起動後に起動しない場合はこちらで切り分けます。

起動しない原因を確認 →設定ガイド

daemon-reloadはいつ必要？

Unitファイル変更後にdaemon-reloadが必要な場面と反映手順を確認します。

反映手順を確認 →
このページの対象：enable自体が失敗する・有効化できない場合です。enableは成功しているのにOS起動時に立ち上がらない場合はenableしたのに自動起動しないガイド、WantedByの意味はWantedByガイドへ分けています。

[Install]を追加する前にレビュー

WantedByやAliasを推測で足す前に、Unit全体の設定と依存関係を確認します。

systemd Unitをレビュー

まず「存在」「enable状態」「Unit実体」を分けて確認

systemctl status example.service --no-pager -l systemctl cat example.service systemctl is-enabled example.service systemctl list-unit-files 'example*'

Unit名の打ち間違いと、Unitは存在するが通常のenable対象ではない状態を混同しないことが重要です。エラーを消すためだけに[Install]を追加する前に、どのUnitやtargetから起動される設計かを確認します。

Failed to enable unit: Unit file ... does not exist

まずUnit名と配置場所を確認します。テンプレートUnitなら、example@.serviceとexample@worker.serviceのように名前の意味も確認します。

systemctl list-unit-files | grep -F example systemctl cat example.service find /etc/systemd/system /usr/lib/systemd/system /lib/systemd/system -maxdepth 1 -name 'example*.service' -ls 2>/dev/null
配置先を決め打ちしない：ディストリビューションによってベンダーUnitの配置場所は異なります。systemctl catやsystemctl show -p FragmentPathで実際に読まれている場所を確認します。

no installation configやstaticは「壊れている」とは限らない

The unit files have no installation configやstaticは、そのUnitが単独でenableされる設計ではなく、依存関係・socket・timer・別Unitなどから起動される構成を示す場合があります。

systemctl is-enabled example.service systemctl cat example.service systemctl list-dependencies --reverse example.service

[Install]やWantedBy=を追加すれば必ず正しくなるわけではありません。自動起動の仕組み自体を確認する場合はWantedByの専用ガイドへ進みます。

maskedなら、なぜmaskされているかを先に確認

systemctl is-enabled example.service systemctl cat example.service ls -l /etc/systemd/system/example.service /run/systemd/system/example.service 2>/dev/null

maskはUnitを起動できないようにする明示的な制御です。運用上の理由やパッケージの設計でmaskされている可能性もあるため、理由を確認せずunmaskしないようにします。

すぐにunmaskしない：障害回避や競合サービス停止のためにmaskされている場合があります。構成管理・変更履歴・依存関係を確認してから判断します。

Permission deniedやRead-only file systemなら書込み先を確認

enableはUnitの有効化情報に基づいてシンボリックリンク等を作成します。一般ユーザー権限、読み取り専用ファイルシステム、構成管理上の制約などで変更できない場合があります。

id mount | grep ' / ' findmnt -T /etc/systemd/system ls -ld /etc/systemd/system

system unitの変更では通常管理者権限が必要です。ただし、権限エラーを見てディレクトリのモードを緩めるのではなく、正しい権限で操作しているかを確認します。

古い環境ではsystemd管理かSysV管理かを確認

既存環境ではSysV init scriptを互換的に扱っている場合があります。まずPID 1とsystemdの有無を確認し、systemd環境なのか、古いinit方式なのかを分けます。

ps -p 1 -o comm= systemctl --version 2>/dev/null || true

古い手順書にchkconfigやupdate-rc.dが書かれていても、現在の環境がsystemdなら新旧の有効化方式を混ぜない方が安全です。

エラー別の次の対応

表示・状態対処
Unit file ... does not existUnit名・テンプレート名・配置先を修正し、Unitファイルを追加/変更した場合はsystemctl daemon-reload後に再度enableします。
static / no installation configそのUnitが直接enableする設計か確認します。依存元から起動されるstatic Unitなら無理に[Install]を追加しません。自作Unitで自動起動要件がある場合のみ、正しいtargetとの関係を設計して[Install]を追加します。
maskedmaskされた理由と運用影響を確認し、解除が正当な場合だけsystemctl unmask後にenableします。意図的な停止制御を勝手に解除しません。
Permission denied / Read-only file systemsudo権限、Unit配置先、ファイルシステム状態を修正します。モードを広げて回避せず、書込み先と運用権限を正します。
enableは成功したが再起動後に起動しないenable処理は解決済みです。enableしたのに自動起動しないへ切り替えて起動時ログ・依存関係を修正します。

修正後の再確認

systemctl is-enabled example.service systemctl list-unit-files example.service systemctl status example.service --no-pager

自動起動が目的なら、is-enabledが期待状態になったことだけでなく、Unitの起動自体が成功することも確認します。Unitファイルを変更した場合はsystemd-analyze verifyとdaemon-reloadを先に実施してください。

enable成功＝サービス正常ではありません。登録の問題と実行時の問題を分け、起動失敗が残る場合はsystemd起動トラブル側へ移ります。
start時にUnitが見つからない場合：このページはenable操作の失敗が対象です。systemctl startでUnit not foundが出る場合は、起動時のUnit not found専用ガイドを確認してください。