1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@honda-dev-jp

古いLIFEBOOKをUbuntu開発機にする【5. Sambaファイルサーバ構築編】

1
Last updated at Posted at 2026-09-11

目次

はじめに

メインPCのDELLでフリーズやWSL切断などの不調が発生し、修理・切り分け中もLaravel開発を止めないため、以前使っていた古いLIFEBOOKをUbuntu開発機として再利用しています。

これまでにLIFEBOOKへ Ubuntu 24.04.4 LTS Desktop をインストールし、OpenSSH Server、公開鍵認証、UFW、Git、GitHub CLI、VS Code Remote - SSH、Docker Engineなどの開発基盤を整えてきました。

その後、メインPCのDELLをメーカーの工場へ修理に出すことになりました。

修理に備えて必要なデータをバックアップする中で、LIFEBOOKを開発機として使うだけでなく、Windowsからも利用できる家庭内LAN用のファイルサーバとして活用できるようにしておきたいと考えました。

そこで今回の第5回では、LIFEBOOKへ Samba を導入し、WindowsからSMB経由で共有フォルダへアクセスできるファイルサーバを構築します。

最終的には次の構成を目指します。

Windows PC
  │
  │ 家庭内LAN
  │ SMB
  ▼
LIFEBOOK
Ubuntu 24.04.4 LTS Desktop
  ├─ OpenSSH Server
  ├─ Git / GitHub CLI
  ├─ Docker Engine
  └─ Samba
       └─ Windowsとのファイル共有

今回は単にSambaをインストールして共有フォルダを公開するだけではなく、ゲストアクセスを使用せず、UFWで家庭内LANからのアクセスに限定することを前提として、実機の状態を確認しながら構築していきます。

今回の導入環境

項目 内容
PC 富士通 LIFEBOOK AH52/C
型名 FMVA52CBJ
CPU Intel Pentium P6200 2.13GHz
CPUコア数 2コア / 2スレッド
メモリ 8GB
ストレージ 256GB SSD
ファイルシステム ext4
OS Ubuntu 24.04.4 LTS Desktop
Kernel Linux 7.0.0-31-generic
アーキテクチャ x86_64
Ubuntuユーザー honta
ネットワーク接続 Wi-Fi（wlp16s0）
LIFEBOOK側IPv4 192.168.11.9/24
家庭内LAN 192.168.11.0/24
UFW 有効
UFWの受信デフォルト deny
SSH 家庭内LAN 192.168.11.0/24 からTCP/22のみ許可
Docker Engine 導入済み
Samba Server 未導入から開始

192.168.11.9/24 と 192.168.11.0/24 は、今回の家庭内LANで実際に確認した値です。

別の環境ではIPアドレスやサブネットが異なります。SambaやUFWを設定するときは、この値をそのままコピーせず、自分の環境で確認してください。

Samba導入前のパッケージ確認では、samba-libs がすでにインストールされていました。

samba-libs:amd64  2:4.19.5+dfsg-4ubuntu9.7

ただし、この時点ではSambaファイルサーバ本体の samba パッケージは確認できていません。

そのため、この記事では Samba Server未導入の状態から構築を開始します。

今回作る構成

今回はSambaをUbuntuホストへ直接導入し、家庭内LAN上のWindows PCからLIFEBOOKの共有ディレクトリへアクセスできる構成にします。

Windows PC
  │
  │ 家庭内LAN
  │ SMB
  ▼
192.168.11.0/24
  │
  │ UFW
  │ 家庭内LANから必要な通信のみ許可
  ▼
LIFEBOOK
Ubuntu 24.04.4 LTS Desktop
  │
  ├─ OpenSSH Server
  │    └─ SSH: 192.168.11.0/24からのみ許可
  │
  ├─ Docker Engine
  │
  └─ Samba
       │
       ├─ ゲストアクセスは使用しない
       ├─ Sambaユーザーで認証
       └─ /srv/samba/share
            └─ Windowsとファイル共有

今回のSambaは、インターネットへ公開するファイルサーバではありません。

用途は、自宅の家庭内LANに接続しているWindows PCとLIFEBOOKの間でファイルを共有することに限定します。

そのため、次の方針で構築します。

  • SambaはUbuntuホストへ直接インストールする
  • 共有ディレクトリは /srv/samba/share 配下に作成する
  • ゲストアクセスは使用しない
  • Ubuntuに存在するユーザー honta をSamba側にも登録して認証する
  • Windowsから共有ディレクトリへの読み書きを可能にする
  • UFWでは家庭内LAN 192.168.11.0/24 から必要なSamba通信だけを許可する
  • 既存のSSH用UFWルールは維持する
  • ルーター側でSamba用ポートをインターネットへ転送しない
  • SMB1を有効化するための設定は追加しない

Sambaの設定ファイル、Linux側のファイル権限、Samba側の認証、UFWの通信制御はそれぞれ別の仕組みです。

そのため、単に共有フォルダがWindowsから見えることだけをゴールにせず、

Linuxファイル権限
  ↓
Samba認証・共有設定
  ↓
UFWによる通信元制限
  ↓
Windowsから接続
  ↓
読み書き確認

の順に確認しながら構築していきます。

1. Samba導入前の状態を確認する

いきなりSambaをインストールせず、まずLIFEBOOKの現在状態を確認しました。

1.1 OS・ホスト情報を確認する

hostnamectl

今回の主な結果です。

Static hostname: lifebook-ubuntu
Operating System: Ubuntu 24.04.4 LTS
Kernel: Linux 7.0.0-31-generic
Architecture: x86-64
Hardware Vendor: FUJITSU
Hardware Model: FMVA52CBJ

Ubuntu 24.04.4 LTSが動作しており、ホスト名は lifebook-ubuntu です。

1.2 CPUとメモリを確認する

CPU情報を確認します。

lscpu

今回の主な結果です。

アーキテクチャ: x86_64
CPU:            2
モデル名:       Intel(R) Pentium(R) CPU P6200 @ 2.13GHz
コアあたりのスレッド数: 1
ソケットあたりのコア数: 2
ソケット数: 1

メモリも確認しました。

free -h

               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       2.3Gi       4.1Gi       129Mi       1.6Gi       5.3Gi
Swap:          4.0Gi          0B       4.0Gi

今回のLIFEBOOKでは、約8GBのメモリと4GBのSwapが利用できます。

1.3 ストレージを確認する

共有ファイルを保存することになるため、ディスク構成も確認しました。

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

主な結果です。

NAME     SIZE TYPE FSTYPE MOUNTPOINTS
sda    238.5G disk
├─sda1     1M part
└─sda2 238.5G part ext4   /

今回の環境では、約256GBのSSDを使用しており、ルートファイルシステムは ext4 です。

Samba用に別ディスクや別パーティションを追加するのではなく、このUbuntu環境内へ共有ディレクトリを作成する方針とします。

1.4 ネットワーク状態を確認する

Sambaは家庭内LANから利用するため、LIFEBOOKのネットワーク状態を確認します。

ip -br addr

今回の主な結果です。

lo        UNKNOWN  127.0.0.1/8
enp24s0   DOWN
wlp16s0   UP       192.168.11.9/24
docker0   DOWN     172.17.0.1/16

LIFEBOOKはWi-Fiインターフェース wlp16s0 で家庭内LANへ接続しており、IPv4アドレスは、

192.168.11.9/24

でした。

したがって、今回アクセスを許可する家庭内LANは、

192.168.11.0/24

です。

192.168.11.9/24 と 192.168.11.0/24 は今回の環境で確認した値です。

別のネットワーク環境では異なるため、自分の環境で ip コマンドなどを使って確認してください。

1.5 UFWの現在状態を確認する

Samba用のFirewallルールを追加する前に、現在のUFW設定を確認しました。

sudo ufw status verbose

今回の結果です。

状態: アクティブ
ロギング: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    192.168.11.0/24

Samba導入前は、

受信通信
  ↓
原則拒否

家庭内LAN 192.168.11.0/24
  ↓
TCP/22
  ↓
SSHのみ許可

という状態です。

今回のSamba構築でも、この 「受信は原則拒否し、家庭内LANから必要な通信だけ許可する」 方針を維持します。

このあとSamba用のUFWルールを追加します。

Firewallの設定を誤ると、意図しないネットワークからアクセスできる状態になったり、逆に必要な通信まで遮断したりする可能性があります。

既存ルールを確認した上で、今回必要な通信だけを追加します。

1.6 Samba関連パッケージの状態を確認する

Samba Serverがすでにインストールされていないか確認しました。

dpkg -l | grep -E '^ii\s+(samba|samba-common|smbclient)\b'

今回表示されたのは、

ii  samba-libs:amd64  2:4.19.5+dfsg-4ubuntu9.7  amd64  Samba core libraries

のみでした。

この時点ではSambaのコアライブラリである samba-libs は存在していますが、今回の確認結果ではSamba Server本体の samba パッケージは確認できませんでした。

したがって、この記事では Samba Server未導入の状態から構築を開始します。

samba-libs が存在することと、Sambaファイルサーバが構築済みであることは同じではありません。

今回はパッケージ一覧を確認し、Samba Server本体が確認できない状態から作業を開始しています。

2. Samba公式・Ubuntu公式の構成を確認する

Sambaをインストールする前に、Ubuntu公式ドキュメントとSamba公式ドキュメントを確認し、今回採用する構成を整理しました。

2.1 Ubuntu公式のファイルサーバ構成を確認する

Ubuntu公式のSambaファイルサーバ手順では、最初に samba パッケージをインストールします。

公式記載：

The first step is to install the samba package.

インストールコマンドは次のとおりです。

sudo apt install samba

また、Sambaのメイン設定ファイルについて、Ubuntu公式では次のように説明されています。

The main Samba configuration file is located in /etc/samba/smb.conf.

したがって、今回もSamba本体をインストールしたあと、

/etc/samba/smb.conf

を設定ファイルとして使用します。

2.2 共有ディレクトリは /srv/samba/share を使用する

Ubuntu公式のファイルサーバ設定例では、共有ディレクトリとして、

/srv/samba/share

が使用されています。

Ubuntu公式では /srv を採用する理由について、FHS（Filesystem Hierarchy Standard）上、システムが提供するサービス固有のデータを配置する場所であることを説明しています。

今回もホームディレクトリ配下をそのまま共有するのではなく、

/srv/samba/share

をSamba専用の共有ディレクトリとして作成する方針にします。

Sambaでは、Linux側の権限が適切であれば /srv/samba/share 以外の場所も共有できます。

今回はUbuntu公式の構成に合わせ、Sambaで提供するデータを /srv 配下へ分離します。

2.3 Ubuntu公式のゲスト共有例はそのまま使用しない

Ubuntu公式の基本的なファイルサーバ例には、次の設定があります。

guest ok = yes

Samba公式では guest ok = yes について、パスワードなしでその共有へ接続できる設定であると説明されています。

公式記載：

no password is required to connect to the service.

Ubuntu公式の基本例も、ネットワーク上のクライアントからパスワード入力なしで利用できる共有を作る構成です。

一方、Ubuntu公式自身も、この構成ではローカルネットワーク上のクライアントへ広くアクセスを許可するため、より厳格な制御が必要な場合はShare Access Controlを使用するよう案内しています。

今回の目的は、自分が管理するWindows PCとLIFEBOOK間でファイルを共有することです。

そのため、

ゲストアクセス
  ↓
使用しない

Sambaユーザー認証
  ↓
使用する

という構成にします。

設定時には、

guest ok = no

として、認証なしの共有を許可しないことを明示します。

Samba 4.19公式ドキュメントでは、guest ok のデフォルト値は no です。

今回はデフォルト任せにするのではなく、共有設定を読んだときに意図が分かるよう guest ok = no を明示する方針にします。

2.4 LinuxユーザーとSambaユーザーは別に管理される

今回使用するUbuntuユーザーは、

honta

です。

ただし、Ubuntu公式では、Linuxに存在するローカルユーザーが自動的にSambaユーザーとして利用できるわけではないことが説明されています。

公式記載：

All local Linux users that the system may have are not automatically available as Samba users.

既存LinuxユーザーをSambaから認証できるようにするには、Sambaの認証情報データベースへ登録する必要があります。

Ubuntu公式で案内されているコマンドは、

sudo smbpasswd -a <Linuxユーザー名>

です。

また、Sambaへ登録するユーザーは、あらかじめLinuxユーザーとして存在している必要があります。

今回すでにUbuntuユーザー honta が存在しているため、Sambaインストール後に、

sudo smbpasswd -a honta

でSambaユーザーとして登録する方針にします。

LinuxのログインパスワードとSambaのパスワードは別の認証情報として管理されます。

Ubuntu公式でも、Sambaユーザーへ設定するパスワードはLinuxユーザーのパスワードと同じである必要はないと説明されています。

2.5 共有へアクセスできるユーザーも限定する

Samba公式の valid users パラメータは、その共有へログインを許可するユーザーを指定する設定です。

公式記載：

This is a list of users that should be allowed to login to this service.

valid users を設定しない場合、デフォルトでは特定のユーザー一覧による制限はありません。

今回の共有フォルダは自分だけが使用するため、

valid users = honta

として、共有へアクセスできるSambaユーザーも honta に限定する方針にします。

2.6 SMB1を有効化する設定は追加しない

Samba 4.19公式ドキュメントでは、サーバーが許可する最小SMBプロトコルのデフォルト値は、

server min protocol = SMB2_02

です。

最大値は、

server max protocol = SMB3

です。

さらに公式では、通常はSMBの自動ネゴシエーションによって適切なプロトコルが選択されるため、これらの設定を変更する必要はないと説明されています。

公式記載：

Normally this option should not be set

そのため今回は、

server min protocol
server max protocol

を独自に設定せず、Samba 4.19のデフォルト動作を使用します。

特に、古いSMB1専用クライアントへ接続する必要はないため、

server min protocol = NT1

など、SMB1を利用可能にする設定は追加しません。

この記事では、Samba 4.19公式ドキュメントで確認したデフォルト値を基準にしています。

別バージョンのSambaではデフォルト値が変更される可能性があるため、別の環境で構築する場合は、その環境のSamba公式ドキュメントと実際の設定値を確認してください。

2.7 今回採用する方針を整理する

公式ドキュメントを確認した結果、今回は次の構成でSambaを設定します。

Sambaパッケージ
  └─ Ubuntu公式APTからインストール

メイン設定
  └─ /etc/samba/smb.conf

共有ディレクトリ
  └─ /srv/samba/share

認証
  ├─ Linuxユーザー: honta
  ├─ Sambaユーザー: honta
  ├─ guest ok = no
  └─ valid users = honta

SMBプロトコル
  ├─ Samba 4.19のデフォルトを使用
  ├─ 最小: SMB2_02
  ├─ 最大: SMB3
  └─ SMB1有効化設定は追加しない

ネットワーク
  └─ 後続手順でUFWを家庭内LAN 192.168.11.0/24に限定

Ubuntu公式のゲスト共有例をそのままコピーするのではなく、公式のアクセス制御方法とSamba自身の設定仕様を確認した上で、今回の用途に必要な設定だけを採用します。

3. Sambaをインストールする

Samba公式・Ubuntu公式の構成を確認したので、LIFEBOOKへSambaをインストールします。

Ubuntu公式のSambaファイルサーバ手順では、samba パッケージをAPTでインストールします。

判断元URL：

公式記載：

The first step is to install the samba package.

ただし今回は、いきなりインストールせず、先にAPTのパッケージ情報、候補バージョン、依存関係を実機で確認してから導入しました。

3.1 APTのパッケージ情報を更新する

まず、APTのパッケージ情報を更新します。

sudo apt update

今回の結果では、Ubuntuの、

noble
noble-updates
noble-security
noble-backports

に加え、すでに登録済みのDocker、Microsoft、GitHub CLIの各リポジトリもエラーなく取得できました。

最後に、

アップグレードできるパッケージが 12 個あります。

と表示されました。

今回のSamba導入では既存パッケージをまとめてアップグレードすることが目的ではないため、この12件には手を付けず、Sambaの確認を続けます。

3.2 Sambaの候補バージョンと取得元を確認する

