Ubuntu上のSambaで、ゲスト接続はできるのにSamba ユーザー認証 できない状態になることがあります。
共有フォルダ自体は見えるのに、ユーザー名とパスワードを入れると拒否される、という症状です。
この組み合わせは、サービス全体の停止というより、認証経路かアクセス制御のどちらかに偏った不整合を疑うのが安全です。
原因が1つに確定できないことも多いため、本記事では事実（設定・コマンド結果）と推測を分けて、切り分け順に進めます。
ゲスト可・認証不可は、まずサーバー側のSambaユーザー登録と共有設定、次にWindows側の保存済み資格情報を疑います。
パッケージの再インストールやディスクのフォーマットは、原因が特定できるまで行わないでください。
想定する症状と環境
ここでは、次のような状況を想定します。
環境名やパスは例であり、実機では読み替えてください。
| 項目 | 例 |
|---|---|
| サーバー | Ubuntu（Sambaスタンドアロン） |
| クライアント | Windows 10 / 11 |
| 症状 | ゲストでは共有に入れる |
| 症状（認証時） | ユーザー名・パスワードで接続失敗 |
| 共有先の例 | ext4上のディレクトリ、またはNTFS（fuseblk）マウント |
ゲストで入れる事実は、「SMBの到達性」「共有名の公開」「ゲスト用の読み取り権限」までは通っている可能性が高い、という材料になります。
一方で認証失敗は、Sambaユーザー未登録、パスワード不一致、valid usersの不一致、保存済み資格情報の誤り、認証後のファイルシステム権限不足など、複数の候補が残ります。
ログや設定を見る前に原因を1つに決めつけないことが、遠回りを減らすコツです。
Sambaのユーザー認証と共有設定の基本
UbuntuのSambaでは、LinuxユーザーとSambaユーザーは別管理です。
既存のLinuxアカウントがあっても、そのままではSMB認証に使えません。
Samba cannot authenticate existing Linux users using the its native protocols. … To have a local Linux user available as a Samba user, they need to be created in the Samba credentials database.
引用：Share access controls – Ubuntu Server documentation
つまり、Linux側にユーザーを作ったあと、別途 smbpasswd -a などでSamba側にも登録する必要があります。
Samba用パスワードはLinuxのログインパスワードと揃える必要はありません。
共有設定では、次の観点が「ゲスト可・認証不可」と特に関係しやすいです。
security = user（ユーザー単位の認証）guest ok/map to guest（ゲスト接続の扱い）valid users（認証後に入れるユーザー制限）- 共有ディレクトリの所有者・権限（認証後の実アクセス）
ゲストは通るのに特定ユーザーだけ入れない場合、valid users にそのユーザーが含まれていない、という単純な不一致もよくあります。
逆にゲストだけ許可する共有では guest only = yes が効いており、認証ユーザーを意図せず拒いていることもあります。
パラメータの意味は、公式の smb.conf マニュアルで確認できます。
Ubuntu側で確認すること
まずはサーバー側で、認証に必要な前提が揃っているかを事実として集めます。
推測で設定を書き換えず、確認コマンドの結果を控えてから変更してください。
サービスと設定の健全性
次でSambaが動いていること、設定に文法エラーがないことを確認します。
sudo systemctl status smbd nmbd
testparm -s
sudo smbcontrol smbd reload-configtestparm -s は実際に解釈された設定を表示します。
意図した共有名・path・guest関連・valid usersが、自分が書いたつもりと一致しているかを見ます。
Sambaユーザーの有無とパスワード
ゲストは通るのに認証だけ失敗するとき、いちばん多い候補の1つがsmbpasswd未登録です。
Linuxユーザーが存在しても、Sambaデータベースに無いと認証は通りません。
# Linuxユーザーの確認（例: shareuser）
id shareuser
# Sambaユーザー追加（初回）
sudo smbpasswd -a shareuser
# パスワード変更（既に登録済みの場合）
sudo smbpasswd shareuser
# 登録一覧の確認（環境により表示方法は異なる）
sudo pdbedit -Lsmbpasswd -a は、対象がLinuxユーザーとして先に存在しないと失敗します。
これはUbuntu公式の説明とも一致します。
パスワードを変えた直後でも、Windows側が古い資格情報を送り続けていると、サーバーは正しく拒否します。
サーバーを直したつもりでも症状が残る場合は、後述の資格情報マネージャー確認が必要です。
共有設定の例（認証ユーザー向け）
ゲスト共有と認証共有を混ぜると切り分けが難しくなります。
認証用の共有は、意図をはっきり書いた設定例に寄せるのが分かりやすいです。
[myshare]
path = /srv/samba/myshare
browseable = yes
read only = no
guest ok = no
valid users = shareuser
create mask = 0660
directory mask = 0770この例ではゲストを明示的に閉じ、valid users で入れる人を限定しています。
ゲストも同時に許したい共有では guest ok = yes になりますが、「認証ユーザーが本当に通っているのか」が見えにくくなる点に注意してください。
スタンドアロンサーバーの基本構成は、Samba Wikiにもまとめがあります。
ディレクトリ権限（認証後アクセス）
認証そのものは成功しても、共有pathのUnix権限が足りないと、クライアントからは接続失敗やアクセス拒否に見えます。
ログでは認証成功後に権限エラーが出ることがあります。
ls -ld /srv/samba/myshare
namei -l /srv/samba/myshare
sudo journalctl -u smbd -n 100 --no-pager所有者・グループ・パーミッションを、Sambaで使うLinuxユーザー（またはグループ）に合わせて調整します。
ここで重要なのは、権限変更は必要最小限に留め、共有外のディレクトリまで広く書き換えないことです。
Windows側で確認すること
サーバー設定が正しそうなのに失敗が続く場合は、クライアント側の保存済み資格情報を疑います。
Windowsは一度保存したユーザー名・パスワードを、次回以降も自動送信することがあります。
資格情報マネージャーの確認
資格情報マネージャーでは、Web資格情報ではなく「Windows資格情報」側を見ます。
対象サーバーのホスト名やIPアドレスごとに別エントリになることがあります。
- タスクバー検索で「資格情報マネージャー」を開く
- 「Windows資格情報」を選択する
- 対象のサーバー名またはIP向けのエントリを確認する
- 古いエントリがあれば削除し、エクスプローラーや
net useで再接続する
コマンドでも一覧と削除ができます。
パスワードの中身は表示されないため、「エントリがある」ことと「内容が正しい」ことは別問題です。
cmdkey /list
cmdkey /delete:192.168.1.10
cmdkey /delete:FILESVR
ホスト名で接続したときとIPで接続したときで、別の資格情報が使われることがあります。
症状が片方だけで出る場合は、どちらの文字列で接続しているかを揃えて再確認してください。
明示的な接続テスト
エクスプローラーだけでなく、コマンドでユーザーを明示すると切り分けが進みます。
net use * /delete /y
net use \\192.168.1.10\myshare /user:shareuserここで成功し、エクスプローラーだけ失敗するなら、保存済み資格情報や別セッションの競合を疑う材料になります。
逆にコマンドでも失敗するなら、サーバー側（Sambaユーザー・valid users・ログ）に戻る方が効率的です。
NTFS（fuseblk）環境で注意すべき点
共有pathがNTFSをFUSE経由でマウントした領域（よく fuseblk と表示）の場合、認証後の見え方がext4と違います。
認証は通っても、マウント時の所有者・権限マスクの影響で読めない・書けないことがあります。
まず、実際のマウント状態を確認します。
findmnt /mnt/ntfs-share
mount | grep -E 'fuseblk|ntfs'
ls -ld /mnt/ntfs-share
pgrep -a ntfs-3gmount の表示上はFUSEの情報が中心になり、ntfs-3gに渡したオプションが見えにくいことがあります。
その場合は pgrep -a ntfs-3g や fstab の記述を併せて見る必要があります。
よく使う調整は、マウント時に uid / gid / umask（または fmask・dmask）を指定し、Sambaが使うLinuxユーザーから読める・書ける状態にすることです。
例は次のようなイメージです（UUIDやパスは環境に合わせてください）。
UUID=xxxx-xxxx /mnt/ntfs-share ntfs-3g defaults,uid=1000,gid=1000,umask=007 0 0このとき、chmod や chown をNTFS上で繰り返しても期待どおりに残らない、あるいは意味が薄いことがあります。
原因候補としては「Sambaの認証失敗」ではなく「認証後のファイルシステム見え方」の可能性が高いです。
NTFS-3gのオプション詳細はマニュアルを参照してください。
ディスクの再フォーマットや、共有データの一括削除は、この段階では推奨しません。
まずマウントオプションとSambaユーザーの実効UIDが一致しているかを確認してください。
切り分けの順番（安全側の進め方）
原因未特定のまま広範囲の変更をすると、復旧コストだけが増えます。
次の順で、狭い範囲から事実を集めるのがおすすめです。
- 症状の整理（ゲスト可／認証不可、ホスト名接続かIP接続か）
- Ubuntu側：
testparm、pdbedit/smbpasswd、共有のvalid usersと path権限 - Windows側：資格情報マネージャーと
cmdkey、net useでの明示接続 - ファイルシステム：ext4かNTFS（fuseblk）か、マウントオプションと実効所有者
- ログ照合：
journalctl -u smbdで認証失敗か権限失敗かを区別
再インストール、Samba設定の全消し、ディスクのフォーマットは、上記で原因が特定できて代替手段が無いときに限る判断です。
多くの場合は、Sambaユーザー登録・共有設定・資格情報・マウントオプションのどこかで説明がつきます。
まとめ
UbuntuのSambaでゲストだけ繋がりユーザー認証が通らないときは、導入手順のやり直しより、認証経路の切り分けが近道です。
サーバーではSambaユーザー登録と共有設定、クライアントでは資格情報マネージャー、共有先がNTFSならマウントオプション、の順で事実を揃えてください。
原因がログや設定で説明できるまで、再インストールやフォーマットなどの高リスク操作は控えましょう。
公式の共有アクセス制御・smb.conf・smbpasswd・資格情報の説明を参照しながら、変更は1か所ずつ確認するのが安全です。
コメント