トラブル対処集

原因の候補：打ち間違い。まだインストールしていない。違う機械に打っている（Ubuntuで Test-NetConnection を打つ、PowerShellで ip a を打つ、など）。

確かめる：プロンプトを見る。綴りを指導書と1文字ずつ見比べる。全角文字が混ざっていないか。

直し方：正しい画面で打ち直す。インストールが必要なものは、その日の手順を見直す。

原因の候補：管理者の権限が必要な操作に sudo を付け忘れた。ファイルの権限が足りない。

確かめる：ls -l ファイル名 で所有者と権限を見る。

直し方：必要な操作なら先頭に sudo を付けて実行する。SSHの Permission denied (publickey) は別の問題なので、鍵の項目を見る。

原因の候補と直し方：

• 左下に lines 1-20 や (END)：1画面ずつの表示。q
• ping が止まらない：Ctrl+C（-c 3 を付ければ3回で止まる）
• >>> と出ている：Ollamaの会話画面。/bye
• 画面下に ^G Help ^O Write Out：nanoの中。Ctrl+X
• 何を打っても変な動きをする：vimの中かもしれない。Esc → :q! → Enter
• password: で止まっている：パスワードの入力待ち。見えないまま打って Enter
• 何も表示されず待たされる：処理中の可能性（apt、docker pull など）。しばらく待つ

Proxmoxで、うまく動いていた時点のスナップショットに戻せます。VMを選び、「スナップショット」タブで戻したいものを選んで「ロールバック」を押します。その時点より後の変更はすべて消えるので、先に教員に相談し、エビデンスを撮り終えているかも確かめてください。

原因：仮想DVDにISOが入ったままで、そこから起動している。

直し方：VMを止め（Ubuntuで sudo shutdown -h now、またはProxmoxの「シャットダウン」）、Proxmoxの「ハードウェア」→「CD/DVDドライブ」→「編集」→「メディアを使用しない」にして起動し直す（1日目 手順3）。

原因：裏でUbuntuが自動更新をしていて、aptを使用中。

確かめる：ps aux | grep -i apt で、apt や unattended-upgrade が動いているか見る。

直し方：数分待ってからやり直す。ロックのファイルを消すなどの無理な操作はしない。

原因の候補：名前の問い合わせ先（DNSサーバー）の設定が間違っている、またはネットワークにつながっていない。

確かめる：ping -c 3 192.168.100.1（IPアドレスなら届くか）、resolvectl status（問い合わせ先の設定）。

直し方：IPなら届く場合は、Netplanの nameservers の字下げと値を見直して sudo netplan apply。IPでも届かない場合は次の項目へ。

原因の候補：IPアドレス・ゲートウェイの設定ミス、ほかの人とIPアドレスが重なっている、NICの名前（ens18）の間違い。

確かめる：ip a（自分のアドレス）、ip route（default via 192.168.100.1 があるか）。

直し方：/etc/netplan/99-custom.yaml の addresses、routes、NICの名前を見直す。IPアドレスが学生番号どおりか確かめる。

• 行番号つきのエラー：YAMLの字下げ、コロンの後ろのスペース、タブ文字の混入を疑う。sudo netplan generate でも書式を確かめられる
• Permissions for … are too open：sudo chmod 600 /etc/netplan/99-custom.yaml

反映後にネットワークが切れるのが心配なときは、sudo netplan try を使うと、確認しなければ約2分で元に戻る。

原因：Proxmox側の「QEMU Guest Agent」の設定がまだ反映されていない（仮想の部品がない）。

直し方：Proxmoxの「オプション」で有効になっているか確かめ、Ubuntuを sudo shutdown -h now で完全に止めてから「開始」する。再起動（reboot）では反映されないことがある。

原因の候補：VMが止まっている。IPアドレスの打ち間違い。ufwで22番を許可していない。

確かめる：ProxmoxでVMが動いているか。Windowsで Test-NetConnection 192.168.100.xxx -Port 22。コンソールで sudo ufw status と ip a。

直し方：コンソールから sudo ufw allow 22/tcp。IPアドレスを正しく打ち直す。

原因：門（ufw）は開いているが、窓口（SSHのサーバー）が動いていない。すぐに断られるのが「timed out」との違い。

