Hermes LXCのSambaマウント作業記録（2026-10-09）

Hermes LXCからSamba共有を利用するための作業記録

記録日: 2026-10-09（UTC）
最終読み取り再確認: 2026-10-09 11:33 UTC

1. 目的と到達点

HermesからSambaの share 全体へアクセスし、素材や文書を利用できるようにする。利用者の合意した方針はRW（読み書き）であり、Assets専用の読み取り専用共有へ切り替える作業ではない。

到達点: ホストでCIFSマウントした共有を非特権LXCへバインドし、実行ユーザー hermes でAssetsとPatchouliの一覧取得、および実ファイルの読み取りに成功。

RWマウントは確認したが、実際の書き込みは未テスト。Proxmoxホスト再起動後の自動復旧も未確認。

2. 確認した構成

Sambaサーバー 192.168.0.199（Proxmox CT 199、名前 samba）
  /srv/share
  SMB共有 //192.168.0.199/share
          ↓ CIFS、SMB 3.1.1、RW、認証ユーザー lulu
Proxmoxホスト（端末プロンプト root@minase）
  /mnt/bindmounts/hermes-share
          ↓ CT 103 の mp0 によるバインド
Hermes（Proxmox CT 103、非特権LXC）
  /mnt/share
  実行ユーザー hermes（UID/GID 1000）

利用者が提示した pct config 103 の関連項目:

hostname: hermes
mp0: /mnt/bindmounts/hermes-share,mp=/mnt/share
unprivileged: 1
onboot: 1
net0: name=eth0,bridge=vmbr0,gw=192.168.0.1,hwaddr=BC:24:11:D8:F0:01,ip=192.168.0.103/24,type=veth

コンテナで確認したUID/GIDマッピング（双方同じ）:

0 100000 65536

ホスト側のCIFS所有者指定は uid=101000,gid=101000。コンテナではこれが実行ユーザーのUID/GID 1000に対応している。これはクライアント側の所有者表示・アクセス設定であり、サーバー側のUnix認可とは別。

3. アクセス拒否の状況

当初、共有直下では Games、Assets、Media、Zotero-backup、Patchouli、obsidian の一覧を取得できた。一方、/mnt/share/Assets と /mnt/share/Patchouli は Permission denied で一覧取得や内部ファイルの読み取りができなかった。

利用者がSambaサーバーで提示した情報:

uid=1001(lulu) gid=1001(lulu) groups=1001(lulu),1003(share)
/srv/share           root:share     drwxrwx---
/srv/share/Assets    minase:minase  drwxrwx---
/srv/share/Patchouli minase:minase  drwxrwx---

変更前の有効な共有設定:

[share]
        create mask = 0660
        directory mask = 0770
        path = /srv/share
        read only = No
        valid users = minase lulu

表示された通常のUnix権限では、luluはshareグループに属するがminaseグループには属さず、対象の子ディレクトリへのアクセス権を持たない状態だった。ACL全体の調査はしていないため、モード表示だけを完全な権限監査結果とは扱わない。

注意: sudo -u lulu -- ls -ld <ディレクトリ> はディレクトリ自身のメタデータ確認であり、内部を一覧取得できることの証明ではない。

4. 合意したサーバー側の変更

利用者に影響範囲を説明し、同意を得て、Sambaサーバーの /etc/samba/smb.conf の [share] に次の1行を追加する方式を採用した。

        force user = minase

変更後の意図した設定:

[share]
        create mask = 0660
        directory mask = 0770
        path = /srv/share
        read only = No
        valid users = minase lulu
        force user = minase

認証はluluのまま、当該共有でのファイル操作をminaseのUnix権限で行う方針。この設定は当該共有へ許可された接続全体に影響し、luluによる操作もUnix上ではminaseとして扱われる。新規ファイルの所有者・Unixレベルの操作帰属をluluと分ける方式ではない。

既存ファイルへの再帰的なchmod/chown、luluのminaseグループへの追加、LXCの特権化は実施していない。

利用者に案内したコマンド（Sambaサーバー上）:

cp -ai /etc/samba/smb.conf /etc/samba/smb.conf.before-force-user
nano /etc/samba/smb.conf
# [share] に force user = minase を追加

testparm -s
# 検査で問題がない場合だけ再読み込み
smbcontrol smbd reload-config
testparm -s --section-name=share

利用者は設定変更済みと報告した。変更後のtestparm全文とバックアップファイルの実在は、この会話では読み戻していない。上記を「全コマンドの実行ログが確認済み」とは扱わない。

5. 新規接続と既存マウントの切り分け

利用者が次の新規接続でAssetsの一覧取得成功を報告:

smbclient //192.168.0.199/share -U lulu -W WORKGROUP \
  -c 'cd Assets; ls'