Sambaがまだ未導入であることと、APTがどのバージョンを候補としているか確認します。

apt-cache policy samba

今回の結果です。

samba:
  インストールされているバージョン: (なし)
  候補:               2:4.19.5+dfsg-4ubuntu9.7
  バージョンテーブル:
     2:4.19.5+dfsg-4ubuntu9.7 500
        500 http://jp.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
     2:4.19.5+dfsg-4ubuntu9 500
        500 http://jp.archive.ubuntu.com/ubuntu noble/main amd64 Packages

この結果から、今回のLIFEBOOKでは、

Samba Server
  └─ 未インストール

APT候補
  └─ 2:4.19.5+dfsg-4ubuntu9.7

取得元
  ├─ noble-updates/main
  └─ noble-security/main

であることを確認しました。

Ubuntu 24.04 LTS初期リリース側には、

2:4.19.5+dfsg-4ubuntu9

も存在しますが、今回APTが選択した候補は更新済みの 2:4.19.5+dfsg-4ubuntu9.7 です。

2:4.19.5+dfsg-4ubuntu9.7 は、今回構築した時点でLIFEBOOKのAPTから確認できた候補バージョンです。

別の時点では更新されている可能性があります。記事中のバージョンへ固定せず、自分の環境で apt-cache policy samba を確認してください。

3.3 インストール内容をシミュレーションする

実際にインストールする前に、APTがどのパッケージを変更する予定なのか確認しました。

apt install --simulate samba

--simulate を使用しているため、この段階では実際のパッケージ変更は行われません。

今回の結果は、

アップグレード: 0 個
新規インストール: 22 個
削除: 0 個
保留: 12 個

でした。

新規インストール予定には、Samba本体のほか、

python3-samba
samba-common
samba-common-bin
samba-ad-provision
samba-dsdb-modules
samba-vfs-modules
tdb-tools

などが含まれていました。

また、

libcephfs2
librados2
librdmacm1t64

なども依存関係として追加される予定でした。

一方、

bind9
bind9utils
ctdb
winbind
chrony

などは「提案パッケージ」として表示されましたが、今回の新規インストール22件には含まれていません。

既存パッケージの削除やアップグレードを伴わないことを確認できたため、そのままインストールへ進みます。

今回はUbuntu公式の通常の apt install samba を使用します。

依存・推奨パッケージを独自判断で削るための --no-install-recommends などは使用していません。

3.4 Sambaをインストールする

Ubuntu公式の手順に従い、Sambaをインストールします。

sudo apt install samba

今回、APTから次の内容が表示されました。

アップグレード: 0 個
新規インストール: 22 個
削除: 0 個
保留: 12 個

13.0 MB のアーカイブを取得する必要があります。
この操作後に追加で 78.5 MB のディスク容量が消費されます。

内容を確認して、

続行しますか? [Y/n] Y

としてインストールを実行しました。

実際に samba パッケージとして導入されたバージョンは、

samba (2:4.19.5+dfsg-4ubuntu9.7)

でした。

インストール中には、Sambaの設定ファイルも新規作成されました。

Creating config file /etc/samba/smb.conf with new version

また、systemd用のsymlinkも作成されました。

主なものは次のとおりです。

smb.service → smbd.service
nmb.service → nmbd.service

multi-user.target.wants/smbd.service → smbd.service
multi-user.target.wants/nmbd.service → nmbd.service

samba.service → samba-ad-dc.service
multi-user.target.wants/samba-ad-dc.service → samba-ad-dc.service

インストール自体はエラーなく完了しました。

3.5 Sambaのバージョンを確認する

インストール後、smbd のバージョンを確認します。

smbd --version

今回の結果です。

Version 4.19.5-Ubuntu

APTパッケージとして確認したバージョン表記は、

2:4.19.5+dfsg-4ubuntu9.7

でしたが、smbd --version では、

4.19.5-Ubuntu

と表示されました。

この記事では、それぞれ実際のコマンドで確認できた表記をそのまま記録しています。

3.6 Sambaサービスの状態を確認する

Ubuntu公式のファイルサーバ手順では、設定反映時に smbd.service と nmbd.service を再起動する構成になっています。

判断元URL：

今回はインストール直後の状態を変更せずに確認しました。

smbd

systemctl is-active smbd
systemctl is-enabled smbd

結果：

active
enabled

nmbd

systemctl is-active nmbd
systemctl is-enabled nmbd

結果：

active
enabled

samba-ad-dc

systemctl is-active samba-ad-dc
systemctl is-enabled samba-ad-dc

結果：

inactive
enabled

さらに、現在実際に起動しているSamba関連serviceを確認しました。

systemctl --no-pager --type=service \
  | grep -E 'smbd|nmbd|samba'

今回の結果です。

nmbd.service  loaded active running Samba NMB Daemon
smbd.service  loaded active running Samba SMB Daemon

この時点で実際に active / running と確認できたSamba関連serviceは、

smbd.service
nmbd.service

でした。

samba-ad-dc は enabled と表示されましたが、今回の実機確認時点では inactive です。

samba-ad-dc が enabled であることだけを根拠に、今回のLIFEBOOKがActive Directory Domain Controllerとして動作しているとは判断しません。

実機では systemctl is-active samba-ad-dc が inactive であり、後述の testparm -s ではサーバーロールが ROLE_STANDALONE と確認できました。

3.7 デフォルト設定ファイルの存在を確認する

Sambaインストール時に作成された /etc/samba/smb.conf を確認します。

ls -l /etc/samba/smb.conf

今回の結果です。

-rw-r--r-- 1 root root 8917  7月 25 00:59 /etc/samba/smb.conf

設定ファイルが存在しており、所有者は root、グループも root です。

3.8 testparm でデフォルト設定を検証する

Sambaの設定ファイルを変更する前に、現在の設定を testparm で確認しました。

sudo 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

Loaded services file OK. と表示され、/etc/samba/smb.conf は正常に読み込まれました。

また、今回のサーバーロールは、

ROLE_STANDALONE

でした。

この段階で確認できた共有セクションは、

[printers]
[print$]

です。

また、[global] の実効設定には、

map to guest = Bad User
usershare allow guests = Yes

も含まれていました。

今回作成するファイル共有ではゲストアクセスを使用しない方針なので、後続の設定作業で認証ユーザーだけがアクセスできる共有を追加します。

Weak crypto is allowed by GnuTLS (e.g. NTLM as a compatibility fallback) という表示も確認できました。

今回の testparm では同時に Loaded services file OK. と表示されており、設定ファイルの読み込み自体は成功しています。

この記事では、この表示だけから暗号方式の利用状況を断定せず、実際に確認できた出力として記録します。

3.9 Sambaインストール後のUFWを確認する

Sambaをインストールしたことで、既存のUFW設定が意図せず変更されていないか確認しました。

sudo ufw status verbose

今回の結果です。

状態: アクティブ
ロギング: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    192.168.11.0/24

Sambaインストール後も、Samba用の受信許可ルールは追加されていませんでした。

この時点では、

受信通信
  ↓
原則拒否

192.168.11.0/24
  ↓
TCP/22
  ↓
SSHのみ許可

というSamba導入前のUFW設定が維持されています。

つまり、Sambaサービス自体は起動していますが、この時点ではUFWでSamba用の受信通信を許可していません。

後続の手順で、家庭内LAN 192.168.11.0/24 から必要なSamba通信だけを許可します。

Sambaをインストールしたからといって、Firewallを無効化して接続確認することはしません。

今回の環境ではUFWの受信デフォルト deny を維持したまま、後続手順で家庭内LANから必要な通信だけを追加します。

3.10 インストール直後の状態を整理する

ここまでで、Sambaインストール直後の状態は次のようになりました。

Ubuntu 24.04.4 LTS
  │
  ├─ Samba package
  │    └─ 2:4.19.5+dfsg-4ubuntu9.7
  │
  ├─ smbd
  │    ├─ active
  │    └─ enabled
  │
  ├─ nmbd
  │    ├─ active
  │    └─ enabled
  │
  ├─ samba-ad-dc
  │    ├─ inactive
  │    └─ enabled
  │
  ├─ /etc/samba/smb.conf
  │    └─ testparm: Loaded services file OK.
  │
  ├─ Server role
  │    └─ ROLE_STANDALONE
  │
  └─ UFW
       ├─ active
       ├─ incoming: deny
       └─ 192.168.11.0/24 → TCP/22のみ許可

これでSamba本体の導入と、設定を始める前の初期状態まで確認できました。

次は、Windowsと共有するためのディレクトリを /srv/samba/share に作成します。

4. 共有ディレクトリを作成する

Samba本体のインストールが完了したので、Windowsと共有するためのディレクトリを作成します。

Ubuntu公式のSambaファイルサーバ手順では、共有ディレクトリの例として /srv/samba/share が使用されています。

判断元URL：

Ubuntu公式では、/srv はシステムが提供するサービス固有のデータを配置する場所としてFHSに沿った構成であること、またSambaの共有自体はファイルシステム上の別の場所にも配置できるものの、適切な権限設定が必要であることが説明されています。

今回はUbuntu公式の例に合わせて、

/srv/samba/share

を共有ディレクトリとして使用します。

ただし、Ubuntu公式の基本例はゲスト共有を前提として nobody:nogroup を所有者にしています。

今回の構成ではゲストアクセスを使用せず、認証ユーザー honta だけが利用するため、Linux側の所有者と権限も今回の用途に合わせて設定します。

4.1 作成前のユーザーとディレクトリ状態を確認する

まず、共有ディレクトリを作成する前に、Ubuntuユーザー honta のUID・GID・所属グループを確認しました。

id honta

今回の結果です。

uid=1000(honta) gid=1000(honta) groups=1000(honta),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),100(users),114(lpadmin),984(docker)

この結果から、honta のプライマリグループも、

honta

であることを確認しました。

続いて、/srv、/srv/samba、/srv/samba/share の存在と権限を確認します。

ls -ld /srv /srv/samba /srv/samba/share 2>/dev/null \
  || echo "/srv/samba/share はまだありません"

今回の結果です。

drwxr-xr-x 2 root root 4096  2月 10  2026 /srv
/srv/samba/share はまだありません

この時点では、

/srv
  └─ 存在する

/srv/samba
  └─ 存在しない

/srv/samba/share
  └─ 存在しない

という状態でした。

既存の共有ディレクトリへ上書きするのではなく、新規に作成する状態であることを確認できました。

4.2 /srv の保存先と空き容量を確認する

共有ファイルを保存する場所になるため、/srv がどのファイルシステム上にあり、どの程度空き容量があるか確認しました。

df -h /srv

今回の結果です。

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       234G   30G  193G  14% /

今回の環境では /srv はルートファイルシステム / と同じ /dev/sda2 上にあり、確認時点の空き容量は、

193G

でした。

Samba専用に別ディスクや別パーティションを追加するのではなく、今回はこの既存ファイルシステム上へ共有ディレクトリを作成します。

空き容量 193G は今回確認した時点のLIFEBOOK実機の値です。

当然ながら使用状況によって変化するため、別環境では df -h などを使って実際の空き容量を確認してください。

4.3 共有ディレクトリを作成する

共有ディレクトリを作成します。

sudo mkdir -p /srv/samba/share

-p を指定しているため、存在していなかった親ディレクトリ /srv/samba も同時に作成されます。

続いて、共有ディレクトリの所有者を今回使用するUbuntuユーザー honta に変更します。

sudo chown honta:honta /srv/samba/share

今回は自分専用の認証付き共有として利用するため、共有ディレクトリ自体の権限を 0700 に設定しました。

sudo chmod 0700 /srv/samba/share

0700 の場合、共有ディレクトリに対するLinux側の権限は次の構成になります。

owner: honta  → rwx
group: honta  → ---
others        → ---

Ubuntu公式のゲスト共有例では nobody:nogroup を使用していますが、今回はその構成をそのまま採用せず、認証ユーザー honta だけがLinux側でもアクセスできるようにしています。

chown や chmod はLinuxの所有者・アクセス権限を変更するコマンドです。

この記事では新規作成した /srv/samba/share だけを対象にしています。

既存データがあるディレクトリへ同じ設定を機械的に適用すると、他のユーザーやサービスからアクセスできなくなる可能性があります。対象パスと現在の権限を確認してから実行してください。

4.4 作成後の所有者と権限を確認する

ディレクトリ作成と権限変更後の状態を確認します。

ls -ld /srv /srv/samba/ /srv/samba/share

今回の結果です。

drwxr-xr-x 3 root  root  4096  9月 10 21:50 /srv
drwxr-xr-x 3 root  root  4096  9月 10 21:50 /srv/samba/
drwx------ 2 honta honta 4096  9月 10 21:50 /srv/samba/share

意図したとおり、

/srv
  └─ root:root / 0755

/srv/samba
  └─ root:root / 0755

/srv/samba/share
  └─ honta:honta / 0700

となっていることを確認できました。

共有対象の /srv/samba/share だけを honta 所有とし、その上位ディレクトリは root:root のままです。

4.5 honta で書き込みできることを確認する

Samba側の設定へ進む前に、まずLinuxのファイルシステム上で honta が共有ディレクトリへ正常に書き込めることを確認します。

テストファイルを作成しました。

touch /srv/samba/share/linux-write-test.txt

作成されたファイルを確認します。

ls -l /srv/samba/share/linux-write-test.txt

今回の結果です。

-rw-rw-r-- 1 honta honta 0  9月 10 21:52 /srv/samba/share/linux-write-test.txt

テストファイルが、

owner: honta
group: honta

として正常に作成されました。

これで、Sambaの設定とは切り離して、Linux側では honta が /srv/samba/share へ書き込めることを確認できました。

今回作成されたテストファイル自体は -rw-rw-r-- と表示されました。

ただし共有ディレクトリ /srv/samba/share は 0700 であり、今回この章で確認した目的は「honta が共有ディレクトリへファイルを作成できること」です。

ファイル作成時のデフォルト権限の詳細については、この結果だけから一般化せず、必要であれば umask やSamba側の create mask などを別途確認します。

4.6 テストファイルを削除して最終状態を確認する

書き込み確認用のファイルは不要なので削除します。

rm /srv/samba/share/linux-write-test.txt

削除後の共有ディレクトリを確認しました。

ls -la /srv/samba/share/

今回の結果です。

合計 8
drwx------ 2 honta honta 4096  9月 10 21:54 .
drwxr-xr-x 3 root  root  4096  9月 10 21:50 ..

テストファイルは削除され、共有ディレクトリ内にはファイルが残っていません。

ここまでで、

/srv/samba/share が存在しないことを確認
  ↓
/srv の保存先と空き容量を確認
  ↓
/srv/samba/share を新規作成
  ↓
所有者を honta:honta に設定
  ↓
ディレクトリ権限を 0700 に設定
  ↓
honta でテストファイル作成成功
  ↓
テストファイル削除
  ↓
共有ディレクトリが空の状態まで確認

できました。

次は、Ubuntuユーザー honta をSambaの認証情報データベースへ登録し、Windowsから認証して接続できるようにします。

5. Sambaユーザーを設定する

共有ディレクトリ /srv/samba/share のLinux側の準備ができたので、Windowsから認証して接続するためのSambaユーザーを設定します。

Ubuntu公式では、Linux上に存在するローカルユーザーが自動的にSambaユーザーとして利用できるわけではなく、Sambaの認証情報データベースへ別途登録する必要があると説明されています。

判断元URL：

公式記載：

All local Linux users that the system may have are not automatically available as Samba users.

今回使用するLinuxユーザーは、すでに実機で存在を確認している、

honta

です。

そのため、新しいLinuxユーザーを作成するのではなく、既存ユーザー honta をSamba側へ登録します。

5.1 Sambaユーザーの登録状態を確認する

まず、変更前のSambaユーザー一覧を確認しました。

sudo pdbedit -L

今回の結果では、何も表示されませんでした。

（出力なし）

この時点では、Sambaの認証情報データベースにユーザーが登録されていない状態から開始しています。

5.2 honta をSambaユーザーとして登録する

Ubuntu公式で案内されている smbpasswd -a を使用して、既存Linuxユーザー honta をSambaへ登録します。

sudo smbpasswd -a honta