確かめる：コンソールで systemctl status ssh。

直し方：sudo sshd -t で設定の誤りを確かめてから sudo systemctl start ssh。

原因：以前に接続したときと、サーバーの鍵（指紋）が変わった。VMを作り直した、Ubuntuを入れ直した、などで起きる（本当になりすましの場合もあるので、心当たりがないときは教員に相談する）。

直し方：作り直したことが確かなら、Windowsで古い記録を消してから接続し直し、新しい指紋を yes で受け入れる。

ssh-keygen -R 192.168.100.xxx

原因の候補：~/.ssh や authorized_keys の権限が緩すぎる。公開鍵が正しく追記されていない。違う秘密鍵を指定している。

確かめる（サーバー側。パスワード認証が残っていればSSHで、なければコンソールで）：

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
cat ~/.ssh/authorized_keys
sudo journalctl -u ssh -n 30

drwx------（700）と -rw-------（600）になっているか、ssh-ed25519 AAAA… t3-lab の1行があるか。ログに bad ownership or modes とあれば権限の問題。Windows側で ssh -v -i $env:USERPROFILE\.ssh\id_ed25519 t3admin@192.168.100.xxx とすると、どの鍵を試したかが詳しく表示される。

直し方：chmod 700 ~/.ssh、chmod 600 ~/.ssh/authorized_keys。中身がおかしければ、2日目 手順6をやり直す。

Proxmoxのコンソールは、SSHを使わずに直接ログインする方法なので、SSHの設定に関係なく入れます。コンソールからログインし、設定を戻すか直します。

sudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl restart ssh

バックアップを取っていなかった場合は、sudo nano /etc/ssh/sshd_config で PasswordAuthentication を一時的に yes に戻し、鍵の問題を直してから no に戻します。確認のために ssh-keygen で鍵を上書きしてしまった場合も、コンソールから新しい公開鍵を登録し直します。

原因の候補：Windows PowerShell 5.1 で ~ を使った。今いるフォルダに送りたいファイルがない。

確かめる：プロンプトで今いるフォルダを見る。Get-ChildItem でファイルがあるか確かめる。

直し方：~ の代わりに $env:USERPROFILE を使う（PowerShellの注意）。ファイルのあるフォルダに cd してから実行する。

原因：docker の前に sudo を付け忘れた。

直し方：sudo docker … と打ち直す。↑ で前のコマンドを呼び出し、先頭に sudo を足すと早い。

原因：compose.yaml のないディレクトリで実行している。ファイル名の打ち間違い（compose.yml、Compose.yaml など）。

確かめる：pwd と ls。

直し方：cd /opt/compose-demo（その日のディレクトリ）に移動してから実行する。

原因：YAMLの書き方の誤り。字下げのずれ、タブ文字、コロンの後ろのスペース忘れ、- （ハイフンとスペース）の忘れなど。

直し方：表示された行番号の前後を、このガイドの例と字下げの深さまで見比べる。nanoでは Alt+Shift+3 で行番号を表示できる。

原因：そのポートを、ほかのコンテナやプログラムがすでに使っている。前の日の構成を止め忘れていることが多い。

確かめる：sudo docker ps（動いているコンテナとポート）、sudo ss -tlnp（どのプログラムが待ち受けているか）。

直し方：不要な構成のディレクトリで sudo docker compose down。

• toomanyrequests：Docker Hubには、ログインせずに取得できる回数に上限がある。教室全員が同じ出口のIPアドレスを共有していると、上限に達することがある。時間をおいてやり直すか、教員に相談する
• timeout、no such host：サーバーから外に出られていない。ping -c 3 www.google.co.jp で確かめる（1日目の項目）

原因の候補：/opt/nginx/html/index.html がまだない。名前が違う（index.htm、Index.html）。ファイルの権限で読めない。

確かめる：ls -l /opt/nginx/html。

直し方：4日目 手順3のとおりに index.html を作る。権限が -rw-r--r-- でなければ sudo chmod 644 /opt/nginx/html/index.html。

原因：URLのファイル名と、実際のファイル名が違う。Linuxは大文字と小文字を区別する。GoAccessのレポートをまだ作っていない。

直し方：ls /opt/nginx/html で実際の名前を確かめ、URLを合わせる。

