AlmaLinux 9 一覧へ戻る トップ ／ AlmaLinux 9 ／ Phase 1 Samba基盤構築マニュアル
AlmaLinux 9 ・ ゼロトラスト統合基盤検証ロードマップ

Phase 1 Samba基盤構築マニュアル

Quadletによる Samba ファイルサーバ構築、LAN内疎通検証、実機トラブルと解決の記録

実施日：2026年8月3日 Samba基盤：構築・DoD達成 Authentik連携：未実施（次工程）

本ページの位置づけについて

ロードマップ上の「Phase 1：ハイブリッドストレージ＆ゼロトラスト認証・認可（RBAC）」は、本来 authentik連携によるグループ別フォルダ表示・MFA強制 までを完成条件（DoD）としています。本ページで実施・検証したのは、その土台となるSamba単体の構築とLAN内アクセス検証までです。authentik LDAP Outpost連携・グループ別ACL・Nextcloud/OnlyOffice統合は未実施のため、Phase 1全体としては「一部完了」の状態です。詳細は「11. 未実施項目と次ステップ」をご確認ください。

目次

  1. ネットワーク＆フォルダ設計
  2. STEP 1：共有ディレクトリ作成＆SELinux設定
  3. STEP 2：Samba設定ファイル（smb.conf）
  4. STEP 3：Samba Quadletファイルの定義
  5. STEP 4：サービスの有効化＆起動
  6. トラブル①：Windowsゲストアクセスのブロック
  7. トラブル②：存在しないグループ参照（@smbgroup）
  8. トラブル③：ファイル所有者の不一致
  9. STEP 5：LAN側疎通確認（DoDエビデンス）
  10. 精査メモ：Sambaユーザーの永続化について
  11. 未実施項目と次ステップ

1. Phase 1 ネットワーク＆フォルダ設計

項目内容
ホストIP192.168.2.3（AlmaLinux 9）
SMBポートTCP 445
パブリック共有/srv/samba/public（全ユーザー・ゲスト共有）
プライベート共有/srv/samba/private（認証ユーザーのみ）
Samba設定ファイル/srv/containers/samba/smb.conf

2. STEP 1：共有ディレクトリ作成＆SELinux設定

sudo mkdir -p /srv/samba/public
sudo mkdir -p /srv/samba/private
sudo mkdir -p /srv/containers/samba

sudo chmod -R 777 /srv/samba/public
sudo chmod -R 770 /srv/samba/private

sudo chcon -t container_file_t -R /srv/samba/
実機での適用結果
system_u:object_r:container_file_t:s0:c537,c901 private
system_u:object_r:container_file_t:s0:c537,c901 public

3. STEP 2：Samba設定ファイル（smb.conf）

下記は実機で最終的に稼働している内容です（privateのvalid usersはトラブル②の対応により修正済み）。

sudo tee /srv/containers/samba/smb.conf << 'EOF'
[global]
   workgroup = WORKGROUP
   server string = Home Server Samba
   security = user
   map to guest = Bad User
   log file = /var/log/samba/log.%m
   max log size = 1000
   guest account = nobody

[public]
   comment = Public Shared Directory
   path = /mount/public
   browseable = yes
   writable = yes
   guest ok = yes
   read only = no
   force user = nobody

[private]
   comment = Private Shared Directory
   path = /mount/private
   browseable = yes
   writable = yes
   guest ok = no
   valid users = smbuser
EOF

4. STEP 3：Samba Quadletファイルの定義

sudo tee /etc/containers/systemd/samba.container << 'EOF'
[Unit]
Description=Samba File Server Container
After=network-online.target identity-dns-ntp.service
Requires=network-online.target

[Service]
Restart=always
RestartSec=10

[Container]
ContainerName=samba-server
Image=docker.io/dperson/samba:latest
Network=host
Volume=/srv/containers/samba/smb.conf:/etc/samba/smb.conf:Z
Volume=/srv/samba/public:/mount/public:Z
Volume=/srv/samba/private:/mount/private:Z

[Install]
WantedBy=multi-user.target
EOF

Network=host により、LAN内からのSMB（Port 445）名前解決やレスポンス速度を最大化しています。

5. STEP 4：サービスの有効化＆起動

sudo systemctl daemon-reload
sudo systemctl start samba
sudo systemctl status samba --no-pager
実機での結果（2026-08-03 20:50 JST）
● samba.service - Samba File Server Container
     Active: active (running) since Mon 2026-08-03 20:50:16 JST
   Main PID: 284314 (conmon)
 8月 03 20:50:16 samba-server[284314]: smbd version 4.12.2 started.
 8月 03 20:50:17 samba-server[284314]: daemon_ready: daemon 'smbd' finished starting up and ready to serve connections

精査ポイント：enable ではなく start

