Linux環境でのSambaサーバー構築と設定：Windowsネットワーク向けファイル共有とアクセス権限の完全ガイド - ITFROMZERO - Share tobe shared! Linux上でWindows向けにセキュアなファイル共有を実現するSambaサーバーの構築手順を詳しく解説。2層のアクセス権限の仕組み、実践的な設定ファイルの記述例、Permission Deniedエラーを解消するWindows側のキャッシュクリア手順まで網羅しています。

Table of Contents

オフィスの現場で直面する課題：LinuxとWindows間のファイル共有の壁

20〜100名規模の企業では、オフィスのクライアントPCの多くがWindows 10や11を採用しています。一方で、ストレージサーバー（ファイルサーバーやNAS）にはUbuntu、Debian、Rocky LinuxなどのLinuxが選ばれるケースが一般的です。その理由は明確で、Windows Serverの高額なライセンス費用を大幅に削減できるうえ、Linuxサーバーは安定性が高く、再起動を必要とすることがほとんどないからです。

しかし、社内文書の共有を始めるとすぐに問題が生じます。チャットツールやUSBメモリ経由でのファイル受け渡しは、情報漏洩やマルウェア感染のリスクを高めます。かといってWindowsからアクセスできるLinuxファイルサーバーを構築しても、システム管理者（SysAdmin）のもとにはトラブルの問い合わせが相次ぎます。「サーバーが表示されない」「Windowsで“Windows cannot access… Permission Denied”（アクセスできません）とエラーが出る」、さらには「誰でも社内の給与明細ファイルを閲覧・削除できてしまう」といった深刻なトラブルまで発生しかねません。

原因はシンプルです。Windowsはネットワーク共有にSMB（Server Message Block）プロトコルを使用しているのに対し、LinuxはPOSIX標準に基づいてファイルアクセス権限を管理しています。この異なる2つのプラットフォームをスムーズに連携させるため、長年にわたり最も標準的かつ信頼されているソリューションがSambaです。

仕組みの正しい理解：Sambaにおける2層の独立したアクセス権限

SambaはLinux上でSMB/CIFSプロトコルを実装したソフトウェアです。これにより、Linuxサーバーを本格的なWindowsファイルサーバーのように動作させることができます。Windowsユーザーは追加のツールを導入することなく、使い慣れた操作感でフォルダの参照、読み書き、ネットワークドライブの割り当て（Map Network Drive）を行えます。

2つのセキュリティレイヤー：smb.confとLinuxファイルシステム

Sambaの設定を始めたばかりの人が陥りがちなのが、「smb.confファイルで権限を指定するだけで十分」という思い込みです。これはPermission Deniedエラーを引き起こす最も典型的な原因です。

実際には、Sambaは完全に独立した2つの制御レイヤーに基づいて動作しています：

レイヤー1 – Samba設定（smb.conf）： 誰に共有フォルダを表示するか、誰に書き込みを許可するか（read only = no、write list）、誰を読み取り専用にするかを制御します。
レイヤー2 – Linuxファイル権限（chmod / chown）： プロセスを実行するLinuxユーザーが、ディスク上の物理ディレクトリに対して実際にアクセス権を持っているかを制御します。

絶対的な原則として、Sambaの権限設定がLinuxのファイル権限を上書きすることはありません。たとえば、smb.confで書き込みを許可（read only = no）していても、Linux側のディレクトリ権限がroot所有の755のままであれば、Windowsユーザーがファイルを書き込もうとしても即座にブロックされます。

LinuxユーザーとSambaユーザーの関係性

すべてのSambaアカウントは、既存のLinuxアカウントに紐付いている必要があります。Linux側でユーザーを作成した後、smbpasswdコマンドを使用してそのユーザーをSamba独自のデータベースに同期します。両アカウントは同一のユーザー名を共有しますが、ネットワーク共有アクセス用のパスワードはLinuxのログインパスワードと別個に設定することが可能です。

実践：UbuntuでのSambaサーバーのインストールと設定

ここでは、Ubuntu Server（IPアドレス：192.168.1.100）上でSambaを設定し、企業でよくある以下の2つのシナリオを解決していきます：

共有フォルダ（Public）： 全社員がお知らせや共通テンプレートを閲覧可能。書き込み・編集権限は管理者のみ。
経理部門フォルダ（KeToan）： 経理部門の担当者のみがアクセス可能で、数値データのすべての操作権限を保持。

ステップ1：Sambaのインストール

パッケージリストを更新し、Sambaおよび検証用クライアントツールをインストールします：

sudo apt update
sudo apt install samba smbclient -y

サービスが正常に起動していることを確認します：

sudo systemctl status smbd

ステップ2：ユーザーグループの作成とLinuxディレクトリの権限設定

ketoan_deptグループを作成し、経理担当のlan_ktと営業担当のtuan_nvユーザーを作成します。セキュリティ向上のため、ターミナルへの直接ログインシェルは無効化（-s /usr/sbin/nologin）しておきます：