しかしHermes側の既存CIFSマウントでは、引き続きAssets/Patchouliへのアクセスが拒否された。ホスト側でも次の一覧取得が Permission denied だった。

ls -la /mnt/bindmounts/hermes-share/Assets

新しい接続は成功し、ホスト側の既存接続は失敗する状況だったため、既存マウントの再接続へ進んだ。設定再読み込みと、すでに有効な接続への設定反映は区別した。

6. ホスト側の再接続手順

以下は利用者へ案内した手順。実行場所はすべてProxmoxホストのroot端末。Hermes自身のCTを停止するとチャット応答も一時的に止まることを事前に説明した。

pct shutdown 103 --timeout 60
pct status 103
# status: stopped を確認してから次へ

umount /mnt/bindmounts/hermes-share
# 解除成功時だけ次へ

mount -t cifs //192.168.0.199/share /mnt/bindmounts/hermes-share \
  -o username=lulu,domain=WORKGROUP,vers=3.1.1,rw,uid=101000,gid=101000,forceuid,forcegid,file_mode=0600,dir_mode=0700,nosuid,nodev,noexec
# パスワードは端末のプロンプトへ入力

findmnt -M /mnt/bindmounts/hermes-share -o TARGET,SOURCE,FSTYPE,OPTIONS
ls -la /mnt/bindmounts/hermes-share/Assets

pct start 103
pct status 103

失敗時の扱い:

正常終了に失敗した場合、強制停止せず調査する。
umountに失敗した場合、重ねてmountせず、既存マウントを残したままCTを起動して復旧する。
umount成功後、再mountに失敗した場合、必要な共有が未マウントのままCTを起動しない。ホスト側で共有接続を復旧してから起動する。
強制/lazyアンマウントやSambaサービス全体の再起動は案内していない。

利用者が「戻ったよ」と報告し、その後のHermes側でアクセス成功を確認した。ホスト上の手順全体の実行ログは受け取っていないため、成功証拠は復帰後の実測を中心とする。

7. 復帰後の実測結果

実行ユーザー:

uid=1000(hermes) gid=1000(hermes) groups=1000(hermes)

findmnt -M /mnt/share でCIFSの共有が確認できた。下層のext4バインドも同じパスに表示されるが、実際の一覧・ファイル読み取りは共有側で成功した。

関連する実測マウントオプション:

source=//192.168.0.199/share
fstype=cifs
rw,nosuid,nodev,noexec,vers=3.1.1
username=lulu,domain=WORKGROUP
uid=101000,forceuid,gid=101000,forcegid
file_mode=0600,dir_mode=0700

確認項目:

/mnt/share/Assets の一覧取得: 成功。
/mnt/share/Patchouli の一覧取得: 成功。
/mnt/share/Assets/Fantasy Earth Zero/ミニキャラ(5国王+シャンテ).zip を開き、先頭64バイトを読み取り: 成功。内容はチャットへ出力していない。
後続作業で /mnt/share/Assets/Live2d/gochic.zip を読み取り、Hermesのローカル作業領域へ展開: 成功。共有上のZIPは変更していない。
文書作成前（2026-10-09 11:33 UTC）にも上記2ディレクトリの一覧とZIP先頭64バイトの読み取りを再確認: 成功。

8. 未検証事項と認証情報の扱い

実ファイル・ディレクトリの作成、変更、削除による書き込み試験は未実施。RW表示は書き込み成功の証明ではない。
ホスト側のfstab、systemdマウント設定、起動時の依存関係は未調査・未変更。
onboot: 1 はCTの設定として確認したが、共有が先にマウントされることは未確認。
Proxmoxホスト再起動後の共有の自動マウント・Hermesの自動復旧は未検証。
今回の再接続は端末のパスワードプロンプトを使う案内。認証情報をチャットやコマンド引数へ記載していない。
ホスト側の既存認証ファイルの有無、保存場所、権限は調査していない。Hermesが認証情報を読めないことを含む秘密情報隔離の完全な監査は未実施。
最終的なサーバー設定の全文、既存バックアップの実在は未確認。

9. 今後確認するなら

ホスト側の永続マウント設定と秘密情報の保管境界を、秘密そのものを出力せず確認する。
ホスト起動時のマウントとCT起動の順序を確認する。
必要なら合意した専用ディレクトリで、空ディレクトリ作成・削除などの最小限のRW試験を行う。
再起動試験は通信断と復旧手段を事前に説明してから行う。

この文書は作業記録であり、自動実行スクリプトではない。未検証事項を完了済みとして扱わない。

出典

2026-10-09のDiscord「Sambaマウントの続き」スレッドでの利用者提供ログとHermesの実測結果。
このノートの作成・読み戻しにより、/mnt/share/Patchouli/lulu/ へのMarkdownファイル書き込みも検証する。共有全体の書き込み可否を保証するものではない。