実行すると、Samba用パスワードを2回入力するよう求められました。

New SMB password:
Retype new SMB password:

パスワードを設定すると、今回の実機では次のように表示されました。

Added user honta.

これで honta がSambaユーザーとして登録されました。

Samba用パスワードは認証情報なので、記事・スクリーンショット・作業ログへ実際の値を記載しないようにします。

Ubuntu公式では、Sambaの認証情報はLinux側とは別に管理され、Samba用パスワードはLinuxログインパスワードと同じである必要はないと説明されています。

今回はパスワードそのものを記録せず、登録が成功したことだけを記事へ残します。

5.3 Sambaユーザーの登録結果を確認する

登録後、pdbedit で honta がSambaユーザーとして存在することを確認しました。

sudo pdbedit -L -u honta

今回の結果です。

honta:1000:honta

ここで、

Sambaユーザー名: honta
UID:             1000

として登録されていることを確認できました。

第4章で確認したLinuxユーザーも、

uid=1000(honta)
gid=1000(honta)

だったため、今回のSambaユーザー honta は既存Linuxユーザー honta に対応しています。

5.4 Sambaユーザー設定後の状態を整理する

ここまでで、認証に使用するユーザーは次の状態になりました。

Linux
  └─ honta
       ├─ UID: 1000
       └─ /srv/samba/share の所有者

Samba
  └─ honta
       ├─ Samba認証情報へ登録済み
       └─ Windowsからの認証に使用

作業の流れは次のとおりです。

Sambaユーザー一覧を確認
  ↓
登録ユーザーなし
  ↓
sudo smbpasswd -a honta
  ↓
Samba用パスワードを設定
  ↓
Added user honta.
  ↓
sudo pdbedit -L -u honta
  ↓
honta:1000:honta を確認

これで、WindowsからSambaへ接続するときに使用する認証ユーザーの準備ができました。

次は /etc/samba/smb.conf を設定し、/srv/samba/share を認証ユーザー honta だけが利用できる共有として定義します。

6. smb.conf を設定する

Sambaユーザー honta の登録が完了したので、/srv/samba/share をWindowsから利用できる共有として /etc/samba/smb.conf に定義します。

Ubuntu公式では、Sambaのメイン設定ファイルとして /etc/samba/smb.conf を使用し、共有セクションをファイル末尾へ追加する方法が案内されています。

判断元URL：

今回は既存設定を直接変更するため、最初にバックアップを作成し、同名共有が存在しないことを確認してから設定を追加します。

6.1 smb.conf をバックアップする

設定変更前に、現在の /etc/samba/smb.conf をバックアップしました。

sudo cp -a /etc/samba/smb.conf \
  "/etc/samba/smb.conf.bak-$(date +%Y%m%d-%H%M%S)"

作成後、バックアップファイルを確認します。

ls -lt /etc/samba/smb.conf* | head

今回の結果です。

-rw-r--r-- 1 root root 8917  7月 25 00:59 /etc/samba/smb.conf
-rw-r--r-- 1 root root 8917  7月 25 00:59 /etc/samba/smb.conf.bak-20260910-220715

バックアップファイル、

/etc/samba/smb.conf.bak-20260910-220715

が作成されたことを確認できました。

今回は cp -a を使用したため、バックアップファイルには元ファイルの属性や更新日時が保持されています。

そのため、ファイル名にはバックアップ作成時刻が含まれていますが、ls -l で表示される更新日時は元の smb.conf と同じになっています。

/etc/samba/smb.conf はSambaの主要設定ファイルです。

設定を誤ると共有へ接続できなくなる可能性があるため、変更前の状態へ戻せるようバックアップを作成してから編集します。

6.2 [share] セクションが既に存在しないことを確認する

今回追加する共有名は、

share

です。

同名セクションを重複して追加しないよう、変更前に確認しました。

grep -nE '^[[:space:]]*\[share\][[:space:]]*$' \
  /etc/samba/smb.conf \
  || echo "[share] はまだありません"

今回の結果です。

[share] はまだありません

既存の [share] セクションは存在していないことを確認できました。

6.3 認証付き共有 [share] を追加する

/etc/samba/smb.conf の末尾へ、今回使用する共有設定を追加します。

sudo tee -a /etc/samba/smb.conf > /dev/null <<'EOF'

[share]
    path = /srv/samba/share
    browsable = yes
    read only = no
    guest ok = no
    valid users = honta
EOF

今回追加した設定は次のとおりです。

設定 今回の用途
[share] Windowsから利用する共有名
path = /srv/samba/share Linux側の共有ディレクトリ
browsable = yes 共有を参照可能にする
read only = no 書き込みを許可する
guest ok = no 未認証のゲストアクセスを許可しない
valid users = honta 共有へアクセスできるSambaユーザーを honta に限定する

今回は、

force user
server min protocol
server max protocol

などの追加設定は行いません。

第2章で確認したとおり、SMBプロトコルについてはSamba 4.19のデフォルト動作を使用し、SMB1を有効化するための設定も追加しません。

6.4 追加した設定を確認する

設定追加後、smb.conf の末尾を確認しました。

tail -n 12 /etc/samba/smb.conf

今回の結果です。

# admin users are members of.
# Please note that you also need to set appropriate Unix permissions
# to the drivers directory for these users to have write rights in it
;   write list = root, @lpadmin


[share]
    path = /srv/samba/share
    browsable = yes
    read only = no
    guest ok = no
    valid users = honta

意図した [share] セクションがそのまま追加されていることを確認できました。

6.5 testparm で設定を検証する

Sambaサービスへ反映する前に、testparm で設定ファイルを検証しました。

sudo 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

今回追加した [share] も、実効設定として次のように表示されました。

[share]
        path = /srv/samba/share
        read only = No
        valid users = honta

Loaded services file OK. と表示され、設定ファイルが正常に読み込まれていることを確認できました。

また、サーバーロールは引き続き、

ROLE_STANDALONE

です。

設定ファイルには、

browsable = yes
guest ok = no

も明示していますが、今回の testparm -s の短縮表示では出力されませんでした。

testparm -s では、デフォルト値と同じ設定などが短縮表示で省略される場合があります。

今回の記事では、実際の /etc/samba/smb.conf に browsable = yes と guest ok = no が存在することを tail で確認し、testparm -s では共有全体が正常に読み込まれることを確認しています。

6.6 Sambaサービスを再起動して設定を反映する

Ubuntu公式では、smb.conf の変更後に smbd.service と nmbd.service を再起動して設定を反映する方法が案内されています。

判断元URL：

今回は次のコマンドを実行しました。

sudo systemctl restart smbd.service nmbd.service

コマンド実行時にエラーは表示されませんでした。

6.7 再起動後のサービス状態を確認する

設定反映後、smbd の状態を確認しました。

systemctl is-active smbd

結果：

active

続いて nmbd を確認します。

systemctl is-active nmbd

結果：

active

さらに、現在起動しているSamba関連serviceを確認しました。

systemctl --no-pager --type=service \
  | grep -E 'smbd|nmbd|samba'

今回の結果です。

nmbd.service  loaded active running Samba NMB Daemon
smbd.service  loaded active running Samba SMB Daemon

設定反映後も、

smbd.service
nmbd.service

の両方が active / running であることを確認できました。

6.8 再起動後にもう一度 testparm を実行する

サービス再起動後も設定が正常に読み込まれることを確認するため、再度 testparm を実行しました。

sudo testparm -s

今回も、

Loaded services file OK.
Server role: ROLE_STANDALONE

となりました。

[share] も引き続き、

[share]
        path = /srv/samba/share
        read only = No
        valid users = honta

と表示されました。

これで、設定ファイルの編集後だけでなく、Sambaサービス再起動後も今回の共有設定が正常に読み込まれていることを確認できました。

6.9 現時点の共有構成を整理する

ここまでで、Samba側の設定は次の状態になりました。

/etc/samba/smb.conf
  │
  └─ [share]
       ├─ path = /srv/samba/share
       ├─ browsable = yes
       ├─ read only = no
       ├─ guest ok = no
       └─ valid users = honta

Linux側
  │
  └─ /srv/samba/share
       ├─ owner: honta
       ├─ group: honta
       └─ mode: 0700

Samba認証
  │
  └─ honta
       └─ 登録済み

Sambaサービス
  ├─ smbd: active
  └─ nmbd: active

testparm
  ├─ Loaded services file OK.
  └─ ROLE_STANDALONE

この時点で、

Linux側の共有ディレクトリ
  ↓
Sambaユーザー認証
  ↓
smb.confの共有定義
  ↓
testparmによる設定検証
  ↓
smbd / nmbd再起動
  ↓
再起動後も設定読み込み成功

まで完了しました。

ただし、UFWではまだSamba用の通信を許可していません。

次は、現在のSambaが使用するポートとUFWのアプリケーションプロファイルを実機で確認した上で、家庭内LAN 192.168.11.0/24 から必要なSamba通信だけを許可します。

7. UFWで家庭内LANからのSamba通信だけを許可する

Sambaの共有設定まで完了しましたが、この時点ではUFWでSamba用の受信通信をまだ許可していません。

今回のLIFEBOOKでは、Sambaをインターネットへ公開せず、家庭内LAN 192.168.11.0/24 からだけ利用する方針です。

そのため、いきなりFirewallルールを追加せず、

SambaのUFWプロファイル確認
  ↓
実際の待受ポート確認
  ↓
現在のUFWルール確認
  ↓
IPv6設定確認
  ↓
dry-run
  ↓
本適用
  ↓
最終確認

の順に進めます。

7.1 SambaのUFWアプリケーションプロファイルを確認する

まず、利用可能なUFWのアプリケーションプロファイルを確認しました。

sudo ufw app list

今回の結果です。

利用可能なアプリケーション:
  CUPS
  OpenSSH
  Samba

Sambaインストール後、Samba プロファイルが利用可能になっていました。

続いて、このプロファイルがどのポートとプロトコルを対象にするのか確認します。

sudo ufw app info Samba

今回の結果です。

プロファイル: Samba
タイトル: LanManager-like file and printer server for Unix

Ports:
  137,138/udp
  139,445/tcp

今回のUbuntu実機では、Sambaプロファイルが次の通信を対象としていることを確認できました。

UDP
  ├─ 137
  └─ 138

TCP
  ├─ 139
  └─ 445

Ubuntu公式のUFWドキュメントでは、アプリケーションプロファイルの詳細を ufw app info で確認でき、Sambaについて特定のサブネットからだけ許可する例も案内されています。

判断元URL：

ネット上の記事に書かれたポート番号をそのまま採用するのではなく、今回は実際にLIFEBOOKへインストールされたUFWの Samba プロファイルを確認してから使用しました。

7.2 Sambaが実際に待ち受けているポートを確認する

次に、Sambaプロセスが実際にどのアドレス・ポートで待ち受けているか確認しました。

sudo ss -lntup \
  | grep -E 'smbd|nmbd|:(137|138|139|445)\b'

今回の主な結果です。

udp   UNCONN ... 172.17.255.255:137 ... users:(("nmbd",...))
udp   UNCONN ...     172.17.0.1:137 ... users:(("nmbd",...))
udp   UNCONN ... 192.168.11.255:137 ... users:(("nmbd",...))
udp   UNCONN ...   192.168.11.9:137 ... users:(("nmbd",...))
udp   UNCONN ...        0.0.0.0:137 ... users:(("nmbd",...))

udp   UNCONN ... 172.17.255.255:138 ... users:(("nmbd",...))
udp   UNCONN ...     172.17.0.1:138 ... users:(("nmbd",...))
udp   UNCONN ... 192.168.11.255:138 ... users:(("nmbd",...))
udp   UNCONN ...   192.168.11.9:138 ... users:(("nmbd",...))
udp   UNCONN ...        0.0.0.0:138 ... users:(("nmbd",...))

tcp   LISTEN ... 0.0.0.0:139 ... users:(("smbd",...))
tcp   LISTEN ... 0.0.0.0:445 ... users:(("smbd",...))
tcp   LISTEN ...    [::]:139 ... users:(("smbd",...))
tcp   LISTEN ...    [::]:445 ... users:(("smbd",...))

今回の実機では、

nmbd
  ├─ 137/udp
  └─ 138/udp

smbd
  ├─ 139/tcp
  └─ 445/tcp

で待ち受けていることを確認できました。

また、nmbd は家庭内LANのWi-Fiインターフェースだけでなく、Docker bridgeの 172.17.0.1 側でも待ち受けていました。

smbd はIPv4の 0.0.0.0 とIPv6の [::] で待ち受けています。

Sambaプロセスが複数のインターフェースやアドレスで待ち受けていることと、Firewallがその通信を許可することは別です。

今回はSamba自身の待受状態だけを見て安全と判断せず、UFW側で家庭内LANからの通信だけを許可します。

7.3 変更前のUFWルールを確認する

Samba用ルールを追加する前に、現在のUFWルールを番号付きで確認しました。

sudo ufw status numbered

今回の結果です。

状態: アクティブ

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    192.168.11.0/24

この時点では、

192.168.11.0/24
  ↓
TCP/22
  ↓
SSHのみ許可

となっており、Samba用の受信許可ルールはまだ存在していません。

7.4 UFWのIPv6設定を確認する

smbd がIPv6の [::]:139 と [::]:445 でも待ち受けていたため、UFWがIPv6を管理対象としているか確認しました。

grep '^IPV6=' /etc/default/ufw

今回の結果です。

IPV6=yes

UFW側ではIPv6サポートが有効になっていることを確認できました。

ただし、今回追加するSambaルールでは送信元としてIPv4サブネット、

192.168.11.0/24

を明示します。

そのため、今回のルールはこのIPv4家庭内LANからのSamba通信だけを対象にします。

7.5 --dry-run で追加予定のルールを確認する

本適用前に、--dry-run を使って追加予定のFirewallルールを確認しました。

sudo ufw --dry-run allow from 192.168.11.0/24 to any app Samba

今回の出力には、Sambaプロファイルに対応するルールとして次の内容が表示されました。

allow udp 137,138 ... 192.168.11.0/24 Samba - in
allow tcp 139,445 ... 192.168.11.0/24 Samba - in

具体的には、

-A ufw-user-input -p udp \
  -m multiport --dports 137,138 \
  -s 192.168.11.0/24 \
  -j ACCEPT

-A ufw-user-input -p tcp \
  -m multiport --dports 139,445 \
  -s 192.168.11.0/24 \
  -j ACCEPT

に相当する内容が確認できました。

コマンド末尾には、

ルールをアップデートしました

と表示されましたが、--dry-run なので、この段階で実際のFirewallルールが変更されたとは判断しません。

Ubuntu 24.04のUFW man pageでも、--dry-run は実際の変更を行わず結果を表示するためのオプションとして説明されています。

判断元URL：

7.6 dry-run後に実際のルールが変更されていないことを確認する

--dry-run 実行後、実機でもUFWルールが変更されていないことを確認しました。

sudo ufw status numbered

結果：

状態: アクティブ

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    192.168.11.0/24

Samba用ルールはまだ追加されていません。

これで、

dry-run
  ↓
ルール内容を確認
  ↓
実際のUFW設定は未変更

であることを実機でも確認できました。

7.7 家庭内LANからだけSambaを許可する

内容を確認できたため、Samba用のUFWルールを本適用します。

sudo ufw allow from 192.168.11.0/24 to any app Samba

今回の結果です。

ルールを追加しました

今回のルールでは、

送信元
  └─ 192.168.11.0/24

アプリケーション
  └─ Samba

対象ポート
  ├─ 137,138/udp
  └─ 139,445/tcp

という構成になります。

Ubuntu公式のUFWドキュメントでも、Sambaを特定サブネットからだけ許可する例として、

ufw allow from 192.168.0.0/24 to any app Samba

という構文が案内されています。

今回はサブネット部分を、実機で確認した家庭内LAN、

192.168.11.0/24

へ置き換えています。

単純な、

sudo ufw allow Samba

では、今回意図している「家庭内LANからだけ許可する」という制限になりません。

この記事では送信元サブネットを明示して、

sudo ufw allow from 192.168.11.0/24 to any app Samba

としています。