Phase 0で判明した通り、Quadlet生成ユニットはdaemon-reload時点で自動的に有効化されるため、enableは不要です。本手順も最初からstartのみで正しく起動しています。

6. トラブル①：Windowsゲストアクセスのブロック

発生した事象

手順書通りにpublic共有（ゲストアクセス）へWindows 11から接続を試みたところ、以下のエラーで拒否されました。

「組織のセキュリティポリシーにより、認証されていないゲストアクセスがブロックされています」（Insecure Guest Logon Block）

原因

Samba側の設定に問題はありません。Windows 10/11は近年、認証なし（ゲスト）SMBアクセスをクライアント側のセキュリティポリシーでデフォルトブロックするようになっています。手順書の設計（guest ok = yesによるパブリック共有）は、現行のWindows既定設定とは相性が悪い状態です。

今回の対応

未解決（既知の制限として記録）

今回はpublic共有のゲストアクセス自体の修正は行わず、認証付きのprivate共有側で検証を継続しました。publicを実際に使う場合は、Windowsクライアント側で「安全でないゲストログオンを有効にする」ポリシーを変更するか、public側にも認証ユーザーを設定する方針転換が必要です。

7. トラブル②：存在しないグループ参照（@smbgroup）

発生した事象

手順書のsmb.confではprivate共有にvalid users = @smbgroupを指定していましたが、このグループを作成する手順が手順書に含まれていませんでした。コンテナ内を確認したところpdbedit -L（登録済みSambaユーザー一覧）が空で、誰もprivate共有にログインできない状態でした。

対応

グループを新規作成する代わりに、コンテナに既定で存在するUNIXユーザーsmbuserを直接指定する方式に変更しました。

sudo sed -i 's/valid users = @smbgroup/valid users = smbuser/' /srv/containers/samba/smb.conf
sudo systemctl restart samba
sudo podman exec -it samba-server smbpasswd -a smbuser

8. トラブル③：ファイル所有者の不一致（Access Denied）

発生した事象

smbuserでのログイン（net use）自体は成功しましたが、private共有へのファイル書き込み・読み込み・削除がすべて「アクセスが拒否されました」で失敗しました。

原因
項目実際の値
ホスト側 /srv/samba/private の所有者root:root（sudo mkdirで作成したため）
ディレクトリ権限770（所有者・所有グループのみアクセス可）
コンテナ内 smbuser のUID/GID100 / 101

Samba認証（SMBレベル）は成功していても、コンテナ内で実際にファイルへアクセスするのはsmbuser（UID100/GID101）のLinuxプロセスです。フォルダの所有者がroot（UID0/GID0）のままだったため、Linuxの標準パーミッションで拒否されていました。

対応
sudo chown -R 100:101 /srv/samba/private

9. STEP 5：LAN側疎通確認（DoDエビデンス）

Windows 11クライアント（192.168.2.xセグメント内）から、コマンドプロンプト経由で認証・書き込み・読み込み・削除を実施しました。

実機エビデンス（2026-08-03 実施）
C:\>net use \\192.168.2.3\private /user:smbuser
（パスワード入力）
コマンドは正常に終了しました。

C:\>echo Phase1 DoD test > "\\192.168.2.3\private\test.txt"
（成功・エラーなし）

C:\>type "\\192.168.2.3\private\test.txt"
Phase1 DoD test

C:\>del "\\192.168.2.3\private\test.txt"
（成功・エラーなし）

DoD達成状況

10. 精査メモ：Sambaユーザーの永続化について

重要：現状のsmbuserパスワードはコンテナ再起動で消えます

Samba Quadletの起動コマンドには--replace --rmが使われており、コンテナは停止のたびに破棄され、次回起動時にイメージから新規に作り直されます。今回podman execで対話的に設定したsmbpasswd -a smbuserはコンテナの一時領域に保存されているため、ホスト再起動やサービス再起動（systemctl restart sambaを除く現在稼働中のプロセスのみ有効）で消える可能性があります。今回はあくまで動作検証のための一時設定です。恒久的に使うには、次のいずれかが必要です。

Samba基盤構築・LAN内DoD達成 🎉

Quadletによるコンテナ化、SELinuxラベル設定、認証付き共有（private）でのLAN内書き込み・読み込み・削除の検証まで完了しました。全体ロードマップは「ゼロトラスト統合基盤検証ロードマップ」を、基盤フェーズは「Phase 0 実践構築マニュアル」をご参照ください。

11. 未実施項目と次ステップ

ロードマップ上のPhase 1完成条件（DoD）と比較した、現時点での未実施項目です。

上記のうち、優先度が高いのは「Sambaユーザーの永続化」と「authentik LDAP Outpost連携」の2点である。

AlmaLinux 9 一覧へ戻る
← ゼロトラスト統合基盤検証ロードマップ（全体像） ← Phase 0 実践構築マニュアル