0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【LinuC】「DockerならLinux知らなくても平気でしょ?」と高を括っていた私が、n8nの権限エラーとディスク枯渇で地獄を見た話 🐧🔥

Posted at

こんにちは😊
株式会社プロドウガ@YushiYamamotoです!
らくらくサイトの開発・運営を担当しながら、React.js・Next.js専門のフリーランスエンジニアとしても活動しています❗️

この記事は あの時「もっと◯◯を勉強しておけば!」と思った話 by エルピーアイジャパン Advent Calendar 2025 の参加記事です🎄

私は普段、ノーコードツール n8n を活用して業務自動化を行っています。
n8nはクラウド版もありますが、コストや自由度を考えると 「VPS(Linuxサーバー)上にDockerでセルフホスト」 するのが最強の運用方法です。

当時の私はこう思っていました。
「Dockerがあるんだから、Linuxのコマンドなんて cdls くらい知ってれば余裕でしょw」

……この慢心が、のちに深夜の緊急メンテナンス地獄を招くことになります。

💥 事件1:謎の「Permission denied」無限ループ

n8nをDocker Composeで立ち上げようとした時のことです。
データを永続化するために、ホスト側のディレクトリをマウントしました。

volumes:
  - ./n8n_data:/home/node/.n8n

意気揚々と docker-compose up -d を叩くと、コンテナが即死します。
ログを見ると、無慈悲なエラーメッセージが。

EACCES: permission denied, open '/home/node/.n8n/config'

「え? なんで? 自分のサーバーなのに権限がないってどういうこと?」

💀 何が起きていたのか

当時の私は、「Linuxのユーザーとグループ(UID/GID)」 の概念を全く理解していませんでした。

  1. ホスト側(VPS)では root ユーザーでディレクトリを作成していた(所有者は root:root)。
  2. n8nのコンテナ内では、セキュリティのために node ユーザー(UID: 1000)でプロセスが動いていた。
  3. 「UID 1000 のユーザー」が「root 所有のディレクトリ」に書き込もうとして拒否された。

ただそれだけのことでした。
しかし、基礎知識がない私は「Docker 権限エラー」でググり、意味もわからず chmod 777(全開放)を叩いて解決しようとしました。
セキュリティ・ホール、爆誕です。

🎓 もっと「Linuxの権限」を勉強しておけばよかった!

LinuCレベル1で学ぶ 「ファイル権限と所有者(chown, chmod)」 の知識があれば、以下のようにスマートに対処できたはずです。

# ホスト側のディレクトリを、コンテナ内のユーザーID(1000)に合わせる
chown -R 1000:1000 ./n8n_data

「コンテナ技術」といっても、結局動いているのはLinuxの上。Linuxのユーザー管理の仕組みを知らずにDockerを触るのは、無免許運転と同じだと痛感しました。

💥 事件2:突然のサーバーダウンと「消えないログ」

運用開始から数ヶ月後。
突然、n8nが動かなくなりました。SSHでサーバーに入ろうとしても、動作が重すぎて入れません。

なんとかログインして df -h を叩くと……

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   30G     0 100% /

ディスク使用率 100%。
原因は、Dockerが出力し続けていた ログファイル(json.log) でした。

💀 何が起きていたのか

n8nは自動化ツールなので、大量の実行ログを吐き出します。
私はDockerのログ設定をデフォルトのままにしていました。デフォルトでは、ログのサイズ制限がなく、無限に肥大化します。

Linuxサーバー運用の基本である 「ログローテーション」 の概念が頭になかったため、数十GBのテキストファイルがディスクを食いつぶしていたのです。

🎓 もっと「システム管理」を勉強しておけばよかった!

これも、LinuCで学ぶ 「システムログの管理」「ディスククォータ」 の知識があれば防げた事故でした。

「Dockerだから勝手にやってくれる」わけではありません。
結局、docker-compose.yml に以下のようなログローテーション設定を追加して解決しました。

logging:
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

「ログは放っておくと爆発する」。
このインフラエンジニアの常識を知らなかった代償は、30GBのログファイルを rm する虚しさでした。

🚀 学び直し:ノーコードの裏側には「コード」がある

これらの失敗を通じて、私は痛感しました。
「便利なツール(Dockerやn8n)を使っているからといって、基礎技術(Linux)を無視していい理由にはならない」 と。

むしろ、抽象化されたツールを使うからこそ、トラブルシューティングの際には 「裏で何が起きているか(カーネル、プロセス、ファイルシステム)」 を理解している必要があります。

私がやった学び直し

  1. LinuC レベル1 の教科書を読む
    • 資格を取る予定がなくても、体系的にまとまっているので「辞書」として最強です。
    • 特に「ファイルシステム」「プロセス管理」「ユーザー管理」の章は必読。
  2. 黒い画面から逃げない
    • コピペで済ませていたコマンド(ls -laps aux)の意味を、一つずつ man コマンドで調べる癖をつけました。

まとめ

「アプリケーションエンジニアだから、インフラはAWSやDockerにお任せ」
そう思っている人こそ、一度 Linuxの基礎 に立ち返ってみてください。

  • Permission denied が怖くなくなる。
  • Disk full を未然に防げるようになる。
  • 何より、サーバーの中で何が起きているか「見える」ようになる。

この安心感は、何物にも代えがたいですよ!🐧✨

最後に:業務委託のご相談を承ります

私は業務委託エンジニアとしてWEB制作やシステム開発を請け負っています。最新技術を活用したレスポンシブなWebサイト制作、インタラクティブなアプリケーション開発、API連携など幅広いご要望に対応可能です。

「課題解決に向けた即戦力が欲しい」「高品質なWeb制作を依頼したい」という方は、お気軽にご相談ください。一緒にビジネスの成長を目指しましょう!

👉 ポートフォリオ

🌳 らくらくサイト

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?