別環境では家庭内LANのアドレス範囲が異なるため、自分のネットワーク構成を確認した上で設定してください。

7.8 追加後のUFWルールを確認する

本適用後、番号付きのルール一覧を確認しました。

sudo ufw status numbered

今回の結果です。

状態: アクティブ

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    192.168.11.0/24
[ 2] Samba                      ALLOW IN    192.168.11.0/24

Samba用ルールが、

192.168.11.0/24

からだけ許可されていることを確認できました。

さらに詳細を確認します。

sudo ufw status verbose

今回の結果です。

状態: アクティブ
ロギング: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
新しいプロファイル: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    192.168.11.0/24
137,138/udp (Samba)        ALLOW IN    192.168.11.0/24
139,445/tcp (Samba)        ALLOW IN    192.168.11.0/24

最終的なUFW構成は次のようになりました。

UFW
  │
  ├─ Default incoming
  │    └─ deny
  │
  ├─ SSH
  │    └─ 192.168.11.0/24 → TCP/22
  │
  └─ Samba
       └─ 192.168.11.0/24
            ├─ UDP/137
            ├─ UDP/138
            ├─ TCP/139
            └─ TCP/445

これで、既存の「受信は原則拒否」という方針を維持したまま、家庭内LANから必要なSamba通信だけを追加できました。

7.9 この時点のネットワーク構成を整理する

ここまでの状態を整理すると、次の構成です。

Windows PC
  │
  │ 家庭内LAN
  │ 192.168.11.0/24
  ▼
UFW
  │
  ├─ SSH
  │    └─ TCP/22
  │
  └─ Samba
       ├─ UDP/137
       ├─ UDP/138
       ├─ TCP/139
       └─ TCP/445
  ▼
LIFEBOOK
  │
  ├─ smbd
  │    └─ active
  │
  ├─ nmbd
  │    └─ active
  │
  └─ [share]
       ├─ path = /srv/samba/share
       ├─ guest ok = no
       └─ valid users = honta

この時点で、

Sambaサービス起動
  ↓
共有設定済み
  ↓
Sambaユーザー登録済み
  ↓
Linux側共有ディレクトリ権限設定済み
  ↓
UFWで家庭内LANからのみSamba通信を許可

まで完了しました。

次は、Sambaサーバー自身から共有一覧と認証を確認した上で、Windowsから実際に接続できるか検証します。

8. Sambaサーバー側で共有と認証を確認する

Sambaの共有設定とUFWの家庭内LAN限定ルールまで完了したので、Windowsから接続する前に、LIFEBOOK自身からSambaへ接続して共有と認証を確認します。

ここでサーバー側の動作を先に確認しておくことで、後からWindowsで接続できなかった場合に、

Sambaサーバー側の問題

と、

Windows側・ネットワーク側の問題

を切り分けやすくします。

Samba公式の smbclient は、SMB/CIFSサーバーへ接続し、共有一覧の取得やファイルの送受信などを行えるクライアントツールです。

判断元URL：

公式記載：

smbclient is a client that can 'talk' to an SMB/CIFS server.

また、-L オプションについては、サーバー上で利用可能なサービスを一覧表示するためのものと説明されています。

公式記載：

This option allows you to look at what services are available on a server.

今回は smbclient をLIFEBOOKへ追加し、ローカルホスト上のSambaへ honta で認証して検証します。

8.1 smbclient の導入状態を確認する

まず、smbclient コマンドがすでに存在するか確認しました。

command -v smbclient || echo "smbclient は見つかりません"

今回の結果では、smbclient のパスは表示されませんでした。

続いて、APT側の状態も確認します。

apt-cache policy smbclient

今回の結果です。

smbclient:
  インストールされているバージョン: (なし)
  候補:               2:4.19.5+dfsg-4ubuntu9.7
  バージョンテーブル:
     2:4.19.5+dfsg-4ubuntu9.7 500
        500 http://jp.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
     2:4.19.5+dfsg-4ubuntu9 500
        500 http://jp.archive.ubuntu.com/ubuntu noble/main amd64 Packages

この時点では、

smbclient
  ├─ 未インストール
  └─ APT候補: 2:4.19.5+dfsg-4ubuntu9.7

でした。

Samba Server本体はすでに導入済みですが、ローカル検証に使用する smbclient は別途インストールする必要がある状態でした。

8.2 インストール内容をシミュレーションする

実際にインストールする前に、変更予定のパッケージを確認しました。

apt install --simulate smbclient

今回の結果です。

提案パッケージ:
  cifs-utils heimdal-clients

以下のパッケージが新たにインストールされます:
  smbclient

アップグレード: 0 個
新規インストール: 1 個
削除: 0 個
保留: 12 個

実際に新規インストールされる予定なのは、

smbclient

だけでした。

候補バージョンは、

2:4.19.5+dfsg-4ubuntu9.7

です。

cifs-utils と heimdal-clients は提案パッケージとして表示されましたが、今回の新規インストール対象には含まれていません。

既存パッケージのアップグレードや削除を伴わないことを確認してから、インストールへ進みました。

8.3 smbclient をインストールする

apt を使用して smbclient をインストールします。

sudo apt install smbclient

今回の主な結果です。

以下のパッケージが新たにインストールされます:
  smbclient

アップグレード: 0 個
新規インストール: 1 個
削除: 0 個
保留: 12 個

470 kB のアーカイブを取得する必要があります。
この操作後に追加で 2,129 kB のディスク容量が消費されます。

実際に導入されたパッケージは、

smbclient (2:4.19.5+dfsg-4ubuntu9.7)

でした。

インストールはエラーなく完了しました。

8.4 smbclient のバージョンを確認する

インストール後、バージョンを確認しました。

smbclient --version

今回の結果です。

Version 4.19.5-Ubuntu

Samba Server側で確認した smbd --version と同じ、

4.19.5-Ubuntu

でした。

8.5 honta で認証して共有一覧を確認する

LIFEBOOK自身のSambaへ、Sambaユーザー honta を指定して接続します。

smbclient -L 127.0.0.1 -U honta

-U honta ではユーザー名だけをコマンドラインで指定し、パスワードはプロンプトで入力しました。

Samba公式では、-U にパスワードを含めなかった場合、パスワード入力を求める動作が説明されています。

判断元URL：

公式記載：

If %password is not specified, the user will be prompted.

今回の記事でもSamba用パスワードをコマンドラインや記事本文へ記載しません。

今回の結果です。

Password for [WORKGROUP\honta]:

        Sharename       Type      Comment
        ---------       ----      -------
        print$          Disk      Printer Drivers
        share           Disk
        IPC$            IPC       IPC Service (lifebook-ubuntu server (Samba, Ubuntu))
SMB1 disabled -- no workgroup available

今回作成した、

share

が Disk 共有として一覧に表示されました。

ここで表示された共有のうち、

share

が今回 /etc/samba/smb.conf へ追加した共有です。

print$ と IPC$ は今回独自に作成した [share] とは別の共有として表示されています。

また、末尾には、

SMB1 disabled -- no workgroup available

と表示されました。

今回の実機では、この表示が出た状態でも [share] は一覧に表示され、続く直接接続とファイル操作も成功しています。

そのため、この記事ではこの表示を理由にSMB1を有効化する設定変更は行いません。

今回の目的はWindowsとのファイル共有であり、SMB1を有効化する必要はありません。

第2章で確認した方針どおり、SMBプロトコルを独自に古いバージョンへ固定する設定は追加していません。

8.6 [share] へ直接接続して一覧を確認する

共有一覧に [share] が表示されたので、今度は共有へ直接接続します。

smbclient //127.0.0.1/share -U honta -c 'ls'

今回もSamba用パスワードはプロンプトで入力しました。

今回の結果です。

Password for [WORKGROUP\honta]:
  .                                   D        0  Thu Sep 10 21:54:18 2026
  ..                                  D        0  Thu Sep 10 21:54:18 2026

                245020956 blocks of size 1024. 201461320 blocks available

この時点では /srv/samba/share 内を空にしていたため、

.
..

だけが表示されました。

これで、

Sambaユーザー honta で認証
  ↓
[share] へ直接接続
  ↓
共有ディレクトリ一覧取得

まで成功したことを確認できました。

8.7 SMB経由で書き込みできることを確認する

一覧取得だけではなく、実際にSamba経由で書き込みできることも確認します。

まず、LIFEBOOKの /tmp にテスト用ファイルを作成しました。

printf 'Samba write test\n' > /tmp/samba-write-test.txt

続いて、smbclient の put を使って [share] へアップロードし、そのまま ls で一覧を確認します。

smbclient //127.0.0.1/share -U honta \
  -c 'put /tmp/samba-write-test.txt samba-write-test.txt; ls'

今回の結果です。

Password for [WORKGROUP\honta]:
putting file /tmp/samba-write-test.txt as \samba-write-test.txt (2.8 kb/s) (average 2.8 kb/s)
  .                                   D        0  Thu Sep 10 23:08:08 2026
  ..                                  D        0  Thu Sep 10 23:08:08 2026
  samba-write-test.txt                A       17  Thu Sep 10 23:08:08 2026

                245020956 blocks of size 1024. 201461312 blocks available

共有内に、

samba-write-test.txt

が表示され、サイズは、

17 bytes

でした。

これで、Linuxから直接共有ディレクトリへ書き込むだけでなく、

smbclient
  ↓
SMB
  ↓
Samba
  ↓
/srv/samba/share

という経路でもファイルを書き込めることを確認できました。

Samba公式の smbclient ドキュメントでも、サーバーへのファイル送信は提供される操作の一つとして説明されています。

判断元URL：

8.8 SMB経由でテストファイルを削除する

書き込み確認ができたので、今度は同じファイルをSamba経由で削除します。

smbclient //127.0.0.1/share -U honta \
  -c 'del samba-write-test.txt'

Samba用パスワードを入力すると、今回の実行ではエラーは表示されずプロンプトへ戻りました。

8.9 Linux側でも削除されたことを確認する

SMB経由で削除したあと、Linux側から共有ディレクトリを確認しました。

ls -la /srv/samba/share

今回の結果です。

合計 8
drwx------ 2 honta honta 4096  9月 10 23:08 .
drwxr-xr-x 3 root  root  4096  9月 10 21:50 ..

先ほどアップロードした、

samba-write-test.txt

は存在せず、共有ディレクトリが再び空になっていることを確認できました。

最後に、/tmp 側へ作成したテストファイルも削除しました。

rm /tmp/samba-write-test.txt

8.10 サーバー側検証結果を整理する

Windowsから接続する前に、LIFEBOOK自身で次の一連の動作を確認できました。

smbclient 未導入を確認
  ↓
APT候補バージョンを確認
  ↓
インストール内容をsimulate
  ↓
smbclient 4.19.5-Ubuntuを導入
  ↓
127.0.0.1へ honta で認証
  ↓
共有一覧に share が表示
  ↓
[share] へ直接接続
  ↓
共有ディレクトリ一覧取得成功
  ↓
SMB経由で17byteのテストファイルを作成
  ↓
共有一覧にファイルが表示
  ↓
SMB経由でテストファイルを削除
  ↓
Linux側でも削除済みを確認

これで少なくともLIFEBOOK自身では、

Sambaユーザー認証
共有定義
Linuxファイル権限
SMB経由の読み取り
SMB経由の書き込み
SMB経由の削除

まで動作することを確認できました。

次は家庭内LAN上のWindows PCからLIFEBOOKへ接続し、実際のクライアント側でも [share] を利用できるか確認します。

9. Windowsから共有フォルダへ接続する

LIFEBOOK自身からSambaの共有・認証・書き込みまで確認できたので、次は家庭内LAN上のWindows PCから実際に接続します。

今回は、名前解決の問題とSMB接続の問題を分けて確認するため、最初はホスト名ではなくLIFEBOOKのIPv4アドレス、

192.168.11.9

を使用しました。

Windowsから接続する共有のUNCパスは、

\\192.168.11.9\share

です。

MicrosoftのSMB関連ドキュメントでも、共有への接続には \\server\share 形式のUNCパスが使用されます。

判断元URL：

9.1 WindowsからTCP/445へ到達できるか確認する

最初にWindows側のPowerShellから、LIFEBOOKのSMB用TCP/445へ到達できるか確認しました。

Test-NetConnection -ComputerName 192.168.11.9 -Port 445

今回の結果です。

ComputerName     : 192.168.11.9
RemoteAddress    : 192.168.11.9
RemotePort       : 445
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.11.2
TcpTestSucceeded : True

Windows側のIPv4アドレスは、

192.168.11.2

で、LIFEBOOKの、

192.168.11.9:445

へTCP接続できることを確認しました。

これで少なくとも、

Windows
  ↓
家庭内LAN
  ↓
UFW
  ↓
TCP/445
  ↓
LIFEBOOK

まで到達できる状態です。

9.2 最初のエクスプローラー接続では 0x80004005 になった

TCP/445への到達を確認したあと、Windowsのエクスプローラーから、

\\192.168.11.9\share

へアクセスしました。

しかし最初の接続では、

\\192.168.11.9\share にアクセスできません

エラー コード: 0x80004005
エラーを特定できません

と表示され、共有フォルダを開けませんでした。

一方、直前の Test-NetConnection では、

TcpTestSucceeded : True

だったため、この時点でTCP/445自体には到達できていることが分かっています。

そのため、UFWを無効化したりSMB1を有効化したりせず、Windows側のSMB接続・認証状態を続けて確認しました。

0x80004005 が表示された原因は、この確認結果だけでは一意に特定できませんでした。

この記事では「TCP/445には到達できていた」「明示的にSambaユーザーを指定した接続では成功した」という実際に確認できた事実までを記載し、原因を推測で断定しません。

9.3 Windowsの既存ネットワーク接続を確認する

まず、PowerShellで現在のSMB接続を確認しようとしました。

Get-SmbConnection |
    Format-Table ServerName, ShareName, UserName, Credential, Dialect -AutoSize

今回の環境では、

Get-SmbConnection: アクセスが拒否されました。

となり、このコマンドでは情報を取得できませんでした。

このエラーだけでは原因を特定できないため、設定変更はせず、続いて net use で既存接続を確認しました。

net use

今回の結果です。

新しい接続は記憶されます。

一覧にエントリが存在しません。

この時点では net use が管理するネットワーク接続一覧にエントリはありませんでした。

今回 Get-SmbConnection は「アクセスが拒否されました」となりました。

この記事では、この結果だけから原因を断定しません。後続の net use とエクスプローラーによる接続確認を継続しました。

9.4 Sambaユーザーを明示して接続する

次に、Windowsから使用するSambaユーザーを明示して共有へ接続しました。

net use \\192.168.11.9\share /user:WORKGROUP\honta *

Microsoftの net use では、/user: で接続に使用するユーザー名を指定でき、パスワード部分に * を指定すると対話形式でパスワード入力を求められます。

判断元URL：

今回は、

ユーザー名
  └─ WORKGROUP\honta

パスワード
  └─ 第5章で設定したSamba用パスワード

を使用しました。

実行すると、

\\192.168.11.9\share のパスワードを入力してください:
コマンドは正常に終了しました。

となりました。

これで、WindowsからSambaユーザー honta を明示した接続が成功しました。

Samba用パスワードをコマンドへ直接書くと、コマンド履歴などへ認証情報が残る可能性があります。

今回は、

*

を指定し、パスワードをプロンプトから入力しました。

実際のパスワードは記事本文や作業ログへ記録しません。

9.5 net use で接続済みになったことを確認する

接続後、再び net use を実行しました。

net use

今回の結果です。

新しい接続は記憶されます。

ステータス  ローカル名 リモート名                ネットワーク名

-------------------------------------------------------------------------------
OK                     \\192.168.11.9\share      Microsoft Windows Network
コマンドは正常に終了しました。

リモート名、

\\192.168.11.9\share

のステータスが、

OK

になっていることを確認できました。

9.6 PowerShellから共有フォルダを参照する

続いて、PowerShellからUNCパスを直接指定して共有フォルダの内容を確認しました。

Get-ChildItem \\192.168.11.9\share

今回の結果では、エラーは表示されず、そのままプロンプトへ戻りました。

第8章の最後で共有ディレクトリ内を空にしていたため、表示対象のファイルがない状態です。