原因：Windowsがその名前をIPアドレスに変換できていない。

確かめる：Windowsで nslookup www.t3.metro-cit.internal（Windowsが普段使っているDNSに問い合わせる）。

直し方：授業の指示に従い、Windowsのhostsファイルを設定するか、DNSを使う（1日目 hosts、付録2）。確認だけならIPアドレスで開いてよい。

原因の候補：まだアクセスがない。アクセスログのファイルがない。

確かめる：sudo ls -l /opt/nginx/log/access.log、sudo tail -n 5 /opt/nginx/log/access.log。

直し方：ブラウザで何度かページを開いて記録を増やしてから、cd /opt/nginx で移動して sudo docker compose run --rm goaccess をやり直す。

• named-checkconf でエラー：表示された行の ; や }; の抜け、" の閉じ忘れ
• named-checkzone でエラー：名前の最後の . の有無、SOAの括弧の閉じ忘れ、シリアル番号の桁
• nslookup で timed out：sudo ufw status で 53/udp が許可されているか、systemctl status bind9 で動いているか
• NXDOMAIN（名前がない）：ゾーン名とファイル名、www の行を見直す。直したらシリアル番号を増やして sudo systemctl restart bind9

原因の候補：Ollamaが 127.0.0.1 でしか待ち受けていない。ufwで11434番を許可していない。

確かめる：サーバーで ss -tln | grep 11434 と sudo ufw status、Windowsで Test-NetConnection 192.168.100.xxx -Port 11434。

直し方：6・7日目 手順2の OLLAMA_HOST の設定と、sudo ufw allow 11434/tcp（授業の指示を確認してから）。

原因：Windows PowerShell 5.1 では curl が別のコマンドの別名。PowerShell 7 の curl では日本語の質問が化けて送られる。

直し方：Invoke-RestMethod を使う書き方にする（6・7日目 手順2）。

原因の候補：コンテナからホストのOllamaに届いていない（Ollamaが 127.0.0.1 でしか待ち受けていない、ufwで止められている、extra_hosts の書き忘れ）。

確かめる：Open WebUIのコンテナの中からOllamaに話しかけてみる。Ollama is running と返れば届いている。

sudo docker exec open-webui curl -s http://host.docker.internal:11434

直し方：届かなければ、手順2の OLLAMA_HOST とufwの設定を行い、cd /opt/open-webui で移動して sudo docker compose restart。届いているのにモデルが出なければ、サーバーで ollama list を実行してモデルが入っているか確かめる。

原因：Nginx（受付）は動いているが、取り次ぎ先（Open WebUI、自作のチャット）が応えない。起動中か、止まっている。

確かめる：取り次ぎ先のディレクトリで sudo docker compose ps と sudo docker compose logs --tail 30。

直し方：起動の途中なら数分待つ。止まっていれば、ログのエラーを読んでから sudo docker compose up -d。

原因：AIの答えが出るのが遅く、Nginxが待ちきれずに打ち切った。

直し方：取り次ぎの設定に proxy_read_timeout 300s; を入れて nginx -t と nginx -s reload（手順7）。短い質問で試す。

原因：設定に書いた取り次ぎ先の名前（open-webui、chat-backend）のコンテナが動いていない、または app-net に参加していない。

確かめる：sudo docker ps、sudo docker network inspect app-net（参加しているコンテナの一覧）。

直し方：取り次ぎ先を先に起動する。compose.yaml の networks: を見直す。

原因：app-net をまだ作っていない。

直し方：sudo docker network create app-net を実行してから、もう一度 up -d。

原因の候補：メモリ不足（仮想マシンは1024 MB）。

確かめる：

free -h
sudo docker stats --no-stream
sudo dmesg | grep -i -E "out of memory|killed process"

最後のコマンドで何か表示されれば、メモリが足りずにプログラムが強制終了させられています。

直し方：使っていない構成を止める（3日目の whoami など）。それでも足りなければ、メモリを増やせるか教員に相談する。

確かめる：df -h（ディスクの残り）、sudo docker system df（Dockerが使っている量）。

直し方：使わなくなったイメージを消す（sudo docker image prune は、どのコンテナにも使われていない名前なしのイメージを消す）。何を消すかを確かめてから実行し、判断に迷ったら教員に相談する。