# 部門用グループの作成
sudo groupadd ketoan_dept

# ターミナルログイン不要のシステムユーザーを作成
sudo useradd -M -s /usr/sbin/nologin -g ketoan_dept lan_kt
sudo useradd -M -s /usr/sbin/nologin tuan_nv

/samba配下にストレージ用のディレクトリツリーを作成し、適切な権限を設定します：

sudo mkdir -p /samba/public
sudo mkdir -p /samba/ketoan

# パブリックフォルダ：全員が読み取り可能（755）、rootのみ書き込み可能
sudo chown -R root:nogroup /samba/public
sudo chmod -R 755 /samba/public

# 経理フォルダ：ketoan_deptグループ所属ユーザーのみアクセス可能（770）
sudo chown -R root:ketoan_dept /samba/ketoan
sudo chmod -R 770 /samba/ketoan

# SGIDビットを有効化：新規作成されたファイルが自動的にketoan_deptグループを継承
sudo chmod g+s /samba/ketoan

chmod g+sコマンドは非常に重要です。このSetGIDフラグにより、以降lan_ktが新規作成したすべてのファイルが自動的にketoan_deptグループを継承します。そのため、同部門内の他の経理担当者も問題なくファイルを開いて編集できるようになります。

ステップ3：Sambaユーザーのパスワード設定

各アカウントのネットワークアクセス用パスワードを設定・有効化します：

# lan_kt（経理部門）のSambaパスワードを設定
sudo smbpasswd -a lan_kt
sudo smbpasswd -e lan_kt

# tuan_nv（一般社員）のSambaパスワードを設定
sudo smbpasswd -a tuan_nv
sudo smbpasswd -e tuan_nv

ステップ4：本番環境向けのsmb.conf設定

設定ファイルを編集する前に、必ず元の設定のバックアップを取得しておきます：

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak

/etc/samba/smb.confを開き、末尾に以下の設定を追記します：

# --- グローバル設定（Global） ---
[global]
   workgroup = WORKGROUP
   server string = Ubuntu File Server
   security = user
   map to guest = bad user
   dns proxy = no

   # 古く安全性の低いSMBv1プロトコルを無効化
   server min protocol = SMB2_10
   client min protocol = SMB2_10

# --- 共有フォルダ（Public） ---
[Public_Data]
   path = /samba/public
   browseable = yes
   read only = yes
   guest ok = yes
   create mask = 0644
   directory mask = 0755

# --- 経理部門フォルダ（機密） ---
[KeToan_Secret]
   path = /samba/ketoan
   browseable = yes
   read only = no
   valid users = @ketoan_dept
   force group = ketoan_dept
   create mask = 0660
   directory mask = 0770

server min protocol = SMB2_10を指定することで、SMBv1を完全に排除できます。この設定はWannaCryなどのランサムウェア感染拡大リスクを抑止するだけでなく、ギガビットネットワーク環境での安定したファイル転送速度の維持にも貢献します。

ステップ5：構文チェックとサービスの再起動

設定を反映する前に、testparmコマンドを実行して構文エラーや記述ミスをチェックします：

testparm

ターミナルに“Loaded services file OK”と表示されたら、サービスを再起動して設定を反映させます：

sudo systemctl restart smbd
sudo systemctl enable smbd

ステップ6：UFWファイアウォールの設定

セキュリティ確保のため、SMBポート（ダイレクトホスティング用ポート445およびNetBIOS用ポート139）へのアクセスをオフィスの社内ネットワークセグメント（例：192.168.1.0/24）のみに制限して開放します：

sudo ufw allow from 192.168.1.0/24 to any port 445 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 139 proto tcp
sudo ufw reload

ステップ7：Windowsからのアクセス確認と認証情報のキャッシュクリア

LAN内のWindowsクライアントPCから以下を実行します：

Windows + Rキーを押し、\\192.168.1.100と入力してEnterキーを押します。
Public_DataとKeToan_Secretの2つのフォルダが表示されます。
KeToan_Secretを開き、ステップ3で設定したユーザーlan_ktの認証情報を入力します。

よくある落とし穴： Windowsは接続セッションの認証情報をキャッシュします（Credential Caching）。誤って先にtuan_nvユーザーで認証してしまうと、経理フォルダを開こうとした際に新たなパスワード入力プロンプトが表示されず、即座にアクセス権エラーとなってしまいます。

既存のログインセッションを完全にクリアして再接続するには、Windowsでコマンドプロンプト（CMD）を開き、次のコマンドを実行します：

net use * /delete /y

まとめ

LinuxとWindows間のファイル共有は、Linuxのファイル権限（chmod/chown）とSambaの共有権限（smb.conf）という「2層のアクセス権限モデル」さえ正しく理解していれば決して難しくありません。この2つのセキュリティレイヤーを適切に同期させることで、アクセス権が明確で安定したファイルサーバーを運用でき、IT部門の日々のトラブル対応負担を劇的に軽減できます。