これでPowerShellからも、

\\192.168.11.9\share

へアクセスできることを確認できました。

9.7 エクスプローラーから共有フォルダを開く

net use でSambaユーザーを明示して接続したあと、再度Windowsのエクスプローラーから、

\\192.168.11.9\share

へアクセスしました。

今度は共有フォルダを正常に開くことができました。

エクスプローラー上では、

ネットワーク
  ↓
192.168.11.9
  ↓
share

と表示され、共有フォルダ内には、

このフォルダーは空です。

と表示されました。

これは第8章でテストファイルを削除し、/srv/samba/share を空の状態に戻していた結果とも一致します。

9.8 Windowsからの接続結果を整理する

ここまでのWindows側の検証結果は次のとおりです。

Windows: 192.168.11.2
  ↓
Test-NetConnection
  ↓
192.168.11.9:445
  ↓
TcpTestSucceeded : True
  ↓
最初のExplorer接続
  ↓
0x80004005
  ↓
net useで既存接続確認
  ↓
接続なし
  ↓
WORKGROUP\honta を明示
  ↓
Samba用パスワードを対話入力
  ↓
net use成功
  ↓
接続状態: OK
  ↓
Get-ChildItemで共有参照成功
  ↓
Explorerから再接続
  ↓
\\192.168.11.9\share を正常に表示

今回、最初のエクスプローラー接続では 0x80004005 となりましたが、TCP/445への疎通は成功していました。

その後、

net use \\192.168.11.9\share /user:WORKGROUP\honta *

でSambaユーザー honta を明示して接続すると成功し、その後はPowerShellとエクスプローラーの両方から共有フォルダを参照できました。

この時点で、

Windows
  ↓
家庭内LAN
  ↓
UFW
  ↓
Samba
  ↓
honta認証
  ↓
/srv/samba/share

という実際のクライアント接続まで確認できました。

次はWindows側から実際にファイルを作成・読み取り・編集・削除し、共有フォルダへの書き込みまで確認します。

10. Windowsとの読み書きを確認する

Windowsから共有フォルダへ接続できたので、実際にWindows側からファイルを作成・読み取り・追記・削除し、LIFEBOOK側でも同じ内容が反映されることを確認します。

今回はPowerShellを使用し、UNCパス、

\\192.168.11.9\share

へ直接ファイル操作を行いました。

10.1 Windowsからテストファイルを作成する

まず、Windows PowerShellから共有フォルダへテストファイルを作成します。

Set-Content `
  -Path "\\192.168.11.9\share\windows-write-test.txt" `
  -Value "Windows Samba write test" `
  -Encoding utf8

Set-Content は、指定したファイルへ内容を書き込むPowerShell cmdletです。

判断元URL：

作成後、共有フォルダの内容を確認しました。

Get-ChildItem \\192.168.11.9\share

今回の結果です。

    ディレクトリ:\\192.168.11.9\share

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          2026/09/10    23:39             26 windows-write-test.txt

Windowsから、

windows-write-test.txt

を正常に作成できました。

10.2 Windowsからファイル内容を読み取る

続いて、作成したファイルの内容を確認します。

Get-Content \\192.168.11.9\share\windows-write-test.txt

今回の結果です。

Windows Samba write test

WindowsからSamba共有上のファイルを正常に読み取れました。

10.3 Windowsから内容を追記する

次に、同じファイルへ2行目を追記します。

Add-Content `
  -Path "\\192.168.11.9\share\windows-write-test.txt" `
  -Value "Second line from Windows" `
  -Encoding utf8

Add-Content は、既存ファイルへ内容を追記するPowerShell cmdletです。

判断元URL：

追記後に内容を再確認しました。

Get-Content \\192.168.11.9\share\windows-write-test.txt

今回の結果です。

Windows Samba write test
Second line from Windows

Windowsから既存ファイルへの追記も成功しました。

10.4 LIFEBOOK側から同じファイルを確認する

Windowsから作成・追記したファイルが、LIFEBOOK側の実ファイルとしてどのように見えるか確認しました。

ls -l /srv/samba/share/windows-write-test.txt

今回の結果です。

-rwxr--r-- 1 honta honta 52  9月 10 23:40 /srv/samba/share/windows-write-test.txt

ファイル内容も確認します。

cat /srv/samba/share/windows-write-test.txt

結果：

Windows Samba write test
Second line from Windows

Windows側で書き込んだ2行が、LIFEBOOK側でも同じ内容として確認できました。

つまり、

Windows
  ↓
SMB
  ↓
Samba
  ↓
/srv/samba/share
  ↓
ext4上の実ファイル

まで正しく反映されています。

10.5 Windowsから作成したファイルのLinux権限を確認する

続いて、Windowsから作成したファイルのLinux側permissionを確認しました。

stat -c '%A %a %U:%G %n' \
  /srv/samba/share/windows-write-test.txt

今回の結果です。

-rwxr--r-- 744 honta:honta /srv/samba/share/windows-write-test.txt

通常のテキストファイルですが、

owner execute

の実行ビットが付いた 0744 になっていました。

この時点では原因を決めつけず、Samba側の実効設定を確認しました。

10.6 create mask などの実効値を確認する

まず [share] に対する create mask を確認します。

testparm -s \
  --section-name=share \
  --parameter-name='create mask'

今回の結果です。

0744

続いて force create mode。

testparm -s \
  --section-name=share \
  --parameter-name='force create mode'

結果：

0000

map archive も確認しました。

testparm -s \
  --section-name=share \
  --parameter-name='map archive'

結果：

Yes

さらに store dos attributes を確認します。

testparm -s \
  --section-name=share \
  --parameter-name='store dos attributes'

結果：

Yes

Samba 4.19公式では、create mask のデフォルト値は 0744 で、新規ファイル作成時に計算されたUNIX modeへbitwise ANDされるマスクとして説明されています。

判断元URL：

公式記載：

Default: create mask = 0744

また、directory mask のデフォルト値は 0755 です。

公式記載：

Default: directory mask = 0755

今回の実機でも、明示設定前の [share] では create mask = 0744 が実効値として確認できました。

10.7 DOS属性がextended attributeへ保存されていることを確認する

Windowsから作成したファイルについて、DOS属性用のextended attributeも確認しました。

getfattr -d -m 'user.DOSATTRIB' \
  /srv/samba/share/windows-write-test.txt

今回の結果です。

getfattr: Removing leading '/' from absolute path names
# file: srv/samba/share/windows-write-test.txt
user.DOSATTRIB=0sAAAFAAUAAAARAAAAIAAAAD4k3yEyQd0B

user.DOSATTRIB が実際に存在していました。

Samba 4.19公式では、store dos attributes = yes の場合、DOS属性をUNIX permission bitへ直接マッピングする前に、user.DOSATTRIB extended attributeへ保存すると説明されています。

判断元URL：

公式記載：

DOS attributes will be stored onto an extended attribute in the UNIX filesystem

さらに、store dos attributes が有効な場合、map archive などの設定はoverrideされ、offとして扱われることも説明されています。

今回の実機では、

store dos attributes = Yes

かつ、

user.DOSATTRIB

が存在することを確認できました。

今回、Windowsから作成したテキストファイルが 0744 になったことと、実効 create mask = 0744 が確認できたことは事実です。

ただし、create mask は「必ず0744を設定する」パラメータではなく、計算されたUNIX modeへ適用されるマスクです。

そのため、今回の記事では内部処理を推測で断定せず、「通常のテキストファイルに実行権限は不要だったため、今回の用途に合わせてより厳しいmaskを明示する」という判断に留めます。

10.8 ファイルとディレクトリのmaskを明示する

今回の共有は、

利用ユーザー
  └─ hontaのみ

という個人用構成です。

通常のテキストファイルやバックアップファイルへ実行権限は不要なので、[share] に次の2行を追加しました。

create mask = 0600
directory mask = 0700

最終的な [share] は次の構成です。

[share]
    path = /srv/samba/share
    browsable = yes
    read only = no
    guest ok = no
    valid users = honta
    create mask = 0600
    directory mask = 0700

今回は、

新規ファイル
  owner: rw-
  group: ---
  others: ---

新規ディレクトリ
  owner: rwx
  group: ---
  others: ---

を意図した設定にしています。

create mask や directory mask は、Samba経由で新規作成されるファイル・ディレクトリのLinux側permissionへ影響します。

複数ユーザーで共有する環境では 0600 / 0700 が適切とは限りません。

この記事では、Samba利用者を honta だけに限定している今回の個人用環境に合わせて設定しています。

10.9 testparm で変更後の設定を確認する

設定変更後、testparm で構文と実効値を確認しました。

sudo 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

[share] は次のように表示されました。

[share]
        create mask = 0600
        directory mask = 0700
        path = /srv/samba/share
        read only = No
        valid users = honta

意図した、

create mask = 0600
directory mask = 0700

が実効設定として認識されていることを確認できました。

10.10 Sambaサービスを再起動して設定を反映する

変更した設定を反映するため、smbd と nmbd を再起動しました。

sudo systemctl restart smbd.service nmbd.service

再起動後の状態を確認します。

systemctl is-active smbd
systemctl is-active nmbd

今回の結果です。

active
active

両サービスとも正常に起動していることを確認できました。

10.11 Windowsから新規ファイルを作り直す

create mask は新規作成時に適用されるため、変更前に作成したテストファイルをWindows側から削除しました。

Remove-Item \\192.168.11.9\share\windows-write-test.txt

削除後に確認します。

Get-ChildItem \\192.168.11.9\share

今回の結果では何も表示されず、共有フォルダが空になりました。

続いて、新しい設定の状態で同名ファイルを再作成します。

