Sambaとは、Windowsのファイル共有プロトコルSMBをLinuxで話すオープンソースのサーバーソフトウェアで、Ubuntuではaptのsambaパッケージとして入ります。SMBという規格そのものではなく、規格を実装したプログラム群のことで、ファイル共有を受け持つのはsmbdというデーモンです。執筆時点でUbuntu 26.04.1のアーカイブから入るのはSamba 4.23.6で、ここに載せたコマンドと出力はすべてこの版で実行したものです。
対象は、NASを買うほどではないが部署ごとの共有フォルダをLinuxで用意したい情シス担当者と、ホームラボの運用者です。検証ではサーバー役の1台目に総務部の読み書き共有と、営業部には閲覧だけを許す規程集の共有を作り、クライアント役の2台目からsmbclientで3人分のアカウントを切り替えて読み書きしました。読み終えると、同僚のファイルを互いに編集できる権限設計のsmb.confと、つながらないときにエラーコードとサーバーログから原因を絞る手順、445番ポートをLANの外に出さない設定が手元に残ります。
この記事でわかること
- Linuxグループ・setgidディレクトリ・
force group・create maskを組み合わせ、2人が書いたファイルが同じグループと同じ権限になることをls -lで確かめる手順 valid usersの打ち間違いとforce groupが重なると他部署の人が書き込めてしまう実例と、force group = +somuで防ぐ方法- NT_STATUS_LOGON_FAILURE・ACCESS_DENIED・BAD_NETWORK_NAMEとSMB1の拒否を再現し、サーバーログで原因を見分ける方法
- ゲストと匿名を使わず、445番をLAN内に限り、SMB3の暗号化を有効にする設定
- Samba on Ubuntu・TrueNAS SCALE・市販NAS・SharePoint／Googleドライブを選ぶ判断表
SambaとSMBの関係と、今回の検証構成
SMBはWindowsがファイルやプリンターを共有するための通信規約で、現在はTCPの445番ポートで直接やり取りします。Sambaはこの規約をLinuxに実装したもので、役割ごとにデーモンが分かれています。ファイル共有と認証を担うのがsmbd、NetBIOSの名前解決と一覧表示を担うのがnmbd（UDPの137番と138番）、Active Directoryのユーザーを引き込むのがwinbinddです。部署のファイルサーバーに必要なのはsmbdだけで、nmbdは動かしません。
最初に押さえておきたいのは認証の仕組みです。SambaはLinuxのログインパスワード（/etc/shadow）を使わず、SMBの認証に必要なハッシュを専用のデータベースに持ちます。既定はtdbsam形式の/var/lib/samba/private/passdb.tdbで、Linuxユーザーを作っただけではログインできず、smbpasswd -aで登録して初めて使えます。一方でファイルの読み書きはLinuxユーザーのUIDで行われるので、Sambaしか使わない人にも同名のLinuxアカウントが要ります。
アクセスの可否は2段階で決まります。1段目は共有の設定（valid users、read only、write list）で、ここで断られると共有に入れません。2段目は、接続したユーザーのUIDとグループで判定されるLinuxのファイル権限です。今回の設計は、1段目で部署を絞り、2段目のグループ権限で「同じ部署の全員が互いのファイルを書き換えられる」状態を作る2段構えです。
検証環境は、Ubuntu 26.04.1のコンテナ2台を専用のブリッジネットワーク（192.168.50.0/24）でつないだものです。サーバーのnagoyadevlab01が192.168.50.10、クライアントのnagoyadevlab02が192.168.50.20で、どちらのポートもホストの外には公開していません。この2つのホスト名とIPアドレスは検証用に付けたものなので、自分のサーバー名とネットワークに読み替えてください。コンテナではsystemdを動かしていないため、smbdはsmbd --foreground --no-process-groupで直接起動しました。systemctlを使う手順はこの環境では実行していないので、該当するブロックにその旨を書いています。
grep VERSION= /etc/os-release
VERSION="26.04.1 LTS (Resolute Raccoon)"
smbd --version
Version 4.23.6-Ubuntu-4.23.6+dfsg-1ubuntu2.2
smbclient --version
Version 4.23.6-Ubuntu-4.23.6+dfsg-1ubuntu2.2作るのは2つの共有と3つのアカウントです。例として、ryomaとsatoは総務部（Linuxグループsomu）、suzukiは営業部（グループeigyo）に属するものとします。アカウント名、グループ名、共有名（somu、kitei）はどれも検証用の例なので、自社の利用者と部署に合わせて決めてください。表の「一覧にも出ない」は、後で設定するaccess based share enumの効果です。
| アカウント（例） | グループ | somu（総務部の共有） | kitei（社内規程） |
|---|---|---|---|
| ryoma | somu | 読み書き | 読み書き |
| sato | somu | 読み書き | 読み書き |
| suzuki | eigyo | 接続できない（一覧にも出ない） | 読み取りのみ |
UbuntuにSambaをインストールして既定の設定を確かめる
サーバー側で入れるのはsambaパッケージだけです。testparmとsmbpasswdは依存関係で入るsamba-common-binに、smbstatusとpdbeditはsamba本体に含まれています。
sudo apt update
sudo apt install -y samba
…
Setting up samba (2:4.23.6+dfsg-1ubuntu2.2) ...インストール直後の/etc/samba/smb.confから、コメントと空行を除いた有効な行だけを取り出すと次のようになります。
grep -Ev '^[[:space:]]*([#;]|$)' /etc/samba/smb.conf
[global]
workgroup = WORKGROUP
disable netbios = yes
server string = %h server (Samba, Ubuntu)
log file = /var/log/samba/log.%m
max log size = 1000
logging = file
panic action = /usr/share/samba/panic-action %d
server role = standalone server
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes
[printers]
…
[print$]
…見てのとおり、disable netbios = yesはすでに入っている一方で、map to guest = bad userとusershare allow guests = yesも入っています。bad userは、存在しないユーザー名でのログインをゲストとして通す設定です。どこかの共有にguest ok = yesが付いた時点で、名前を打ち間違えた人がゲストとしてその共有に入れるようになります。プリンター用の[printers]と[print$]も部署の共有には要りません。追記で打ち消すより、元のファイルを残して丸ごと書き直す方が、あとから読む人に意図が伝わります。
sudo cp -a /etc/samba/smb.conf /etc/samba/smb.conf.orig部署共有の権限設計：Linuxグループとsetgidディレクトリ
部署はLinuxのグループで表します。サーバーの管理者を兼ねる人（例ではryoma）は既存のアカウントをsomuに加え、それ以外の人（例ではsatoとsuzuki）はSamba専用のアカウントとして作ります。-Mでホームディレクトリを作らず、-s /usr/sbin/nologinで対話ログインを塞ぐので、SSHなどファイル共有以外の入口が増えません。
sudo groupadd somu && sudo groupadd eigyo
sudo usermod -aG somu ryoma
sudo useradd -M -s /usr/sbin/nologin -G somu sato
sudo useradd -M -s /usr/sbin/nologin -G eigyo suzuki
id ryoma; id sato; id suzuki
uid=1001(ryoma) gid=1001(ryoma) groups=1001(ryoma),1002(somu)
uid=1002(sato) gid=1004(sato) groups=1004(sato),1002(somu)
uid=1003(suzuki) gid=1005(suzuki) groups=1005(suzuki),1003(eigyo)idの出力で見ておきたいのは、satoの基本グループ（gid）がsomuではなく、ユーザーと同名のsato（1004）になっている点です。useraddはUbuntuではユーザーごとに同名のグループを作って基本グループにするため、何も手を打たないとsatoが作ったファイルのグループはsatoになり、同じ総務部のryomaが書き換えられません。この状態で実際に出るエラーは「つまずきポイント」で再現しています。
usermod -aGで追加したグループは、そのユーザーが次にログインしたときから有効になります。グループに加えた本人（例ではryoma）としてSSHでつないだまま作業を続けると、今のシェルはまだsomuに入っていないので、この後のls -l /srv/samba/somuがls: cannot open directory '/srv/samba/somu': Permission deniedで失敗します。ここでいったんログアウトして入り直し、id -Gnにsomuが出ることを確かめてから先へ進みます。
共有するディレクトリは、グループをsomuにしてsetgidビット（モードの先頭の2）を立てます。setgidが付いたディレクトリの中で作られたファイルやサブディレクトリは、作った人の基本グループではなく、ディレクトリのグループを引き継ぎます。総務部の共有は部外者に一切見せないので2770、規程集は営業部にも読ませるので、その他の人に読み取りと移動を許す2775にしました。
sudo install -d -o root -g somu -m 2770 /srv/samba/somu
sudo install -d -o root -g somu -m 2775 /srv/samba/kitei
ls -ld /srv/samba/somu /srv/samba/kitei
drwxrwsr-x 2 root somu 4096 Sep 26 02:09 /srv/samba/kitei
drwxrws--- 2 root somu 4096 Sep 26 02:09 /srv/samba/somuグループの実行ビットの位置がsになっていれば（drwxrws---）setgidが効いています。setgidはSamba経由に限らずLinuxでのファイル作成すべてに効くので、管理者がSSHで入って置いたファイルもグループはsomuになります。ただし権限はそのときのumaskで決まり、検証でsudo touchしたファイルは-rw-r--r-- 1 root somuでした。サーバー上で直接ファイルを置いたら、最後にchmod 660までしておかないと、Samba経由の利用者が上書きできません。
smb.confを書く：1行ずつの理由と、使わない設定
/etc/samba/smb.confを次の内容で置き換えます。hosts allowの192.168.50.0/24は検証環境のLANなので、自分のLANのアドレス範囲に書き換えてください。
[global]
workgroup = WORKGROUP
server role = standalone server
# 接続元とプロトコル
hosts allow = 127.0.0.1 192.168.50.0/24
smb ports = 445
disable netbios = yes
server smb encrypt = desired
# 認証：ゲストと匿名を使わない
map to guest = Never
restrict anonymous = 2
access based share enum = yes
# 印刷は扱わない
load printers = no
disable spoolss = yes
# ログ（接続元ごとのファイル＋認証の成否）
log file = /var/log/samba/log.%m
max log size = 1000
logging = file
log level = 1 auth_audit:3
[somu]
comment = 総務部
path = /srv/samba/somu
valid users = @somu
read only = no
force group = +somu
create mask = 0660
directory mask = 2770
[kitei]
comment = 社内規程（営業部は閲覧のみ）
path = /srv/samba/kitei
valid users = @somu @eigyo
read only = yes
write list = @somu
force group = +somu
create mask = 0664
directory mask = 2775[global]の各行を選んだ理由は次の通りです。
server role = standalone server：ドメインに参加せず、このサーバーのpassdbだけで認証します。ADのメンバーにする構成は別物で、winbinddとKerberosの設定が加わります。hosts allow = 127.0.0.1 192.168.50.0/24：この範囲以外からの接続を、認証に進む前のプロトコル交渉の段階で切ります（つまずきポイントのSMB1の項で、範囲外から試した結果を載せています）。/24の書き方が効くことは、ファイアウォールの節でtestparmの接続判定を使っても確かめました。smb ports = 445：NetBIOS経由の139番を開けず、445番だけで待ち受けます。Samba 4.23ではserver smb transportsという新しいパラメーターの別名になっていて、testparmはserver smb transports = 445と表示します。新しい名前で書かなかったのは、Ubuntu 24.04.5のSamba 4.19.5ではserver smb transportsが未知のパラメーターとして無視されるのを確かめたからで、smb portsなら両方の版で同じ意味になります。disable netbios = yes：NetBIOSの名前解決とブラウズを止めます。マニュアルにもあるとおり、NetBIOSでしか相手を探さないクライアントからはこのサーバーが見えなくなるので、利用者には一覧から探してもらうのではなく、DNS名かIPアドレスで開いてもらいます。server smb encrypt = desired：SMB3で接続してきたクライアントとの通信を暗号化します。既定値（if_required）は暗号化を交渉できる状態にするだけで、実際には暗号化しません。requiredにすると暗号化できないクライアントを拒否するので、SMB2までしか話せない機器が残っている間はdesiredに留めます。map to guest = Never：パスワードが合わないログインを、ユーザー名が存在しない場合も含めて拒否します。Sambaの既定値ですが、Ubuntuの既定ファイルがbad userだったので明示しました。restrict anonymous = 2：ユーザー名なしの匿名接続で、共有一覧などの問い合わせ窓口であるIPC$に入ることを禁止します。access based share enum = yes：共有の一覧に、その人が入れる共有だけを表示します。営業部のアカウント（例ではsuzuki）には総務部の共有名すら見せません。load printers = noとdisable spoolss = yes：印刷用の共有とRPCを読み込みません。使わない機能の入口を閉じておく意図です。log fileからlog levelまで：接続元ごとに/var/log/samba/log.接続元へ記録し、1ファイルがmax log size（単位はKiB）を超えたら.oldに回します。auth_audit:3は認証の失敗（レベル2）と成功（レベル3）をそれぞれ記録する指定で、誰がいつどこから入ったかを後から追えます。
共有ごとの行は、部署の運用ルールをそのまま書き写したものです。
valid users = @somu：@付きの名前はLinuxのグループを指します。この行が空だと、passdbにいる全員が接続できます。read only = no：Sambaの共有は既定で読み取り専用なので、書き込ませる共有では明示が必要です。force group = +somu：somuのメンバーがこの共有で作ったファイルのグループをsomuにそろえます。先頭の+は「somuのメンバーにだけ適用する」という意味で、付けないと接続してきた全員がsomuとして扱われます。この差がどう効くかは、testparmの節で実演します。create mask = 0660とdirectory mask = 2770：新しいファイルとディレクトリに付く権限の上限です。既定のcreate maskは0744で、グループに書き込み権限が付きません。write list = @somu（kitei）：read only = yesの共有でも、ここに挙げた人には書き込みを許します。「規程集を更新するのは総務部だけ」という決まりを設定にした形です。
逆に、入れなかった設定とその理由です。どれも古い手順やQ&Aで見かける書き方ですが、部署の共有では事故の元になります。
| 使わない設定 | 起きること | 代わりに |
|---|---|---|
map to guest = bad user | 存在しないユーザー名での接続がゲストとして通る。つまずきポイントの節で見るとおり、エラーの表示も変わる | Never（Sambaの既定値） |
guest ok = yes、usershare allow guests = yes | パスワードなしで共有に入れる | 共有ごとにvalid usersでグループを指定 |
server min protocol = NT1 | SMB1を受け付ける。サーバー全体に効く | 書かずに既定のSMB2_02のまま（明示すると将来の既定値の引き上げを打ち消す） |
force user = root、create mask = 0777 | 全員がrootや全開の権限で書き込み、誰が作ったか分からなくなる | グループ・setgid・create mask = 0660 |
force group = somu（+なし） | valid usersが効いていないと、部外者もsomuとして書き込める | force group = +somu |
| ルーターで445番を転送 | インターネットからパスワードを総当たりされる | VPNでLANに入ってから接続 |
書き終えたらtestparm -sで読み込ませます。既定値と同じ行は表示されないので、map to guest = Neverやread only = yesが出てこないのは正常です。smb portsがserver smb transportsとして表示されている点も確認できます。
testparm -s
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)
Server role: ROLE_STANDALONE
# Global parameters
[global]
disable netbios = Yes
disable spoolss = Yes
load printers = No
log file = /var/log/samba/log.%m
logging = file
max log size = 1000
restrict anonymous = 2
server role = standalone server
server smb transports = 445
idmap config * : backend = tdb
access based share enum = Yes
hosts allow = 127.0.0.1 192.168.50.0/24
server smb encrypt = desired
[somu]
comment = 総務部
create mask = 0660
directory mask = 02770
force group = +somu
path = /srv/samba/somu
read only = No
valid users = @somu
…Sambaユーザーを登録してsmbdに反映する
Samba側のパスワードはsmbpasswd -aで登録します。入力中のパスワードは画面に表示されません。Linuxのログインパスワードとは別物なので、利用者にも別のパスワードとして伝えます。
sudo smbpasswd -a ryoma
New SMB password:
Retype new SMB password:
Added user ryoma.
sudo smbpasswd -a sato
New SMB password:
Retype new SMB password:
Added user sato.
sudo smbpasswd -a suzuki
New SMB password:
Retype new SMB password:
Added user suzuki.
sudo pdbedit -L
sato:1002:
ryoma:1001:
suzuki:1003:検証の記録では端末がないため、同じコマンドの標準入力にパスワードを2度流し込んでいます。smbpasswdは端末でないときは標準入力から読むので、画面の表示は同じです。アカウントをまとめて作るスクリプトにも使えますが、パスワードをファイルや履歴に残さない工夫は別に要ります。なお、pdbedit -Lが並べる順番は登録した順とは限らず、アカウントを作ったり消したりした履歴によって入れ替わります。後で出てくるログのSIDの末尾（RID）も同じ理由で変わります。この記事の出力は、試しに作って消したアカウントがある状態で取ったものなので、手元の順番や番号が違っていても問題ありません。
設定ファイルを置き換えたら、実機ではsmbdを再起動して読み込ませます。この検証環境ではsystemdを動かしていないため、次のブロックは実行していません。代わりにsmbd --foreground --no-process-groupで直接起動し、smbd.serviceのExecStartと同じ引数であることをユニットファイルで確認しました。
sudo systemctl restart smbd
systemctl status smbd --no-pager以後の設定変更は、再起動しなくても次のコマンドで読み直させられます（変更があれば3分ごとの自動チェックでも読み込まれます）。smbd.serviceのExecReloadもsmbdへHUPを送る内容なので、systemctl reload smbdでも同じ効果です。ただし、smbdのマニュアルにあるとおり、読み直しはすでに張られている共有への接続には効きません。権限を絞る変更をしたら、後で出てくるsmbstatusで残っている接続を確かめ、利用者につなぎ直してもらうか、smbdを再起動します。
sudo smbcontrol smbd reload-config
sudo ss -tlnp | grep smbd
LISTEN 0 50 0.0.0.0:445 0.0.0.0:* users:(("smbd",pid=4005,fd=28))
LISTEN 0 50 [::]:445 [::]:* users:(("smbd",pid=4005,fd=27))待ち受けは445番だけで、139番はありません。IPv6の[::]:445でも待ち受けている点は、ファイアウォールの節で扱います。
nmbdは、Ubuntuのnmbd.serviceにExecCondition=/usr/share/samba/is-configured nmbという起動条件があり、このスクリプトはdisable netbiosがYesなら終了コード1を返します。systemdはExecConditionが1から254で終わったユニットを失敗扱いにせず起動を見送るので、この設定のままならnmbdは動きません（systemd上の表示はこの環境では確認していません）。スクリプトの判定そのものは確かめました。
sudo /usr/share/samba/is-configured nmb; echo "nmb: exit=$?"; sudo /usr/share/samba/is-configured smb; echo "smb: exit=$?"
nmb: exit=1
smb: exit=0nmbdを手で起動すると話が変わります。検証でnmbd --foreground --no-process-groupを直接実行したところ、disable netbios = yesのままでもUDPの137番と138番を開きました（sudo ss -tulnp | grep -E "mbd"にnmbdの行が6つ出た）。NetBIOSを止めたつもりなら、nmbdを手で起動しないこと、起動条件を外すようなユニットの上書きをしないことが前提です。
動作確認：クライアントからsmbclientで読み書きする
接続する側のマシン（例ではnagoyadevlab02）にはsmbclientを入れます。パスワードをコマンドラインの-U ユーザー名%パスワードで渡すとシェルの履歴やpsの表示に残るので、アカウントごとに認証ファイルを作って-Aで読ませます。
sudo apt update
sudo apt install -y smbclient認証ファイルの書式は、smbclientのマニュアルにある次の3行です。エディタでアカウントごとに1つずつ作ります（例では~/.smb-ryoma、~/.smb-sato、~/.smb-suzuki）。本来は各自のPCから接続しますが、検証では管理者がクライアント側の1台で3人分の認証ファイルを切り替えて試しました。
username = ryoma
password = smbpasswdで設定したパスワード
domain = WORKGROUPchmod 600 ~/.smb-ryoma
chmod 600 ~/.smb-sato
chmod 600 ~/.smb-suzuki
smbclient -L //nagoyadevlab01 -A ~/.smb-ryoma
Sharename Type Comment
--------- ---- -------
somu Disk 総務部
kitei Disk 社内規程（営業部は閲覧のみ）
IPC$ IPC IPC Service (Samba 4.23.6-Ubuntu-4.23.6+dfsg-1ubuntu2.2)
SMB1 disabled -- no workgroup available最後のSMB1 disabled -- no workgroup availableはエラーではありません。ワークグループの一覧はSMB1のブラウズ機能で取るもので、SMB1を使わない構成では表示されない、という意味です。
ここからが権限設計の確認です。総務部の1人目（ryoma）でファイルを1つ置いてフォルダを作り、次に2人目（sato）でファイルを置きます。
echo "10月の備品発注リスト" > from-ryoma.txt
smbclient //nagoyadevlab01/somu -A ~/.smb-ryoma -c 'put from-ryoma.txt; mkdir 2026-10'
putting file from-ryoma.txt as \from-ryoma.txt (29.3 kB/s) (average 29.3 kB/s)
echo "定例会議メモ" > from-sato.txt
smbclient //nagoyadevlab01/somu -A ~/.smb-sato -c 'put from-sato.txt; ls'
putting file from-sato.txt as \from-sato.txt (18.6 kB/s) (average 18.6 kB/s)
. D 0 Sat Sep 26 02:17:33 2026
.. D 0 Sat Sep 26 02:17:33 2026
from-ryoma.txt A 30 Sat Sep 26 02:17:32 2026
2026-10 D 0 Sat Sep 26 02:17:32 2026
from-sato.txt A 19 Sat Sep 26 02:17:33 2026サーバー側で所有者と権限を見ると、狙いどおりになっていました。
ls -l /srv/samba/somu
total 12
drwxrws---+2 ryoma somu 4096 Sep 26 02:17 2026-10
-rw-rw----+1 ryoma somu 30 Sep 26 02:17 from-ryoma.txt
-rw-rw----+1 sato somu 19 Sep 26 02:17 from-sato.txt所有者は書いた本人（ryomaとsato）のまま、グループはどちらもsomu、権限はcreate maskで上限を切ったrw-rw----です。satoの基本グループはsatoなのにsomuになっているのは、force group = +somuとディレクトリのsetgidが効いているからです。ryomaが作ったフォルダ2026-10もdrwxrws---で、setgidが下の階層に引き継がれています。
権限の後ろの+はACLではありません。26.04に入っているlsはuutils coreutils（検証時は0.8.0）で、拡張属性が付いたファイルに+を表示します。SambaはDOSの属性をuser.DOSATTRIBという拡張属性に保存するので、Sambaが作ったファイルにだけ+が付きます。getfaclで見てもACLのエントリーはなく、GNU版のgnuls -lでは同じファイルに+が付きませんでした。
同じ部署で互いのファイルを編集できるかは、2人目（sato）で1人目（ryoma）のファイルを取り出し、1行足して同じ名前で戻して確かめます。
smbclient //nagoyadevlab01/somu -A ~/.smb-sato -c 'get from-ryoma.txt edit.txt'
getting file \from-ryoma.txt of size 30 as edit.txt (29.3 KiloBytes/sec) (average 29.3 KiloBytes/sec)
echo "（satoが数量を修正）" >> edit.txt
smbclient //nagoyadevlab01/somu -A ~/.smb-sato -c 'put edit.txt from-ryoma.txt'
putting file edit.txt as \from-ryoma.txt (57.6 kB/s) (average 57.6 kB/s)ls -l /srv/samba/somu/from-ryoma.txt && cat /srv/samba/somu/from-ryoma.txt
-rw-rw----+ 1 ryoma somu 59 Sep 26 02:17 /srv/samba/somu/from-ryoma.txt
10月の備品発注リスト
（satoが数量を修正）所有者はryomaのまま、中身はsatoの追記が入った状態です。グループsomuに書き込み権限があるので、所有者でなくても上書きできています。次に規程集へ総務部のアカウント（ryoma）で文書を置き、営業部のアカウント（suzuki）で読み書きを試します。
echo "旅費規程 2026年10月改定" > ryohi-kitei.txt
smbclient //nagoyadevlab01/kitei -A ~/.smb-ryoma -c 'put ryohi-kitei.txt'
putting file ryohi-kitei.txt as \ryohi-kitei.txt (31.2 kB/s) (average 31.2 kB/s)
smbclient -L //nagoyadevlab01 -A ~/.smb-suzuki
Sharename Type Comment
--------- ---- -------
kitei Disk 社内規程（営業部は閲覧のみ）
IPC$ IPC IPC Service (Samba 4.23.6-Ubuntu-4.23.6+dfsg-1ubuntu2.2)
SMB1 disabled -- no workgroup available
smbclient //nagoyadevlab01/kitei -A ~/.smb-suzuki -c 'get ryohi-kitei.txt; put from-sato.txt suzuki-test.txt'
getting file \ryohi-kitei.txt of size 32 as ryohi-kitei.txt (31.2 KiloBytes/sec) (average 31.2 KiloBytes/sec)
NT_STATUS_ACCESS_DENIED opening remote file \suzuki-test.txt
smbclient //nagoyadevlab01/somu -A ~/.smb-suzuki -c 'ls'
tree connect failed: NT_STATUS_ACCESS_DENIEDsuzukiの共有一覧にsomuは出ず、kiteiは読めても書き込みはNT_STATUS_ACCESS_DENIEDで断られ、somuは共有に入る段階（tree connect）で拒否されました。表で決めた権限のとおりです。サーバー側のls -l /srv/samba/kiteiでは、規程のファイルが-rw-rw-r--+1 ryoma somuで、その他の人（営業部）に読み取りだけが付いていることも確認しました。
匿名接続が断られることも見ておきます。
smbclient -L //nagoyadevlab01 -N
smb2_signing_decrypt_pdu: No decryption key for SMB2 signing
Anonymous login successful
tree connect failed: NT_STATUS_ACCESS_DENIEDユーザー名なしのセッション自体は張れますが、restrict anonymous = 2によってIPC$への接続が拒否され、共有一覧は取れません。1行目はserver smb encrypt = desiredを入れる前には出ていなかった行で、匿名のセッションには復号用の鍵がない、というクライアント側の表示です。結論は3行目で判断します。
最後に、接続中のセッションをサーバー側から見ます。satoとして2台目からsomuにつないだまま（検証では標準入力をsleep 40につないで接続を保持）、サーバー側でsmbstatusを実行しました。
smbclient //nagoyadevlab01/somu -A ~/.smb-satosudo smbstatus
No locked files
Samba version 4.23.6-Ubuntu-4.23.6+dfsg-1ubuntu2.2
PID Username Group Machine Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
5049 sato sato 192.168.50.20 (ipv4:192.168.50.20:39570) SMB3_11 AES-128-GCM partial(AES-128-GMAC)
Service pid Machine Connected at Encryption Signing
---------------------------------------------------------------------------------------------
somu 5049 192.168.50.20 Sat Sep 26 02:17:53 2026 UTC AES-128-GCM -接続元は192.168.50.20、プロトコルはSMB3_11で、server smb encrypt = desiredによりセッションも共有への接続もAES-128-GCMで暗号化されています。この行を入れる前に同じ操作をしたときは、Encryptionの欄が-でした。Groupの欄はsatoの基本グループのままですが、ファイルを作るときにsomuになることは先のls -lで確かめたとおりです。今つながっている端末とアカウントの確認に使え、登録済みのアカウントの棚卸し（退職者が残っていないか）はsudo pdbedit -Lで行います。
testparmで設定ミスを捕まえる：force groupとの組み合わせに注意
testparmは構文を検査するだけでなく、Sambaが知らないパラメーター名を見つけて警告します。ここでは、force groupを+なしのforce group = somuで書いていた段階のsmb.confで、[somu]のvalid usersをvaild usersと打ち間違えた状態を作りました。
testparm -s > /dev/null; echo "exit=$?"
Load smb config files from /etc/samba/smb.conf
Unknown parameter encountered: "vaild users"
Ignoring unknown parameter "vaild users"
Loaded services file OK.
Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback)
Server role: ROLE_STANDALONE
exit=0未知のパラメーターは無視されるだけで、Loaded services file OK.まで表示され、終了コードも0です。つまりvalid usersの制限が黙って消えます。この設定をsmbdに読み直させ、営業部のsuzukiで総務部の共有を開くと、次のようになりました。
smbclient //nagoyadevlab01/somu -A ~/.smb-suzuki -c 'ls'
. D 0 Sat Sep 26 02:14:18 2026
.. D 0 Sat Sep 26 02:14:18 2026
from-ryoma.txt A 59 Sat Sep 26 02:14:48 2026
2026-10 D 0 Sat Sep 26 02:13:42 2026
from-sato.txt A 19 Sat Sep 26 02:13:42 2026
smbclient //nagoyadevlab01/somu -A ~/.smb-suzuki -c 'put ryohi-kitei.txt from-suzuki.txt'
putting file ryohi-kitei.txt as \from-suzuki.txt (31.2 kB/s) (average 31.2 kB/s)ls -l /srv/samba/somu
total 16
drwxrws---+2 ryoma somu 4096 Sep 26 02:13 2026-10
-rw-rw----+1 ryoma somu 59 Sep 26 02:14 from-ryoma.txt
-rw-rw----+1 sato somu 19 Sep 26 02:13 from-sato.txt
-rw-rw----+1 suzuki somu 32 Sep 26 02:16 from-suzuki.txtディレクトリは2770で、suzukiはsomuに属していないのに、一覧も書き込みもできています。原因はforce group = somuです。このパラメーターは、接続してきた人の基本グループをsomuにしたうえでファイル権限を判定するので、1段目のvalid usersが消えると2段目のファイル権限も素通りになります。force group = +somuに直すと、typoを残したままでも2段目で止まりました。
smbclient //nagoyadevlab01/somu -A ~/.smb-suzuki -c 'ls'
NT_STATUS_ACCESS_DENIED listing \*
smbclient //nagoyadevlab01/somu -A ~/.smb-suzuki -c 'put ryohi-kitei.txt from-suzuki2.txt'
NT_STATUS_ACCESS_DENIED opening remote file \from-suzuki2.txtforce groupを+なしで使うと、valid usersの書き間違いや消し忘れが、そのまま他部署への書き込み許可になります。部署の共有ではforce group = +グループ名と書き、1段目と2段目がそれぞれ単独でも効く状態にしておきます。
試し終えたら、smb.confを前の節の内容（valid users = @somuとforce group = +somu）に戻して読み直させ、typoの状態でsuzukiが書き込んでしまったファイルを消しておきます。この後の節の出力は、この状態から続けたものです。
sudo smbcontrol smbd reload-config
sudo rm /srv/samba/somu/from-suzuki.txt設定を配るスクリプトやAnsibleでtestparmの終了コードだけを見ていると、この種のtypoを通してしまいます。標準エラーに出るUnknown parameterの行を拾って止めるのが確実です。次の/tmp/smb-typo.confは、typoを入れた検証用のコピーです。
testparm -s /tmp/smb-typo.conf 2>&1 >/dev/null | grep -i "unknown parameter" && echo "NG: 設定を直すまで反映しない"
Unknown parameter encountered: "vaild users"
Ignoring unknown parameter "vaild users"
NG: 設定を直すまで反映しない
testparm -s /etc/samba/smb.conf 2>&1 >/dev/null | grep -i "unknown parameter" || echo "OK: 未知のパラメーターなし"
OK: 未知のパラメーターなしつまずきポイント
NT_STATUS_LOGON_FAILURE：Linuxユーザーはいるのにログインできない
smbpasswd -aを忘れたときの表示を再現するため、suzukiをいったんpassdbから消して接続しました。Linuxのアカウントは残っているのでid suzukiは通りますが、Sambaから見ると存在しないユーザーです。
sudo smbpasswd -x suzuki
Deleted user suzuki.smbclient -L //nagoyadevlab01 -A ~/.smb-suzuki
session setup failed: NT_STATUS_LOGON_FAILUREクライアントにはパスワード違いと同じNT_STATUS_LOGON_FAILUREしか返りませんが、サーバーのauth_auditのログには理由が残ります。
sudo grep NT_STATUS_NO_SUCH_USER /var/log/samba/log.192.168.50.20
…
Auth: [SMB2,(null)] user [WORKGROUP]\[suzuki] at [Sat, 26 Sep 2026 02:24:28.347286 UTC] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation [NAGOYADEVLAB02] remote host [ipv4:192.168.50.20:45800] mapped to [WORKGROUP]\[suzuki]. local host [ipv4:192.168.50.10:445]NT_STATUS_NO_SUCH_USERならpassdbに登録がないので、sudo smbpasswd -a ユーザー名で直ります。パスワードの誤りなら、同じ形式の行にNT_STATUS_WRONG_PASSWORDが出ます（わざと違うパスワードを入れた認証ファイルで確かめました）。逆に、Ubuntuの既定ファイルにあったmap to guest = bad userを一時的に戻して、どこにも存在しないユーザー名で試すと、表示はtree connect failed: NT_STATUS_ACCESS_DENIEDに変わりました。ゲストとしてセッションが張られてから共有で断られるためで、権限の問題に見えてしまいます。ログのNO_SUCH_USERを先に見れば取り違えません。
NT_STATUS_ACCESS_DENIED：共有に入れない、同僚のファイルを上書きできない
同じACCESS_DENIEDでも、どこで出るかで原因が分かれます。tree connect failedなら1段目の共有の設定で断られていて、サーバーのログにどのユーザーがどの共有で断られたかが出ます。
smbclient //nagoyadevlab01/somu -A ~/.smb-suzuki -c 'ls'
tree connect failed: NT_STATUS_ACCESS_DENIEDsudo grep 'not permitted' /var/log/samba/log.nagoyadevlab02 | tail -n 1
create_connection_session_info: user 'suzuki' (from session setup) not permitted to access this share (somu)共有には入れるのにopening remote fileで断られるなら、2段目のファイル権限です。部署の共有でいちばん多いのは「同僚が作ったファイルだけ上書きできない」で、[somu]からforce group・create mask・directory maskの行を消し、ディレクトリのsetgidもchmod g-sで外した状態で再現しました。
echo "来客予定" > sato-memo.txt
smbclient //nagoyadevlab01/somu -A ~/.smb-sato -c 'put sato-memo.txt'
putting file sato-memo.txt as \sato-memo.txt (6.3 kB/s) (average 6.3 kB/s)ls -l /srv/samba/somu/sato-memo.txt
-rwxr--r--+ 1 sato sato 13 Sep 26 02:18 /srv/samba/somu/sato-memo.txtsmbclient //nagoyadevlab01/somu -A ~/.smb-ryoma -c 'put edit.txt sato-memo.txt'
NT_STATUS_ACCESS_DENIED opening remote file \sato-memo.txtグループはsatoの基本グループのsato、権限は既定のcreate mask（0744）どおりのrwxr--r--で、ryomaから見ると「その他」の読み取りしかありません。設定を元に戻して読み直させ、chmod g+sでsetgidを付け直したら、この状態で作られてしまった既存のファイルを次のコマンドで直します。ディレクトリとファイルを分けてchmodするのは、chmod -R g+rwXで一括にすると、所有者の実行ビットが付いたファイル（今回のsato-memo.txtのようなもの）にグループの実行権まで付くからです。
sudo chgrp -R somu /srv/samba/somu
sudo find /srv/samba/somu -type d -exec chmod 2770 {} +
sudo find /srv/samba/somu -type f -exec chmod 0660 {} +
ls -l /srv/samba/somu
total 16
drwxrws---+2 ryoma somu 4096 Sep 26 02:17 2026-10
-rw-rw----+1 ryoma somu 59 Sep 26 02:17 from-ryoma.txt
-rw-rw----+1 sato somu 19 Sep 26 02:17 from-sato.txt
-rw-rw----+1 sato somu 13 Sep 26 02:18 sato-memo.txtsmbclient //nagoyadevlab01/somu -A ~/.smb-ryoma -c 'put edit.txt sato-memo.txt'
putting file edit.txt as \sato-memo.txt (28.8 kB/s) (average 28.8 kB/s)NT_STATUS_BAD_NETWORK_NAME：共有名の誤りか、pathが存在しない
smbclient //nagoyadevlab01/soumu -A ~/.smb-ryoma -c 'ls'
tree connect failed: NT_STATUS_BAD_NETWORK_NAME
smbclient //nagoyadevlab01/kitei -A ~/.smb-ryoma -c 'ls'
tree connect failed: NT_STATUS_BAD_NETWORK_NAME1つ目は共有名の打ち間違い（somuをsoumu）、2つ目はサーバー側で/srv/samba/kiteiを別の名前に移した状態です。クライアントの表示は同じですが、サーバーのログで区別できます。
sudo tail -n 2 /var/log/samba/log.nagoyadevlab02
[2026/09/26 02:24:38.661284, 0] source3/smbd/smb2_service.c:755(make_connection_snum)
make_connection_snum: canonicalize_connect_path failed for service kitei, path /srv/samba/kiteipathがないときはcanonicalize_connect_path failedが残り、共有名を打ち間違えたときはこのログ（log level 1）に何も残りませんでした。前者ならls -ldでパスと権限を、後者ならtestparm -sで共有名の綴りを確かめます。ディレクトリを移動・改名する作業の前には、smb.confのpathも一緒に直す手順を作業票に入れておきます。
SMB1しか話せない機器がつながらない
古い複合機のスキャン保存など、SMB1（NT1）しか話せない機器は、接続の最初のプロトコル交渉で断られます。smbclientで使うプロトコルをNT1に絞って再現しました。
smbclient -L //nagoyadevlab01 -A ~/.smb-ryoma --option='client min protocol=NT1' -m NT1
smbXcli_negprot_smb1_done: No compatible protocol selected by server.
Protocol negotiation to server nagoyadevlab01 (for a protocol between NT1 and NT1) failed: NT_STATUS_INVALID_NETWORK_RESPONSE
smbclient -L //nagoyadevlab01 -A ~/.smb-ryoma -m NT1
lp_load_ex: Max protocol NT1 is less than min protocol SMB2_02.
Protocol negotiation to server nagoyadevlab01 (for a protocol between SMB2_02 and NT1) failed: NT_STATUS_INVALID_PARAMETER_MIX1つ目は、サーバーがSMB1の方言をどれも選ばなかったという表示です。2つ目は、Ubuntuのsmbclient自身も既定でSMB1を使わない（client min protocolの既定がSMB2_02）ため、サーバーに届く前にクライアントの中で止まった例です。1つ目の試行は、サーバー側のlog level 1のログに1行も残りませんでした。
紛らわしいのは、hosts allowの範囲外から接続したときにも同じNT_STATUS_INVALID_NETWORK_RESPONSEが出ることです。hosts allowを一時的に127.0.0.1 192.168.50.10/32に絞ってクライアント（nagoyadevlab02）から試すと、次のようになりました。
smbclient -L //nagoyadevlab01 -A ~/.smb-ryoma
Protocol negotiation to server nagoyadevlab01 (for a protocol between SMB2_02 and SMB3) failed: NT_STATUS_INVALID_NETWORK_RESPONSEsudo grep 'Denied connection' /var/log/samba/log.smbd
Denied connection from 192.168.50.20 (192.168.50.20)こちらは接続元ごとのファイルではなく、親プロセスのlog.smbdに拒否の行が残ります。クライアントにこのエラーが出たら、log.smbdにDenied connectionがあればhosts allowを、何も残っていなければSMB1しか話せない機器を疑います。
対処としてserver min protocol = NT1を書くのは勧めません。この設定はサーバー全体に効くので、古い機器1つのために全員の接続でSMB1を許すことになります。機器のファームウェアにSMB2以上を選ぶ設定がないかを先に確かめ、なければ機器側の別の保存経路（メール送信など）に切り替えるか、機器の更新を検討します。
Windows・macOS・Linuxから接続する（この環境では未検証）
この節のコマンドは、この環境では実行していません。検証環境にWindowsとmacOSがなく、コンテナ内でCIFSをマウントするとホストのカーネルモジュールを読み込むことになるためです。書式は各OSの公式ドキュメントとマニュアルで確認しました。
Windowsではエクスプローラーのアドレス欄に\\サーバー名\共有名（この記事の例では\\nagoyadevlab01\somu）と入れて開くのが基本です。disable netbios = yesにしているので、名前で開くにはDNSにサーバーのAレコードを登録するか、\\192.168.50.10\somuのようにIPアドレスで指定します。ドライブ文字に割り当てるならコマンドプロンプトで次のように実行し、*の位置でパスワードを入力させます。
net use S: \\nagoyadevlab01\somu * /user:nagoyadevlab01\ryoma /persistent:yesmacOSはFinderの「移動」メニューから「サーバへ接続」を開き、smb://サーバー名/共有名（例ではsmb://nagoyadevlab01/somu）を入力します。
LinuxクライアントからはカーネルのCIFSクライアントでマウントします。mount.cifsの資格情報ファイルはマニュアル上username=値の形で、smbclientの-A用のファイル（=の前後に空白）とは書き方が違うので、別のファイルとして用意します。
username=ryoma
password=smbpasswdで設定したパスワード
domain=WORKGROUPsudo apt install -y cifs-utils
sudo chmod 600 /root/.smb-somu
sudo mkdir -p /mnt/somu
sudo mount -t cifs //nagoyadevlab01/somu /mnt/somu -o credentials=/root/.smb-somu,uid=ryoma,gid=ryoma,vers=3.1.1,seal//nagoyadevlab01/somu /mnt/somu cifs credentials=/root/.smb-somu,uid=ryoma,gid=ryoma,vers=3.1.1,seal,nofail 0 0uidとgidは、サーバーが所有者の情報を返さないときに手元で表示する所有者で、指定しないとrootになります。versでSMBの版を固定し、sealで暗号化を要求します。fstabのnofailは、起動時にサーバーへつながらなくてもブートを止めないための指定です。このマウントでは、クライアント上の全ユーザーが資格情報ファイルのアカウント（ここではryoma）としてサーバーに書き込む点に注意してください。共用の端末なら、マウントポイントの権限で使える人を絞ります。
445番ポートをLANの外に出さない：ファイアウォールとIPv6
SMBの445番ポートは、ルーターでインターネットに転送してはいけないポートの代表です。社外から使う人にはVPNでLANに入ってもらい、Sambaの前にファイアウォールとhosts allowの2枚を置きます。ufwで許可するルールは次の通りで、ufw自体の既定ポリシー（受信は拒否）と有効化の手順はLinuxサーバーの基本ハードニングにまとめています。
sudo ufw allow from 192.168.50.0/24 to any port 445 proto tcp
sudo ufw status numbered検証用のコンテナにはファイアウォールのルールを入れていないため、上のブロックは実行していません。ルールの書式だけは--dry-runで確かめ、送信元が192.168.50.0/24のTCP 445番だけを許可するiptablesのルールに展開されることを見ています。
sudo ufw --dry-run allow from 192.168.50.0/24 to any port 445 proto tcp
…
### tuple ### allow tcp 445 0.0.0.0/0 any 192.168.50.0/24 in
-A ufw-user-input -p tcp --dport 445 -s 192.168.50.0/24 -j ACCEPT
…hosts allowが意図どおりかは、testparmに接続元の名前とIPアドレスを渡すと判定してくれます。判定結果は標準エラーに出るので、2>/dev/nullを付けると何も見えなくなる点に気をつけてください。
testparm -s /etc/samba/smb.conf nagoyadevlab02 192.168.50.20
…
Allow connection from nagoyadevlab02 (192.168.50.20) to somu
Allow connection from nagoyadevlab02 (192.168.50.20) to kitei
testparm -s /etc/samba/smb.conf pc-outside 10.20.30.40
…
Denied connection from pc-outside (10.20.30.40)
Deny connection from pc-outside (10.20.30.40) to somu
Denied connection from pc-outside (10.20.30.40)
Deny connection from pc-outside (10.20.30.40) to kitei見落としやすいのがIPv6です。smbdは[::]:445でも待ち受けていて、hosts allowにIPv4しか書いていないと、IPv6で来た接続は拒否されます。
testparm -s /etc/samba/smb.conf pc-v6 fd00:50::20 2>&1 | tail -n 4
Denied connection from pc-v6 (fd00:50::20)
Deny connection from pc-v6 (fd00:50::20) to somu
Denied connection from pc-v6 (fd00:50::20)
Deny connection from pc-v6 (fd00:50::20) to kitei社内LANでIPv6を配っていて、クライアントがサーバー名をIPv6アドレスで引く環境では、LANのIPv6プレフィックスもhosts allowに足します。例としてhosts allow = 127.0.0.1 192.168.50.0/24 fd00:50::/64と書いた設定では、testparmの判定でfd00:50::20が許可され、fd00:51::20は拒否されました。検証ネットワークはIPv4だけなので、IPv6での実際の接続は試していません。
バックアップとログ：passdbを忘れない
Sambaサーバーで退避しておくものは、共有のデータ（/srv/samba）、設定（/etc/samba/smb.conf）、Sambaのパスワードが入ったpassdb、それにLinuxのユーザーとグループの定義（/etc/passwdと/etc/group）です。passdbを失うと、サーバーを作り直したときに全員のパスワードを設定し直すことになり、UIDとGIDがずれると共有内のファイルの所有者も合わなくなります。
passdbは動作中のsmbdが開いているTDBファイルなので、そのままコピーせず、samba導入時に一緒に入るtdb-toolsのtdbbackupで複製を取り、その複製をバックアップに含めます。
sudo tdbbackup -s .bak /var/lib/samba/private/passdb.tdb && sudo ls -l /var/lib/samba/private/
total 840
-rw------- 1 root root 421888 Sep 26 02:14 passdb.tdb
-rw------- 1 root root 8192 Sep 26 02:22 passdb.tdb.bak
-rw------- 1 root root 430080 Sep 26 02:09 secrets.tdb
sudo pdbedit -b tdbsam:/var/lib/samba/private/passdb.tdb.bak -L
sato:1002:
ryoma:1001:
suzuki:1003:複製から3人分のアカウントが読めることまで確かめています。同じ目的でpdbedit -eによる書き出しも試しましたが、この版ではtdbsam形式への書き出し先にユーザーが入らず、smbpasswd形式ではbuild_sam_pass: Failing attempt to store user with non-uid based user RID.と出て、3人中2人がfailedになりました。どのアカウントが失敗するかはRIDの割り当てで決まるため、アカウントを作ったり消したりした履歴によって変わります。どちらも終了コードは0だったので、書き出しの成否を終了コードだけで判断しないでください。
取った複製はデータと一緒に別のマシンへ送ります。resticなら、/srv/samba、/etc/samba、/var/lib/samba/private/passdb.tdb.bakをバックアップ対象に並べ、tdbbackupをバックアップの直前に実行します。2台構成の組み方と戻し方の確認はresticでLinuxサーバーをバックアップするガイドの構成がそのまま使えます。ext4の共有にはスナップショットがないので、誤って上書き・削除したファイルを戻す手段はこのバックアップだけです。
ログは監査の最低限の記録になります。auth_audit:3で残る1行には、ユーザー名、時刻（UTC）、認証方式、結果、クライアントの名前とIPアドレスが入ります。
sudo grep -F '[sato]' /var/log/samba/log.192.168.50.20 | tail -n 1
Auth: [SMB2,(null)] user [WORKGROUP]\[sato] at [Sat, 26 Sep 2026 02:18:41.463599 UTC] with [NTLMv2] status [NT_STATUS_OK] workstation [NAGOYADEVLAB02] remote host [ipv4:192.168.50.20:39202] became [NAGOYADEVLAB01]\[sato] [S-1-5-21-2887013718-2221125920-1343838912-1002]. local host [ipv4:192.168.50.10:445]ログファイルは接続元ごとに分かれます。検証では、クライアントの名前が分かる前の認証がIPアドレスのファイル（log.192.168.50.20）に、名前が分かった後の共有への接続がクライアント名のファイル（log.nagoyadevlab02）に書かれたので、1人の操作を追うときは両方を見ます。記録されるのは認証と共有への接続までで、どのファイルを消したかは残りません。ファイル操作まで記録するにはVFSモジュールのfull_auditを足しますが、ログの量が増えるので、この記事の構成には入れていません。
/var/log/sambaはroot:admのdrwxr-x---です。admグループに入っていないユーザーのシェルでsudo grep … /var/log/samba/log.*と書くと、*の展開がsudoの前にそのユーザーの権限で行われるので、grep: /var/log/samba/log.*: No such file or directoryになります。admに入っているユーザーなら展開できますが、誰が実行しても同じ結果にするなら、ファイル名を具体的に書くか、sudo sh -c '…'で囲みます。
Samba on Ubuntu・TrueNAS SCALE・市販NAS・クラウドの選び方
部署のファイル共有を用意する方法は、Sambaを自分で立てるほかに、TrueNAS SCALEのようなNAS用OS、メーカー製のNAS、Microsoft 365のSharePointやGoogle Workspaceの共有ドライブがあります。次の表は、情シスが稟議と運用で詰まりやすい観点で並べたものです。
| 観点 | Samba on Ubuntu（この記事） | TrueNAS SCALE | 市販NAS | SharePoint／Googleドライブ |
|---|---|---|---|---|
| 置き場所 | 既存のUbuntuサーバーやVMに同居できる | 専用機にインストール（ZFS） | 専用の筐体 | サービス側（LAN内のサーバー不要） |
| ユーザー管理 | smbpasswdでローカル管理。ADのメンバーにするならwinbinddの設定が加わる | 管理画面からADに参加できる | 管理画面で作成。AD参加の可否は機種の仕様で確認 | Microsoft 365やGoogle Workspaceのアカウント |
| 誤削除・暗号化被害からの戻し方 | ext4には版がないので、別マシンへのバックアップが頼り | ZFSのスナップショット（設定はTrueNAS SCALEの構築ガイド） | 機種のスナップショット機能とバックアップ | 版の履歴とごみ箱（保持期間はプランと設定次第、執筆時点） |
| 監査に残るもの | auth_auditで認証の成否。ファイル操作はfull_auditを別途 | 版による（公式ドキュメントで確認） | 機種のログ機能による | 管理コンソールの監査ログ（範囲はプラン次第） |
| 社外からの利用 | VPN経由のみ（445番は公開しない） | 同左 | メーカーの中継サービスかVPN | ブラウザーや同期アプリから直接 |
| 運用の手間 | aptの更新と設定ファイル管理、障害対応は自分 | 画面操作が中心だがZFSの理解が要る | ファームウェア更新と保守契約の管理 | サーバー管理はないが、共有リンクと権限の棚卸しが要る |
| 費用の出方 | 既存サーバーに同居すれば追加のライセンス費用なし | 機材とディスク | 本体・ディスク・保守 | ユーザー単位の月額（既存契約の範囲内か確認） |
判断の順番としては、全社でMicrosoft 365かGoogle Workspaceを契約していて、共有するのがOffice文書中心なら、まずクラウド側の共有を使います。Sambaを立てる理由があるのは、複合機のスキャン保存や業務機器がSMBで書き込む、CADや動画のような大きなファイルをLANの速度で扱う、社外のサービスに置けないデータがある、のどれかに当てはまるときです。そのうえで、容量が大きく誤削除をその場で戻したいならTrueNAS SCALE、Linuxを触れる担当者がいない職場なら保守契約付きの市販NAS（選び方はNASの選び方）、既存のUbuntuサーバーやProxmoxのVMに小さく同居させたいならこの記事の構成、という分け方を勧めます。
よくある質問
UbuntuでSambaにつながらないのはなぜですか？
まずサーバーでsudo ss -tlnp | grep smbdに445番が出ているか、ufwとhosts allowが接続元を許しているかを見ます。そのうえでクライアントのエラーで分けます。LOGON_FAILUREはsmbpasswd -aの登録漏れかパスワード違い、ACCESS_DENIEDはvalid usersかファイル権限、BAD_NETWORK_NAMEは共有名かpathの誤りです。
SambaとSMBの違いは何ですか？
SMBはWindowsがファイルやプリンターを共有するための通信規約で、SambaはそれをLinuxやUnixで実装したオープンソースのソフトウェアです。Windows同士ならOSに組み込まれたSMBで共有できますが、LinuxをWindows向けのファイルサーバーにするにはSambaのsmbdが必要になります。
UbuntuでSambaの共有をマウントするにはどうすればいいですか？
cifs-utilsを入れ、mount -t cifs //サーバー/共有 /mnt/共有 -o credentials=資格情報ファイルの形でマウントし、常時使うなら/etc/fstabにnofail付きで書きます。この記事の検証環境ではCIFSのマウントを実行していないので、本文の未検証の節の書式を参考に、まず手動のmountで確かめてからfstabに移してください。
まとめ
- 始める前に、部署ごとのLinuxグループ名と、共有ごとに誰が書けて誰が読めるかを、本文の表の形で決めておきます。
- 設定を変えるたびに
testparm -s 2>&1 >/dev/null | grep -i "unknown parameter"が何も出さないことを確かめてから、smbcontrol smbd reload-configで反映します。 - 利用者に開放する前に、同じ部署の2人で互いのファイルを上書きできること、他部署のアカウントでは一覧にも出ないことをsmbclientで確かめ、passdbの複製を含めたバックアップを一度戻してみます。