Set-Content `
  -Path "\\192.168.11.9\share\windows-write-test.txt" `
  -Value "Windows Samba write test" `
  -Encoding utf8

10.12 Windowsから新規ディレクトリも作成する

directory mask も確認するため、Windowsからテスト用ディレクトリを新規作成しました。

New-Item `
  -ItemType Directory `
  -Path "\\192.168.11.9\share\windows-dir-test"

今回のWindows側では、

windows-dir-test

が正常に作成されました。

10.13 LIFEBOOK側で変更後のpermissionを確認する

まず、Windowsから新規作成したファイルを確認しました。

stat -c '%A %a %U:%G %n' \
  /srv/samba/share/windows-write-test.txt

今回の結果です。

-rw------- 600 honta:honta /srv/samba/share/windows-write-test.txt

意図したとおり、新規ファイルは、

0600

になりました。

続いて、Windowsから作成したディレクトリを確認します。

stat -c '%A %a %U:%G %n' \
  /srv/samba/share/windows-dir-test

今回の結果です。

drwx------ 700 honta:honta /srv/samba/share/windows-dir-test

こちらも意図した、

0700

になりました。

これで、

create mask = 0600
  ↓
Windowsから新規ファイル作成
  ↓
0600 honta:honta

directory mask = 0700
  ↓
Windowsから新規ディレクトリ作成
  ↓
0700 honta:honta

と、設定が実際に反映されることを確認できました。

10.14 Windowsからテストファイルとディレクトリを削除する

検証用に作成したファイルとディレクトリをWindows側から削除します。

Remove-Item \\192.168.11.9\share\windows-write-test.txt
Remove-Item \\192.168.11.9\share\windows-dir-test

削除後、Windows側から共有フォルダを確認しました。

Get-ChildItem \\192.168.11.9\share

今回の結果では何も表示されず、共有フォルダが空になりました。

Remove-Item は、指定したファイルやディレクトリなどを削除するPowerShell cmdletです。

判断元URL：

10.15 LIFEBOOK側でも削除済みを確認する

最後にLIFEBOOK側から共有ディレクトリを確認しました。

ls -la /srv/samba/share

今回の結果です。

合計 8
drwx------ 2 honta honta 4096  9月 11 00:05 .
drwxr-xr-x 3 root  root  4096  9月 10 21:50 ..

Windows側で削除した、

windows-write-test.txt
windows-dir-test

は存在せず、共有ディレクトリが空の状態へ戻っていることを確認できました。

10.16 Windowsとの読み書き確認結果を整理する

ここまでで、WindowsとLIFEBOOKの間で次の一連の操作を確認できました。

Windowsからファイル作成
  ↓
Windowsから読み取り成功
  ↓
Windowsから追記成功
  ↓
LIFEBOOK側で同じ内容を確認
  ↓
Linux permissionを確認
  ↓
初回ファイルは 0744
  ↓
Samba実効設定を確認
  ↓
create mask = 0744
store dos attributes = Yes
user.DOSATTRIB あり
  ↓
今回の用途では実行権限不要と判断
  ↓
create mask = 0600
directory mask = 0700
  ↓
smbd / nmbd再起動
  ↓
Windowsからファイル・ディレクトリを再作成
  ↓
ファイル: 0600 honta:honta
ディレクトリ: 0700 honta:honta
  ↓
Windowsから削除
  ↓
LIFEBOOK側でも削除済みを確認

これで、

Windows
  ↓
家庭内LAN
  ↓
UFW
  ↓
Samba
  ↓
honta認証
  ↓
ファイル作成
  ↓
読み取り
  ↓
追記
  ↓
削除
  ↓
Linux側にも正常反映

まで確認できました。

次はLIFEBOOKを再起動し、Sambaサービス・UFW・共有設定が再起動後も維持され、Windowsから再接続できることを確認します。

11. 再起動後も利用できるか確認する

Sambaのインストール・共有設定・UFW設定・Windowsからの読み書き確認まで完了したので、最後にLIFEBOOKを再起動し、設定が再起動後も維持されることを確認します。

一時的に動作しているだけではファイルサーバーとして運用できないため、

Sambaサービス
UFWルール
smb.conf
共有ディレクトリのpermission
Sambaユーザー
WindowsからのSMB接続

が再起動後も維持されることを順番に確認しました。

11.1 LIFEBOOKを再起動する

LIFEBOOKを再起動しました。

再起動後、起動時刻を確認します。

uptime -s

今回の結果です。

2026-09-11 00:29:03

再起動後の新しいセッションであることを確認できました。

11.2 smbd と nmbd の起動状態を確認する

まず、Sambaのファイル共有を担当する smbd を確認しました。

systemctl is-active smbd
systemctl is-enabled smbd

今回の結果です。

active
enabled

続いて nmbd を確認しました。

systemctl is-active nmbd
systemctl is-enabled nmbd

今回の結果です。

active
enabled

再起動後も、

smbd
  ├─ active
  └─ enabled

nmbd
  ├─ active
  └─ enabled

となっていました。

これでSamba関連サービスが再起動後も自動起動し、実際に稼働していることを確認できました。

11.3 UFWのルールが維持されていることを確認する

次に、Samba用に追加したUFWルールが再起動後も維持されているか確認しました。

sudo ufw status verbose

今回の結果です。

状態: アクティブ
ロギング: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
新しいプロファイル: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    192.168.11.0/24
137,138/udp (Samba)        ALLOW IN    192.168.11.0/24
139,445/tcp (Samba)        ALLOW IN    192.168.11.0/24

再起動後も、

SSH
  └─ 192.168.11.0/24 → TCP/22

Samba
  └─ 192.168.11.0/24
       ├─ UDP/137
       ├─ UDP/138
       ├─ TCP/139
       └─ TCP/445

という家庭内LAN限定のルールが維持されていました。

また、

Default: deny (incoming)

も変わっていません。

11.4 smb.conf の共有設定が維持されていることを確認する

再起動後もSamba設定が正常に読み込まれているか確認しました。

sudo 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

今回作成した [share] も、次の実効設定として確認できました。

[share]
        create mask = 0600
        directory mask = 0700
        path = /srv/samba/share
        read only = No
        valid users = honta

再起動後も、

create mask = 0600
directory mask = 0700
path = /srv/samba/share
valid users = honta

が維持され、Loaded services file OK. となっていました。

11.5 共有ディレクトリのpermissionを確認する

共有ディレクトリ自体のLinux側permissionも確認しました。

stat -c '%A %a %U:%G %n' /srv/samba/share

今回の結果です。

drwx------ 700 honta:honta /srv/samba/share

再起動後も、

owner: honta
group: honta
mode:  0700

が維持されています。

11.6 Sambaユーザーが維持されていることを確認する

Sambaの認証情報データベースに honta が残っていることも確認しました。

sudo pdbedit -L -u honta

今回の結果です。

honta:1000:honta

再起動後もSambaユーザー honta が登録されたままであることを確認できました。

11.7 WindowsからTCP/445へ再接続できるか確認する

LIFEBOOK再起動後、Windows側から再びSMB用TCP/445へ接続できるか確認しました。

Test-NetConnection 192.168.11.9 -Port 445

今回の結果です。

ComputerName     : 192.168.11.9
RemoteAddress    : 192.168.11.9
RemotePort       : 445
InterfaceAlias   : Wi-Fi
SourceAddress    : 192.168.11.2
TcpTestSucceeded : True

再起動後もWindowsから、

192.168.11.9:445

へ到達できました。

11.8 Windowsから共有フォルダを再確認する

最後に、Windows PowerShellから共有フォルダを参照しました。

Get-ChildItem \\192.168.11.9\share

今回の結果ではエラーは表示されず、そのままプロンプトへ戻りました。

第10章の最後でテストファイルとテストディレクトリを削除しているため、共有フォルダ内は空の状態です。

これで再起動後も、

Windows
  ↓
家庭内LAN
  ↓
TCP/445
  ↓
UFW
  ↓
Samba
  ↓
\\192.168.11.9\share

へアクセスできることを確認できました。

11.9 Windows側でネットワークドライブを永続化する

ここまでで、WindowsからUNCパス、

\\192.168.11.9\share

へ接続できることは確認できました。

ただし、実際に使うたびに、

net use \\192.168.11.9\share /user:WORKGROUP\honta *

を入力する運用では手間がかかります。

そこで、Windows側ではSamba共有を S: ドライブとして割り当て、再起動後も資格情報を再入力せず利用できる状態まで確認しました。

11.9.1 S: ドライブを永続ネットワークドライブとして割り当てる

Windows PowerShellから、共有を S: ドライブへ割り当てました。

net use S: \\192.168.11.9\share /persistent:yes

/persistent:yes は、ネットワーク接続を次回ログオン時にも復元するための指定です。

判断元URL：

一度はユーザー名・Samba用パスワードを対話入力することで、S: ドライブ自体の割り当てには成功しました。

net use

では、

OK           S:        \\192.168.11.9\share      Microsoft Windows Network

となり、エクスプローラーでもネットワークドライブとして認識されました。

01-samba-s-drive-mapped.png

WindowsエクスプローラーでSamba共有がS:ドライブとして認識された状態

11.9.2 Windows再起動後は S: が「切断」状態になった

その後Windowsを再起動すると、S: の割り当て自体は残っていましたが、エクスプローラーでは赤い×印が付き、ダブルクリックしても共有を開けませんでした。

net use でも、

切断         S:        \\192.168.11.9\share      Microsoft Windows Network

となっていました。

02-samba-s-drive-disconnected.png

Windows再起動後、S:ドライブの割り当ては残っているものの、Samba共有へ再接続できず「切断」状態になった画面

この時点でも、

Test-NetConnection 192.168.11.9 -Port 445

は、

TcpTestSucceeded : True

でした。

つまり、

S: の割り当て
  └─ 残っている

TCP/445
  └─ 到達可能

Samba共有への認証済み接続
  └─ 復元できていない

という状態でした。

11.9.3 Windows資格情報マネージャーへSamba資格情報を保存する

毎回Samba用パスワードを入力しなくても済むよう、Windowsの 資格情報マネージャー へSambaの資格情報を保存しました。

Microsoft公式では、資格情報マネージャーについて、Webサイト、接続したアプリケーション、ネットワークへのサインイン用として保存された資格情報を管理できると説明されています。

判断元URL：

今回の操作は、

コントロール パネル
  ↓
ユーザー アカウント
  ↓
資格情報マネージャー
  ↓
Windows 資格情報
  ↓
Windows 資格情報の追加

です。

03-windows-credential-manager-add.png

Samba接続用の資格情報を保存するため、Windows資格情報マネージャーで「Windows 資格情報の追加」を選択する画面

登録内容は次のとおりです。

インターネットまたはネットワークのアドレス
  192.168.11.9

ユーザー名
  WORKGROUP\honta

パスワード
  Samba用パスワード

04-windows-credential-input.png

Windows資格情報へ 192.168.11.9 と WORKGROUP\honta を登録し、Samba用パスワードを保存する画面

Samba用パスワードは認証情報です。

スクリーンショットでは入力欄が伏字になっていることを確認し、記事本文へ実際のパスワードは記載しません。

保存後、Windows資格情報の一覧に、

192.168.11.9

が登録されたことを確認しました。

05-windows-credential-saved.png

Samba接続用の資格情報をWindows資格情報マネージャーへ保存し、192.168.11.9 が登録されたことを確認した画面

11.9.4 保存済み資格情報を使う状態で S: を作り直す

資格情報を保存したあと、既存の S: ドライブを一度削除しました。

net use S: /delete

今回の結果です。

S: が削除されました。

続いて、コマンド側ではユーザー名やパスワードを指定せず、S: ドライブを再作成しました。

net use S: \\192.168.11.9\share /persistent:yes

今回の結果です。

コマンドは正常に終了しました。

接続状態を確認します。

net use

結果：

ステータス  ローカル名 リモート名                ネットワーク名
-------------------------------------------------------------------------------
OK           S:        \\192.168.11.9\share      Microsoft Windows Network

さらに、

Get-ChildItem S:\

もエラーなく実行できました。

この操作では net use 実行時にSamba用パスワードを再入力していないため、保存済みのWindows資格情報を使った状態で S: へ接続できたことを確認できました。

11.9.5 Windowsを再起動して最終確認する

最後にもう一度Windowsを再起動しました。

再起動後、PowerShellで認証コマンドを入力することなく、エクスプローラーから S: ドライブをダブルクリックしました。

結果、Samba用パスワードの再入力なしで共有フォルダを開くことができました。

今回確認できた最終状態は次のとおりです。

Windows起動
  ↓
S: ドライブ
  └─ \\192.168.11.9\share
  ↓
Windows資格情報
  └─ WORKGROUP\honta
  ↓
Samba認証
  ↓
共有フォルダを開く
  ↓
パスワード再入力なし

これで、サーバー側が再起動後も動作することに加え、Windows側でも普段使いできる永続ネットワークドライブとして利用できるところまで確認できました。

11.10 再起動後の確認結果を整理する

今回の再起動後確認とWindows側の永続接続確認では、次の項目をすべて確認できました。

LIFEBOOK再起動
  ↓
uptimeで再起動後の起動時刻を確認
  ↓
smbd
  ├─ active
  └─ enabled
  ↓
nmbd
  ├─ active
  └─ enabled
  ↓
UFW
  ├─ active
  ├─ incoming deny
  ├─ SSHは192.168.11.0/24のみ
  └─ Sambaも192.168.11.0/24のみ
  ↓
testparm
  ├─ Loaded services file OK.
  ├─ ROLE_STANDALONE
  └─ [share]設定維持
  ↓
/srv/samba/share
  └─ 0700 honta:honta
  ↓
Sambaユーザー
  └─ honta:1000:honta
  ↓
WindowsからTCP/445
  └─ TcpTestSucceeded : True
  ↓
Windowsから共有参照
  └─ エラーなし
  ↓
Windows側でS:を永続マッピング
  ↓
再起動後にS:が「切断」
  ↓
資格情報マネージャーへ
WORKGROUP\hontaを保存
  ↓
S:を作り直す
  ↓
Windows再起動
  ↓
パスワード再入力なしでS:を開くことに成功

これで、LIFEBOOKを再起動してもSambaファイルサーバーとして必要な設定が維持され、Windowsから再び共有フォルダへアクセスできることを確認できました。

次は、ここまでの構成・サービス・Firewall・共有設定・permissionをまとめて最終確認します。

12. 最終確認

ここまでで、Sambaのインストール、共有設定、認証、UFW、Windowsからの読み書き、再起動後の動作確認まで完了しました。

最後に、現在のSamba接続を smbstatus で確認し、Windowsからどのユーザー・プロトコルで接続されているかを確認します。

Samba公式では、smbstatus は現在のSamba接続を一覧表示するためのツールと説明されています。

判断元URL：

公式記載：

smbstatus is a very simple program to list the current Samba connections.

12.1 Windowsから共有へアクセスする

smbstatus で現在の接続を確認できるように、Windows PowerShellから共有フォルダへアクセスしました。

Get-ChildItem \\192.168.11.9\share

今回の共有フォルダは空のため、ファイル一覧は表示されず、そのままプロンプトへ戻りました。

エラーは表示されていません。

12.2 smbstatus で現在の接続を確認する

LIFEBOOK側で次のコマンドを実行しました。

sudo smbstatus

今回の主な結果です。

Samba version 4.19.5-Ubuntu

PID   Username  Group  Machine                              Protocol Version  Encryption  Signing
4272  honta     honta  192.168.11.2 (ipv4:192.168.11.2:63396)  SMB3_11       -           AES-128-GMAC
4853  nobody    nogroup lifebook-ubuntu (ipv4:192.168.11.9:50752) SMB3_11      -           -
4887  honta     honta  192.168.11.9 (ipv4:192.168.11.9:54988)    SMB3_11      -           partial(AES-128-GMAC)

共有サービス側には、次の接続が表示されました。

Service  pid   Machine
IPC$     4853  lifebook-ubuntu
share    4272  192.168.11.2
share    4887  192.168.11.9

このうち、Windows PCからの接続は、

Machine  → 192.168.11.2
Username → honta
Service  → share

です。

12.3 Windows接続がSMB 3.1.1であることを確認する

Windows PC 192.168.11.2 からの接続では、

Protocol Version
  └─ SMB3_11

と表示されました。

つまり今回のWindowsとLIFEBOOK間の実接続では、SMB 3.1.1がネゴシエーションされています。

第8章の smbclient -L では、

SMB1 disabled -- no workgroup available

という表示も確認していましたが、今回の smbstatus ではWindowsから実際に、

SMB3_11

で接続されていることを確認できました。

SMB1、SMB2、SMB3 はファイルシステム名ではなく、ネットワーク越しにファイル共有を行うSMBプロトコルの世代です。

今回のLIFEBOOKのローカルファイルシステムは ext4 ですが、Windowsとの通信にはSMBを使用しています。

SMB1 / SMB2 / SMB3の違いについては、後述の「今回躓いたポイント」でも整理します。

12.4 SMB署名も確認する

Windows PC 192.168.11.2 からの接続では、Signing に、

AES-128-GMAC

と表示されました。

Samba公式の smb.conf ドキュメントでは、SMB3.1.1で使用可能な署名アルゴリズムとして AES-128-GMAC が挙げられています。

判断元URL：

今回の実機では、Windowsからの接続について AES-128-GMAC によるSMB署名が使用されていることを smbstatus で確認できました。

SMB署名とSMB暗号化は別の機能です。

今回の smbstatus ではWindows接続の Signing に AES-128-GMAC が表示されましたが、Encryption 欄には暗号方式は表示されていませんでした。

この記事では、この実機出力以上のことを推測で断定しません。

12.5 最終的なSamba構成を確認する

今回構築したSambaファイルサーバーの最終状態を整理します。

LIFEBOOK
Ubuntu 24.04.4 LTS Desktop
  │
  ├─ Samba
  │    └─ Version 4.19.5-Ubuntu
  │
  ├─ smbd
  │    ├─ active
  │    └─ enabled
  │
  ├─ nmbd
  │    ├─ active
  │    └─ enabled
  │
  ├─ Sambaユーザー
  │    └─ honta
  │
  ├─ /etc/samba/smb.conf
  │    └─ [share]
  │         ├─ path = /srv/samba/share
  │         ├─ browsable = yes
  │         ├─ read only = no
  │         ├─ guest ok = no
  │         ├─ valid users = honta
  │         ├─ create mask = 0600
  │         └─ directory mask = 0700
  │
  ├─ /srv/samba/share
  │    ├─ owner = honta
  │    ├─ group = honta
  │    └─ mode = 0700
  │
  └─ UFW
       ├─ Default incoming = deny
       ├─ SSH
       │    └─ 192.168.11.0/24 → TCP/22
       └─ Samba
            └─ 192.168.11.0/24
                 ├─ UDP/137
                 ├─ UDP/138
                 ├─ TCP/139
                 └─ TCP/445

Windows側からは、

Windows PC
  └─ 192.168.11.2
       │
       │ SMB3_11
       │ Signing: AES-128-GMAC
       ▼
\\192.168.11.9\share
       │
       │ Sambaユーザー honta
       ▼
/srv/samba/share

という接続になっていることを実機で確認できました。

12.6 今回確認できた項目

最終的に、次の項目を実機で確認できました。

Samba Server導入
  ↓
Samba 4.19.5-Ubuntu
  ↓
smbd / nmbd active・enabled
  ↓
/srv/samba/share 作成
  ↓
Linux側 owner honta:honta / mode 0700
  ↓
Sambaユーザー honta 登録
  ↓
guest ok = no
  ↓
valid users = honta
  ↓
create mask = 0600
directory mask = 0700
  ↓
testparm: Loaded services file OK.
  ↓
UFW incoming denyを維持
  ↓
Sambaは192.168.11.0/24からのみ許可
  ↓
LIFEBOOK自身からSMB読み書き成功
  ↓
WindowsからTCP/445到達成功
  ↓
Windowsから認証・共有接続成功
  ↓
Windowsから作成・読み取り・追記・削除成功
  ↓
LIFEBOOK再起動後も設定維持
  ↓
Windowsから再接続成功
  ↓
smbstatus
  ├─ User: honta
  ├─ Client: 192.168.11.2
  ├─ Share: share
  ├─ Protocol: SMB3_11
  └─ Signing: AES-128-GMAC
  ↓
Windows資格情報
  └─ WORKGROUP\honta
  ↓
S: → \\192.168.11.9\share
  ↓
Windows再起動後も
パスワード再入力なしで利用成功

これで、家庭内LAN上のWindows PCから利用する認証付きSambaファイルサーバーの構築と動作確認まで完了しました。

今回躓いたポイント

今回のSamba構築では、インストールそのものよりも、Windowsからの接続確認やLinux側permissionの扱いでいくつか確認が必要になりました。

ここでは、実際に発生した主な躓きと、その切り分け結果を整理します。

Windowsエクスプローラーから最初は 0x80004005 で接続できなかった

最初にWindowsのエクスプローラーから、

\\192.168.11.9\share

へアクセスしたところ、

\\192.168.11.9\share にアクセスできません

エラー コード: 0x80004005
エラーを特定できません

となり、共有フォルダを開けませんでした。

ただし、その直前にPowerShellで、

Test-NetConnection -ComputerName 192.168.11.9 -Port 445

を実行すると、

TcpTestSucceeded : True

でした。

さらにLIFEBOOK自身では、smbclient を使った、

smbclient //127.0.0.1/share -U honta -c 'ls'

も成功していました。

このため、

Windows
  ↓
家庭内LAN
  ↓
UFW
  ↓
TCP/445
  ↓
LIFEBOOK

というネットワーク経路そのものには到達できていることを確認し、UFWを無効化したりSMB1を有効化したりする変更は行いませんでした。

Windows側で既存接続を確認すると、

net use

は、

一覧にエントリが存在しません。

でした。

そこでSambaユーザーを明示して、

net use \\192.168.11.9\share /user:WORKGROUP\honta *

を実行し、Samba用パスワードを対話入力しました。

結果：

コマンドは正常に終了しました。

その後、

Get-ChildItem \\192.168.11.9\share

もエラーなく実行でき、エクスプローラーからも共有フォルダを開けるようになりました。

最初のエクスプローラー接続が 0x80004005 になった原因は、今回の確認結果だけでは一意に特定できませんでした。

この記事では、

  • TCP/445への到達は成功していた
  • Sambaサーバー自身からの共有アクセスは成功していた
  • WORKGROUP\honta を明示した net use では接続に成功した
  • その後エクスプローラーからも共有を開けた

という実際に確認できた事実までを記録し、原因を推測で断定しません。

Windows再起動後、S: ドライブが「切断」状態になった

Windowsからの通常接続ができるようになったあと、毎回、

net use \\192.168.11.9\share /user:WORKGROUP\honta *

を入力しなくても使えるよう、Samba共有を S: ドライブへ割り当てることにしました。

最初に、資格情報の保存も同時に行おうとして、

net use S: \\192.168.11.9\share /user:WORKGROUP\honta * /persistent:yes /savecred

を実行しました。

しかし今回のWindows環境では、

コマンドが矛盾するスイッチで使用されました。

NET HELPMSG 3510 と入力すると、より詳しい説明が得られます。

となり、この組み合わせでは実行できませんでした。

そこで、ネットワークドライブの永続化と資格情報の保存を分けて確認することにしました。

まず、いったん作成していたドライブ文字なしの接続を削除しました。

net use \\192.168.11.9\share /delete

続いて cmdkey を使い、接続先とユーザー名を登録しました。

cmdkey /add:192.168.11.9 /user:WORKGROUP\honta

今回の結果です。

CMDKEY: 資格情報を正しく追加しました。

その状態で、

net use S: \\192.168.11.9\share /persistent:yes

を実行すると、最初は、

\\192.168.11.9\share のパスワードまたはユーザー名が無効です。

となり、ユーザー名とSamba用パスワードの入力を求められました。

対話入力すると接続自体には成功し、

net use

で、

OK           S:        \\192.168.11.9\share      Microsoft Windows Network

と表示されました。

しかしWindowsを再起動すると、S: 自体は残っているものの、

切断         S:        \\192.168.11.9\share      Microsoft Windows Network

となり、エクスプローラーからも共有を開けませんでした。

この時点でも、

Test-NetConnection 192.168.11.9 -Port 445

は、

TcpTestSucceeded : True

でした。

つまり、

S: の割り当て
  └─ 残っている

TCP/445
  └─ 到達可能

Samba共有への認証済み接続
  └─ 復元できていない

という状態でした。

そこでWindowsの 資格情報マネージャー へ、Samba接続に使用する資格情報を明示的に保存しました。

ネットワークアドレス: 192.168.11.9
ユーザー名:           WORKGROUP\honta
パスワード:           Samba用パスワード

保存後、cmdkey /list でも、

ターゲット: Domain:target=192.168.11.9
種類:       ドメイン パスワード
ユーザー:   WORKGROUP\honta

として登録されていることを確認しました。

その後、既存の S: をいったん削除しました。

net use S: /delete

続いて、ユーザー名やパスワードをコマンド側へ指定せず、

net use S: \\192.168.11.9\share /persistent:yes

で S: を作り直しました。

結果：

コマンドは正常に終了しました。

さらに、

net use

では、

OK           S:        \\192.168.11.9\share      Microsoft Windows Network

となり、

Get-ChildItem S:\

もエラーなく実行できました。

最後にWindowsをもう一度再起動し、PowerShellで認証コマンドを入力せず、エクスプローラーから S: をダブルクリックしました。

結果、Samba用パスワードの再入力なしで共有フォルダを開くことができました。

今回の切り分けを整理すると、

毎回のnet use入力を省きたい
  ↓
/persistent:yes + /savecred を試す
  ↓
NET HELPMSG 3510
「矛盾するスイッチ」
  ↓
永続化と資格情報保存を分離
  ↓
cmdkeyで接続先・ユーザーを登録
  ↓
net use S: ... /persistent:yes
  ↓
初回はユーザー名・パスワード入力が必要
  ↓
S:作成成功
  ↓
Windows再起動
  ↓
S:は残るが「切断」
  ↓
TCP/445は到達可能
  ↓
資格情報マネージャーへ
192.168.11.9 / WORKGROUP\honta / Samba用パスワードを保存
  ↓
S:を削除して作り直す
  ↓
Get-ChildItem S:\ 成功
  ↓
Windows再起動
  ↓
パスワード再入力なしでS:を開くことに成功

という流れでした。

/persistent:yes はネットワーク接続を永続化するための指定ですが、今回の実機では、それだけでは再起動後に S: が「切断」状態になりました。

Windows資格情報マネージャーへSamba用資格情報を保存し、S: を作り直したあとに再起動確認まで行うことで、毎回パスワードを入力せず利用できる状態になりました。

この記事では、このWindows環境で実際に確認できた結果として記録します。

UFWの --dry-run なのに「ルールをアップデートしました」と表示された

Samba用のUFWルールを本適用する前に、

sudo ufw --dry-run allow from 192.168.11.0/24 to any app Samba

で追加内容を確認しました。

しかし、出力の最後には、

ルールをアップデートしました

と表示されました。

表示だけを見ると、実際にFirewallルールが変更されたようにも見えます。

Ubuntu 24.04のUFW man pageでは、--dry-run について次のように説明されています。

判断元URL：

公式記載：

don't modify anything, just show the changes

そのため、表示だけで判断せず、

sudo ufw status numbered

で実際の状態を確認しました。

結果：

[ 1] 22/tcp  ALLOW IN  192.168.11.0/24

Samba用ルールはまだ追加されていませんでした。

その後、改めて本適用として、

sudo ufw allow from 192.168.11.0/24 to any app Samba

を実行し、

137,138/udp (Samba)  ALLOW IN  192.168.11.0/24
139,445/tcp (Samba)  ALLOW IN  192.168.11.0/24

が追加されたことを確認しました。

今回のように出力メッセージが紛らわしい場合でも、実際の設定状態を確認してから次へ進むことが重要でした。

Sambaが複数インターフェースで待ち受けていた

Sambaの待受状態を、

sudo ss -lntup \
  | grep -E 'smbd|nmbd|:(137|138|139|445)\b'

で確認したところ、nmbd は家庭内LAN側だけでなくDocker bridgeの、

172.17.0.1

でも待ち受けていました。

また、smbd は、

0.0.0.0:139
0.0.0.0:445
[::]:139
[::]:445

で待ち受けていました。

一見すると広い範囲からアクセスできるようにも見えますが、

サービスがsocketを待ち受けていること

と、

Firewallが外部からの通信を許可していること

は別です。

今回のUFWは、

Default: deny (incoming)

を維持し、Sambaについては、

192.168.11.0/24

からだけ許可しました。

最終的なUFW設定は、

22/tcp                     ALLOW IN    192.168.11.0/24
137,138/udp (Samba)        ALLOW IN    192.168.11.0/24
139,445/tcp (Samba)        ALLOW IN    192.168.11.0/24

です。

今回の記事では、Samba自身の待受インターフェースを追加設定で限定するのではなく、UFWの受信デフォルト deny を維持したまま、家庭内LANから必要なSamba通信だけを許可する構成にしました。

Windowsから作成したテキストファイルが 0744 になった

WindowsからSamba共有へ通常のテキストファイルを作成し、LIFEBOOK側で確認したところ、

-rwxr--r-- 744 honta:honta

となっていました。

通常のログやテキストデータとして使用するファイルに実行権限は不要なので、Samba側の実効設定を確認しました。

testparm -s \
  --section-name=share \
  --parameter-name='create mask'

結果：

0744

さらに、

testparm -s \
  --section-name=share \
  --parameter-name='force create mode'

testparm -s \
  --section-name=share \
  --parameter-name='map archive'

testparm -s \
  --section-name=share \
  --parameter-name='store dos attributes'

を確認すると、

force create mode   = 0000
map archive         = Yes
store dos attributes = Yes

でした。

Samba 4.19公式では、create mask は新規ファイル作成時に算出されたUNIX modeへbitwise ANDされるマスクで、デフォルト値は 0744 と説明されています。

判断元URL：

公式記載：

Default: create mask = 0744

また、store dos attributes = yes の場合、DOS属性はUNIX permission bitではなくextended attributeへ保存され、map archive などは無効として扱われます。

今回、実際のファイルを、

getfattr -d -m 'user.DOSATTRIB' \
  /srv/samba/share/windows-write-test.txt

で確認すると、

user.DOSATTRIB=...

が存在していました。

今回、Windowsから作成したファイルが 0744 になったことと、実効 create mask = 0744 が確認できたことは事実です。

ただし create mask は「必ず0744を設定する」パラメータではなく、新規ファイル作成時に計算されたUNIX modeへ適用されるマスクです。

そのため、内部処理を推測で断定せず、今回の用途では実行権限が不要であることを理由にmaskを明示的に変更しました。

今回の共有は honta だけが使用するため、[share] に、

create mask = 0600
directory mask = 0700

を追加しました。

変更後にWindowsから新しいファイルとディレクトリを作成し、LIFEBOOK側で確認すると、

ファイル:
-rw------- 600 honta:honta

ディレクトリ:
drwx------ 700 honta:honta

となりました。

これで、今回意図したpermissionが実際に反映されることを確認できました。

0600 / 0700 は、Samba利用ユーザーを honta だけに限定している今回の個人用環境に合わせた設定です。

複数ユーザーでファイルを共有する環境では、そのまま適用すると他ユーザーがアクセスできなくなるため、用途に応じたpermission設計が必要です。

SMB1 disabled はファイルシステムの話ではなかった

LIFEBOOK自身から共有一覧を確認した際、

smbclient -L 127.0.0.1 -U honta

の末尾に、

SMB1 disabled -- no workgroup available

と表示されました。

ここで登場する SMB1 は、ext4 や NTFS のようなファイルシステム名ではありません。

Microsoft公式ではSMBについて、

判断元URL：

公式記載：

The SMB protocol is a network file sharing protocol.

と説明されています。

今回出てきた用語を整理すると、次のようになります。

用語 種類 今回の役割
SMB1 / SMB2 / SMB3 ネットワークファイル共有プロトコルの世代 WindowsとSamba間の通信
Samba SMBをLinuxなどで提供するソフトウェア LIFEBOOK側のファイルサーバー
NT1 Sambaで扱われる古いSMB系プロトコル名 Samba 4.19ではSMB1系のレガシー側として扱われる
ext4 Linuxのファイルシステム LIFEBOOKのSSD上でファイルを保存
NTFS Windowsで使われるファイルシステム SMBとは別の層

Samba 4.19公式のプロトコル一覧では NT1 について、

Known as CIFS.

と説明されています。

また、Samba 4.19のサーバー側デフォルトは、

server min protocol = SMB2_02
server max protocol = SMB3

です。

判断元URL：

さらに今回、Windowsから実際に接続した状態を、

sudo smbstatus

で確認すると、

Machine          192.168.11.2
Username         honta
Protocol Version SMB3_11
Signing          AES-128-GMAC

となっていました。

つまり今回の実接続では、

Windows
  │
  │ SMB 3.1.1
  ▼
Samba
  │
  ▼
/srv/samba/share
  │
  ▼
ext4

という関係です。

SMB1 disabled と表示されても、Windowsとは SMB3_11 で正常に接続できていたため、SMB1を有効化する変更は行いませんでした。

SMBのバージョンとディスク上のファイルシステムは別の層です。

今回のLIFEBOOKでは、保存先のファイルシステムは ext4、Windowsとのネットワークファイル共有にはSMB 3.1.1を使用していることを実機で確認できました。

今回特に重要だったのは、エラー表示やデフォルト値だけを見て設定を変更せず、

症状を確認
  ↓
現在状態を確認
  ↓
公式仕様を確認
  ↓
実機で切り分け
  ↓
必要な設定だけ変更
  ↓
変更後に再検証

という順番を維持したことでした。

切り分けの時系列

今回のSamba構築では、いきなり設定を変更するのではなく、現在状態を確認しながら1段階ずつ進めました。

全体の流れを時系列で整理すると、次のようになります。

LIFEBOOKの実機環境を確認
  │
  ├─ Ubuntu 24.04.4 LTS
  ├─ LIFEBOOK FMVA52CBJ
  ├─ Intel Pentium P6200 2.13GHz
  ├─ メモリ 8GB
  ├─ 192.168.11.9/24
  └─ UFW: incoming deny
        ↓
Samba導入前の状態を確認
  │
  ├─ samba-libsは存在
  └─ Samba Server本体は未導入
        ↓
Ubuntu公式・Samba公式ドキュメントを確認
  │
  ├─ /etc/samba/smb.conf
  ├─ /srv/samba/share
  ├─ ゲスト共有は採用しない
  ├─ Sambaユーザー認証を使用
  └─ SMB1を有効化する設定は追加しない
        ↓
sudo apt update
        ↓
apt-cache policy samba
  │
  └─ 候補: 2:4.19.5+dfsg-4ubuntu9.7
        ↓
apt install --simulate samba
  │
  ├─ 新規22パッケージ
  ├─ アップグレード0
  └─ 削除0
        ↓
sudo apt install samba
        ↓
Samba 4.19.5-Ubuntu導入
  │
  ├─ /etc/samba/smb.conf 作成
  ├─ smbd: active / enabled
  ├─ nmbd: active / enabled
  └─ testparm: ROLE_STANDALONE
        ↓
共有ディレクトリ作成前の状態を確認
  │
  ├─ /srv/samba/share は未作成
  └─ /srvの空き容量 193G
        ↓
/srv/samba/share を作成
  │
  ├─ owner: honta:honta
  └─ mode: 0700
        ↓
Linux側で書き込みテスト
  │
  ├─ hontaでファイル作成成功
  └─ テストファイル削除
        ↓
Sambaユーザー一覧を確認
  │
  └─ 登録ユーザーなし
        ↓
sudo smbpasswd -a honta
  │
  └─ Added user honta.
        ↓
pdbeditで登録確認
  │
  └─ honta:1000:honta
        ↓
smb.conf変更前にバックアップ
  │
  └─ smb.conf.bak-20260910-220715
        ↓
既存の [share] がないことを確認
        ↓
[share] を追加
  │
  ├─ path = /srv/samba/share
  ├─ browsable = yes
  ├─ read only = no
  ├─ guest ok = no
  └─ valid users = honta
        ↓
testparm -s
  │
  ├─ Loaded services file OK.
  └─ [share] 認識成功
        ↓
smbd / nmbd 再起動
  │
  └─ 両方 active
        ↓
SambaのUFWプロファイル確認
  │
  ├─ 137,138/udp
  └─ 139,445/tcp
        ↓
ssで実際の待受状態を確認
  │
  ├─ nmbd: 137/138
  ├─ smbd: 139/445
  ├─ Docker bridge側でも待受を確認
  └─ smbdはIPv6側でも待受
        ↓
UFW変更前の状態を確認
  │
  └─ 192.168.11.0/24 → TCP/22のみ
        ↓
IPV6=yes を確認
        ↓
UFWをdry-run
  │
  └─ Samba用LAN限定ルールの内容を確認
        ↓
dry-run後の実ルールを再確認
  │
  └─ Sambaルールはまだ追加されていない
        ↓
Sambaを家庭内LANからのみ許可
  │
  └─ sudo ufw allow from 192.168.11.0/24 to any app Samba
        ↓
UFW最終確認
  │
  ├─ SSH: 192.168.11.0/24 → TCP/22
  └─ Samba: 192.168.11.0/24 → 137,138/udp + 139,445/tcp
        ↓
smbclient未導入を確認
        ↓
apt install --simulate smbclient
  │
  ├─ 新規1パッケージ
  ├─ アップグレード0
  └─ 削除0
        ↓
sudo apt install smbclient
  │
  └─ Version 4.19.5-Ubuntu
        ↓
LIFEBOOK自身から共有一覧を確認
  │
  ├─ honta認証成功
  ├─ share表示
  └─ SMB1 disabled と表示
        ↓
LIFEBOOK自身から [share] へ直接接続
  │
  └─ 一覧取得成功
        ↓
SMB経由の書き込み・削除テスト
  │
  ├─ samba-write-test.txt 作成成功
  └─ SMB経由で削除成功
        ↓
WindowsからTCP/445を確認
  │
  └─ TcpTestSucceeded : True
        ↓
Windows Explorerから初回接続
  │
  └─ 0x80004005 で失敗
        ↓
ネットワーク経路を再確認
  │
  ├─ TCP/445は到達済み
  └─ Sambaサーバー自身の接続も成功済み
        ↓
Windowsのnet useを確認
  │
  └─ 既存接続なし
        ↓
Sambaユーザーを明示して接続
  │
  └─ net use \\192.168.11.9\share /user:WORKGROUP\honta *
        ↓
net use成功
  │
  └─ 接続状態: OK
        ↓
Windows Explorerから再接続
  │
  └─ \\192.168.11.9\share を正常に表示
        ↓
Windowsからファイル作成
  │
  ├─ 読み取り成功
  └─ 追記成功
        ↓
LIFEBOOK側で同じ内容を確認
        ↓
Linux側permissionを確認
  │
  └─ 通常のテキストファイルが 0744
        ↓
Sambaの実効permission設定を確認
  │
  ├─ create mask = 0744
  ├─ force create mode = 0000
  ├─ store dos attributes = Yes
  └─ user.DOSATTRIB あり
        ↓
今回の用途では実行権限不要と判断
        ↓
[share] にpermission設定を追加
  │
  ├─ create mask = 0600
  └─ directory mask = 0700
        ↓
testparmで設定確認
        ↓
smbd / nmbd 再起動
        ↓
Windowsから新規ファイル・ディレクトリを作成
        ↓
LIFEBOOK側でpermission再確認
  │
  ├─ ファイル: 0600 honta:honta
  └─ ディレクトリ: 0700 honta:honta
        ↓
Windowsからテストデータを削除
        ↓
LIFEBOOK側でも共有ディレクトリが空であることを確認
        ↓
LIFEBOOKを再起動
        ↓
再起動後の状態を確認
  │
  ├─ smbd: active / enabled
  ├─ nmbd: active / enabled
  ├─ UFWルール維持
  ├─ [share]設定維持
  ├─ /srv/samba/share: 0700 honta:honta
  └─ Sambaユーザー honta 維持
        ↓
Windowsから再度TCP/445確認
  │
  └─ TcpTestSucceeded : True
        ↓
Windowsから共有を再参照
  │
  └─ エラーなし
        ↓
sudo smbstatus
  │
  ├─ Windows Client: 192.168.11.2
  ├─ User: honta
  ├─ Share: share
  ├─ Protocol: SMB3_11
  └─ Signing: AES-128-GMAC
        ↓
Windows側の永続接続を設定
  │
  └─ /persistent:yes + /savecred
        ↓
NET HELPMSG 3510
  │
  └─ 矛盾するスイッチ
        ↓
永続化と資格情報保存を分けて確認
        ↓
cmdkeyで192.168.11.9 / WORKGROUP\hontaを登録
        ↓
net use S: ... /persistent:yes
  │
  └─ 初回はユーザー名・パスワード入力が必要
        ↓
S:作成成功
        ↓
Windows再起動
  │
  └─ S: は残るが「切断」
        ↓
TCP/445を再確認
  │
  └─ TcpTestSucceeded : True
        ↓
Windows資格情報マネージャーへ登録
  │
  ├─ 192.168.11.9
  └─ WORKGROUP\honta
        ↓
S:を削除して作り直す
  │
  └─ net use S: \\192.168.11.9\share /persistent:yes
        ↓
Get-ChildItem S:\ 成功
        ↓
Windows再起動
        ↓
パスワード再入力なしでS:を開くことに成功
        ↓
Sambaファイルサーバー構築完了

今回特に重要だったのは、エラーや想定外の表示が出た時点で設定を緩めず、

現在状態を確認
  ↓
どこまで成功しているかを切り分ける
  ↓
公式仕様を確認する
  ↓
必要な箇所だけ変更する
  ↓
変更後に同じ観点で再検証する

という流れを維持したことでした。

その結果、SMB1やFirewallを不要に緩めることなく、家庭内LAN限定・認証必須・ファイル 0600 / ディレクトリ 0700 の構成で、Windowsから利用できるSambaファイルサーバーを構築できました。

まとめ

今回は、Ubuntu 24.04.4 LTSをインストールした古いLIFEBOOKへ Samba 4.19.5-Ubuntu を導入し、家庭内LAN上のWindows PCから利用できる認証付きファイルサーバーを構築しました。

単に apt install samba で終わらせず、

  • Samba導入前の実機状態確認
  • Ubuntu公式・Samba公式ドキュメントの確認
  • /srv/samba/share の作成
  • Sambaユーザー honta の登録
  • guest ok = no / valid users = honta による認証付き共有
  • UFWで 192.168.11.0/24 からのSamba通信だけを許可
  • LIFEBOOK自身から smbclient で共有・認証・読み書きを確認
  • WindowsからTCP/445の疎通を確認
  • Windowsからファイルの作成・読み取り・追記・削除を確認
  • LIFEBOOK再起動後もSamba・UFW・共有設定が維持されることを確認
  • smbstatus でWindowsからの実接続が SMB3_11 であることを確認
  • Windows側で S: の永続ネットワークドライブ化を検証
  • /persistent:yes だけでは再起動後に S: が「切断」状態になることを確認
  • Windows資格情報マネージャーへSamba資格情報を保存
  • S: を作り直し、Windows再起動後もパスワード再入力なしで開けることを確認

まで行いました。

今回特に重要だったのは、接続できない・想定外のpermissionになるといった事象が出ても、すぐにFirewallを無効化したりSMB1を有効化したりせず、どこまで正常に動いているかを順番に切り分けたことです。

Windowsエクスプローラーから最初に接続した際は、

0x80004005

で共有を開けませんでした。

しかし、

TCP/445への到達
  ↓
LIFEBOOK自身からのSamba接続
  ↓
Windowsの既存接続状態
  ↓
Sambaユーザーを明示したnet use

の順に確認し、

net use \\192.168.11.9\share /user:WORKGROUP\honta *

で認証すると接続に成功しました。

また、Windowsから作成した通常のテキストファイルが最初は、

-rwxr--r-- 744

になったため、Sambaの実効設定とextended attributeを確認しました。

今回の個人用共有では実行権限が不要だったため、

create mask = 0600
directory mask = 0700

を明示し、Windowsから新規作成したファイル・ディレクトリが実際に、

ファイル:
-rw------- 600 honta:honta

ディレクトリ:
drwx------ 700 honta:honta

になることまで再検証しました。

最終的な構成は次のとおりです。

Windows PC
192.168.11.2
  │
  │ SMB 3.1.1
  │ Sambaユーザー: honta
  ▼
家庭内LAN
192.168.11.0/24
  │
  ▼
UFW
  ├─ Default incoming: deny
  ├─ SSH:   192.168.11.0/24 → TCP/22
  └─ Samba: 192.168.11.0/24
              ├─ UDP/137
              ├─ UDP/138
              ├─ TCP/139
              └─ TCP/445
  │
  ▼
LIFEBOOK
Ubuntu 24.04.4 LTS Desktop
  │
  ├─ smbd: active / enabled
  ├─ nmbd: active / enabled
  │
  └─ /srv/samba/share
       ├─ owner: honta
       ├─ group: honta
       └─ mode: 0700

SMB1 disabled という表示もありましたが、最終的に smbstatus ではWindowsから、

Protocol Version: SMB3_11
Signing: AES-128-GMAC

で接続していることを実機で確認できました。

そのため、SMB1を有効化する設定は追加していません。

これで、メインPCの修理期間中も、LIFEBOOKをUbuntu開発機として利用しながら、Windowsから家庭内LAN経由でファイルを保管・共有でき、再起動後も S: ドライブからそのまま利用できる環境を用意できました。

古いPentium搭載のLIFEBOOKですが、SSH、Docker Engineに続いて、Sambaファイルサーバーとしても問題なく動作するところまで確認できました。

参考資料

今回の記事では、Ubuntu 24.04.4 LTS上でのSamba構築手順、Samba 4.19の設定仕様、UFW、Windows側のSMB接続確認について、主に以下の公式ドキュメントを参照しました。

Ubuntu公式：Set up Samba as a file server

確認内容:

  • samba パッケージのインストール方法
  • Sambaのメイン設定ファイルが /etc/samba/smb.conf であること
  • 共有セクションの基本構成
  • /srv/samba/share を使った共有例
  • browsable / guest ok / read only / create mask の設定例
  • smbd.service / nmbd.service の再起動
  • WindowsからIPアドレスを指定して共有へ接続する方法
  • Ubuntu公式の基本例はゲスト共有であり、より厳格なアクセス制御ではShare Access Controlsを参照すること

公式記載例:

The first step is to install the samba package.

The main Samba configuration file is located in /etc/samba/smb.conf.

Ubuntu公式：Share access controls

確認内容:

  • Linuxユーザーが自動的にSambaユーザーになるわけではないこと
  • 既存LinuxユーザーをSamba認証情報データベースへ追加する方法
  • sudo smbpasswd -a <ユーザー名> の使用方法
  • Samba用パスワードはLinuxログインパスワードと同じである必要がないこと
  • Samba側のアクセス制御だけでなく、Linuxファイルシステム側のpermission確認も必要であること

公式記載例:

All local Linux users that the system may have are not automatically available as Samba users.

Ubuntu公式：Firewall

確認内容:

  • UbuntuでのUFWの基本的な利用方法
  • ufw app list によるアプリケーションプロファイル一覧確認
  • ufw app info Samba によるSambaプロファイル確認
  • UFWのアプリケーションプロファイルには必要なport / protocol情報が含まれること
  • 特定のネットワークからだけSambaを許可する拡張構文

公式記載例:

ufw allow from 192.168.0.0/24 to any app Samba

今回の環境では家庭内LANが 192.168.11.0/24 だったため、実機確認したサブネットへ置き換えて設定しました。

Ubuntu公式 man page：ufw(8)

確認内容:

  • Ubuntu 24.04 LTS（noble）のUFW man page
  • --dry-run の動作
  • status numbered / status verbose
  • 送信元アドレスを限定するルール構文
  • UFW application integration
  • IPv6 Firewallを使用する場合の /etc/default/ufw の扱い

公式記載:

don't modify anything, just show the changes

今回 --dry-run 実行時に「ルールをアップデートしました」と表示されたため、実際の ufw status numbered も確認し、ルールが変更されていないことを実機で確認しました。

Samba公式：smb.conf(5) — Samba 4.19

確認内容:

  • smb.conf の構成とshare section
  • Samba側のアクセス権がLinuxファイルシステム側の権限を超えないこと
  • guest ok
  • valid users
  • browsable
  • read only
  • create mask
  • directory mask
  • force create mode
  • store dos attributes
  • map archive
  • usershare allow guests
  • server min protocol
  • server max protocol
  • SMB protocol levelとしての NT1 / SMB2_02 / SMB3_11 など

今回特に確認したデフォルト値:

create mask = 0744

Windowsから作成したテキストファイルが実機で 0744 になったため、設定値と実際のpermissionを確認した上で、今回の個人用共有では、

create mask = 0600
directory mask = 0700

を明示しました。

また、store dos attributes = yes の場合にDOS属性をextended attributeへ保存する仕様を確認し、実ファイルでも user.DOSATTRIB が存在することを確認しました。

Samba公式：testparm(1) — Samba 4.19

確認内容:

  • smb.conf の内部的な整合性確認
  • 設定ファイルを正常に読み込めるかの確認
  • -s / --suppress-prompt
  • 特定share・parameterの実効値確認
  • testparm が成功しても、共有サービスが実際に利用可能であることまで保証するものではないこと

公式記載例:

check an smb.conf configuration file for internal correctness

今回の記事では testparm -s と実際のSMB接続テストを分けて確認しました。

Samba公式：smbclient(1) — Samba 4.19

確認内容:

  • SMB/CIFSサーバーへ接続するクライアントツールであること
  • -L による共有一覧取得
  • -U によるSambaユーザー指定
  • //server/share 形式での共有接続
  • ファイルの取得・送信・一覧取得
  • -c によるコマンド実行
  • パスワードをコマンドラインへ直接含めず、対話入力する方法
  • NT1 がSMB1系を指定する際に使用されること

公式記載例:

smbclient is a client that can 'talk' to an SMB/CIFS server.

今回の記事では、Windowsから接続する前にLIFEBOOK自身から smbclient を使い、共有一覧・認証・読み書き・削除まで確認しました。

Samba公式：smbstatus(1) — Samba 4.19

確認内容:

  • 現在のSamba接続を確認するためのツールであること
  • 接続ユーザー
  • クライアント
  • 利用中のshare
  • Protocol Version
  • Encryption
  • Signing

公式記載:

smbstatus is a very simple program to list the current Samba connections.

今回の実機ではWindows PC 192.168.11.2 から、

Username         honta
Service          share
Protocol Version SMB3_11
Signing          AES-128-GMAC

で接続していることを確認しました。

Linux Foundation：Filesystem Hierarchy Standard 3.0

確認内容:

  • /srv の目的
  • /srv が、このシステムによって提供されるサービス固有データを置くための階層として定義されていること

公式記載:

/srv contains site-specific data which is served by this system.

今回の共有ディレクトリはUbuntu公式のSamba例にも合わせ、

/srv/samba/share

へ配置しました。

Microsoft Learn：Windows および Windows Server の SMB ファイル共有とは

確認内容:

  • SMBがネットワークファイル共有プロトコルであること
  • SMBを使用してネットワーク経由でファイルを読み書きできること
  • SMB1 / SMB2 / SMB3はファイルシステムではなくSMB protocolの世代・dialectであること
  • Windows 11が対象に含まれていること

公式記載:

SMB プロトコルは、ネットワーク ファイル共有プロトコルです。

今回の記事では、LIFEBOOK側のファイルシステム ext4 と、ネットワーク共有に使用するSMB protocolを区別して説明しました。

Microsoft Learn：Test-NetConnection

確認内容:

  • Windowsから指定ホスト・TCP portへの接続確認
  • -ComputerName
  • -Port
  • TcpTestSucceeded

今回の記事では、

Test-NetConnection -ComputerName 192.168.11.9 -Port 445

を使用し、WindowsからLIFEBOOKのTCP/445へ到達できることを確認しました。

Microsoft Learn：Net use

確認内容:

  • Windowsから共有リソースへ接続する net use
  • \\ComputerName\ShareName 形式
  • /user: による接続ユーザー指定
  • * によるパスワードの対話入力
  • net use 単独で現在の接続一覧を確認できること
  • ドライブ文字の割り当て
  • /persistent:yes による永続ネットワーク接続

今回の記事では、

net use \\192.168.11.9\share /user:WORKGROUP\honta *

を使用し、パスワードをコマンドラインへ直接記載せずにSambaユーザーを明示して接続しました。

この net use ページはMicrosoft Learn上の旧Windows Server向けドキュメントですが、今回使用した構文の確認元として参照しています。

実際の動作については、今回のWindows環境でコマンドが正常終了し、net use の接続状態が OK になることを実機確認しています。

Microsoft Support：Windows の資格情報マネージャー

確認内容:

  • Windows 11 / Windows 10の資格情報マネージャー
  • Webサイト、接続したアプリケーション、ネットワークへのサインイン用として保存した資格情報を管理できること
  • Windows 資格情報 からネットワーク用の資格情報を管理する操作

今回の記事では、Sambaサーバー 192.168.11.9 に対する WORKGROUP\honta の資格情報をWindows資格情報マネージャーへ保存し、S: ドライブを作り直したあと、Windows再起動後もパスワード再入力なしで共有を開けることを実機確認しました。

Microsoft Learn：Set-Content

確認内容:

  • PowerShellから指定ファイルへ内容を書き込む方法
  • -Path
  • -Value
  • -Encoding

今回の記事では、WindowsからSamba共有上へテストファイルを新規作成するために使用しました。

Microsoft Learn：Add-Content

確認内容:

  • PowerShellから既存ファイルへ内容を追記する方法
  • -Path
  • -Value
  • -Encoding

今回の記事では、WindowsからSamba共有上のテストファイルへ2行目を追記し、書き込み可能であることを確認しました。

Microsoft Learn：Remove-Item

確認内容:

  • PowerShellからファイル・ディレクトリを削除する方法
  • Samba共有上のテストファイル・テストディレクトリの削除

今回の記事では、動作確認後のテストデータをWindows側から削除し、LIFEBOOK側でも削除済みであることを確認しました。

関連記事

このシリーズ

あわせて読みたい

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?