DockerとSambaを使って、安全なネットワーク ストレージを作りましょう。
マイクロソフトの援助もあって、sambaは洗練され、Windowsとの互換性を高めています。
アクセスコントロールについては、まずPOSIX ACLで設定してみます。
次にWindows NTFS完全互換のアクセスコントロールに変更します。
Dockerのインストールと、使用するイメージやネットワークは、前回の記事を参照してください。
コンテナの作成
前回ビルドしたdebian.protoイメージを使って、sambaサーバーを作ります。
コンテナ名は「folders」にします。
データ保存ボリュームの準備
ホスト上に、foldersコンテナがデータを保存する「FOLDERS」ディレクトリを作成します。
ホストの /v ディレクトリーは「RAID1」で冗長化されています。
ここに「FOLDERS」ディレクトリを作れば安全です。
fumi@y3:~$ sudo mkdir /v/FOLDERSdebianコンテナ作成
基本システムのみの「debianコンテナ」を作成します。
docker run \
--name=folders \
--hostname=folders \
--network=private-net \
--ip=192.168.11.10 \
--volume=/v/FOLDERS:/srv \
--detach=true \
debian.protoコンテナ作成は完了です。
この意味は、次の通りです。
| docker run | コンテナを作ります。 |
| –name=folders | コンテナに folders という名前を付けます。 |
| –hostname=folders | コンテナの hostname に folders を設定します。 |
| –network=private-net | private-net ネットワークに接続します。 |
| –ip=192.168.11.10 | ipアドレスを 192.168.11.10 に設定します。 |
| –volume=/v/FOLDERS:/srv | ホストの /v/FOLDERS を コンテナの /srv に対応させます。 |
| –detach=true | デタッチ モードで起動します。 |
| debian.proto | debian.proto イメージを使ってコンテナを作ります。 |
今回新しいオプションが出てきました。
「–volume=/v/FOLDERS:/srv」は、永続データを保存場所を指定するオプションです。
ホストの「/v/FOLDERS」ディレクトリーが、コンテナの「/srv」ディレクトリーにバインドされます。
コンテナが「/srv」に書き込みすると、ホストの「/v/FOLDERS」に書き込まれます。
sambaのインストール
コンテナにsambaをインストールします。
コンテナが起動しているかを確認してみます。
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e37f6add81cc debian.proto "/startup.sh" 6 seconds ago Up 5 seconds folders
4d8392d46f6f debian.proto "/startup.sh" 4 days ago Up 3 days dns0
「foldersコンテナ」が起動していることを確認しました。
「foldersコンテナ」に入ります。
docker exec -it folders bash起動しているプロセスを確認します。
root@folders:/# ps -A
PID TTY TIME CMD
1 ? 00:00:00 bash
8 ? 00:00:00 tail
9 pts/0 00:00:00 bash
16 pts/0 00:00:00 ps「bash」とコンテナを永続させるための「tail」のみが起動しています。
sambaをインストールします。
root@folders:/# apt -y install samba
sambaの「設定ファイル」を作ります。
catとヒアドキュメントで書き込むとき、「タブは通らない」ので、スペースに替えてください。
cat <<'EOF' > /etc/samba/smb.conf
[global]
dos charset = CP932
server string = ネットワークストレージ
map to guest = Bad User
dns proxy = No
idmap config * : backend = tdb
acl group control = No
acl map full control = No
acl allow execute always = No
local master = No
os level = 0
domain master = No
preferred master = No
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
[ストレージ１]
path = /srv/S1
read only = No
create mask = 0644
force create mode = 0644
directory mask = 0755
force directory mode = 0755
guest ok = No
EOFviで編集してもOKです。
root@folders:/# vi /etc/samba/smb.conf設定ファイルの内容は以下の通りです。
[global]
dos charset = CP932
server string = ネットワークストレージ
map to guest = Bad User
dns proxy = No
idmap config * : backend = tdb
acl group control = No
acl map full control = No
acl allow execute always = No
local master = No
os level = 0
domain master = No
preferred master = No
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
[ストレージ１]
path = /srv/S1
read only = No
create mask = 0644
force create mode = 0644
directory mask = 0755
force directory mode = 0755
guest ok = No設定内容は次の通りです。
| [global] | ここから、次の [] までが、samba 全体の設定です。 |
| [ストレージ１] | フォルダの名前です。 ここから次の [] までが、このフォルダについての設定です。 |
省エネルギーのハードウエアを使う場合、リソースの浪費は禁物です。
[global]エリアで、sambaで自動的に起動する「lpqd プロセスの起動を抑制」しています。
プリントサーバーをこのコンテナで使う場合は、以下を「コメント化」してください。
# load printers = no
# printing = bsd
# printcap name = /dev/null
# disable spoolss = yesフォルダの設定は、[]に挟まれた、「フォルダの名前」から始まります。
「path = /srv/S1」でフォルダの名前「ストレージ１」とLinuxのディレクトリー「/srv/S1」を結びつけます。
そのほかは、ファイル保存時のアクセス許可設定です。
ただし、ここでは拡張属性を使ったアクセスコントロールは使いません。
共有ストレージではなく、ユーザー単位のネットワーク ストレージです。
この設定では、「sambaユーザーのアクセス権限」は「Linuxユーザーのパーミション」によって決まります。
各設定の詳細は、「smb.conf」のマニュアルを参照してください。
「testparm」で、設定に文法ミスがないか確認します。
root@folders:/# testparm間違ったパラメーターやWARNINGがあれば、修正してください。
ユーザーを作る
今回のsambaの設定では、「Linuxのローカルユーザー」と「sambaのユーザー」がリンクしています。
同名の「Linuxのローカルユーザー」がなければ、「sambaのユーザー」を作ことはできません。
この設定では「Linuxユーザーのパスワード」と「sambaユーザーのパスワード」は同期しません。
Linuxユーザーのパスワードは設定しなくてもOKです。
homeディレクトリも必要ありません。
ここではユーザーとして「fumi」を設定します。
Linuxユーザー「fumi」を作ります。
root@folders:/# useradd fumi次にsambaユーザーを作ります。
root@folders:/# pdbedit -a fumiパスワードの設定を促されますので、任意に設定してください。
以下のように作成したユーザー情報が出力されます。
new password:
retype new password:
Unix username: fumi
NT username:
Account Flags: [U ]
User SID: S-1-5-21-2460080139-991547097-4264342129-1000
Primary Group SID: S-1-5-21-2460080139-991547097-4264342129-513
Full Name:
Home Directory: \\folders\fumi
HomeDir Drive:
Logon Script:
Profile Path: \\folders\fumi\profile
Domain: FOLDERS
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: 木, 07 2月 2036 00:06:39 JST
Kickoff time: 木, 07 2月 2036 00:06:39 JST
Password last set: 水, 30 6月 2021 09:08:44 JST
Password can change: 水, 30 6月 2021 09:08:44 JST
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFsambaのユーザーが作成されました。
Windowsなどのパソコンから、このネットワーク ストレージにアクセスする場合には、「sambaユーザー」と「パスワード」でアクセスします。
共有フォルダー用のディレクトリを作る
「smb.conf」の設定で「ストレージ１」フォルダを「/srv/S1」にリンクさせました。
「ストレージ１」に保存したデータは、コンテナの「/srv/S1」に保存されます。
コンテナに「/srv/S1」を作ります。
root@folders:/# mkdir /srv/S1
sambaユーザーのアクセス権は、linuxユーザーのパーミションで決まります。
sambaで「fumi」が「ストレージ１」にアクセスできるように、Linuxユーザー「fumi」を「/srv/S1」の所有者にして、アクセス全権を与えます。
root@folders:/# chown fumi /srv/S1
設定完了です。
sambaを起動する
sambaを起動します。
sambaには「nmbd」、「smbd」、「samba-ad-dc」が含まれていますが、ネットワーク ストレージに必要なのは「smbd」だけです。
「smbd」のみの起動で、今回の目的は達成されます。
root@folders:/# /etc/init.d/smbd start
プロセスを確認してみます。
root@folders:/# ps -A
PID TTY TIME CMD
1 ? 00:00:00 bash
15 ? 00:00:00 smbd
16 ? 00:00:00 tail
18 ? 00:00:00 smbd-notifyd
19 ? 00:00:00 cleanupd
20 pts/0 00:00:00 bash
28 pts/0 00:00:00 ps「smbd」が起動しています。
コンテナの起動と共に、smbdを立ち上げるために、「startup.sh」に起動スクリプトを追加しておきます。
root@folders:/# sed -i '1a /etc/init.d/smbd start' /startup.shviでstartup.shを編集してもいOKです。
startup.shは以下のようになります。
#!/usr/bin/env bash
/etc/init.d/smbd start
tail -f /dev/null
Windowsからアクセスする
foldersコンテナを使ってみましょう。
Windows10から、ネットワーク ストレージにアクセスして、パソコンにあるデータをバックアップしてみましょう。
foldersコンテナの「ipアドレス」は「192.168.11.10」に設定しました。
① Windows10の検索ボックスに「\\192.168.11.10」を入力します。
最初の「\\」はネットワーク上のサーバーにアクセスするときに使う「おまじない」です。
② 「開く」をクリックします。
開いたウインドウに「ストレージ１」フォルダが表示されます。
資格情報を入力してフォルダーにつなぐ
現在「Windowsにサインインしているユーザー」と、「foldersコンテナで『ストレージ１』フォルダにアクセス権を設定したsambaユーザー」が異なる場合は、接続時に資格情報を求められます。
「ストレージ１」をダブルクリックすると、資格情報の入力ダイアログがポップアップします。
sambaユーザー「fumi」と先ほど設定した「パスワード」を入力します。
「資格情報を記憶する」にチェックしておくことで、以後の資格情報の入力を省略することができます。
資格情報が承認され、フォルダーが開きます。
資格情報を入力しないでフォルダーにつなぐ
現在Windowsにサインインしているユーザーが、sambaユーザーと同じ「fumi」で、パスワードも同じである場合は、あらためて認証情報は求められません。
Windowsとsambaのユーザーを同じにしておけば、Windowsへのサインインでsambaの認証も済ませることができます。
ただし、Windowsのパスワードを変更すると、sambaとパスワードが異なることになり、認証情報の入力が再現します。
ローカル ファイルを転送する
Windowsパソコンのローカルディスク データをファイルサーバーに転送してみます。
ここに、「バックアップ」フォルダを新規作成します。
ウインドウ内に表示された「このフォルダーはからです。」の下あたりを「右クリック」します。
「新規作成(X)」→「フォルダー(F)」で、フォルダを作成します。
foldersコンテナの「/srv/S1」ディレクトリーのパーミションが「fumi」ユーザーに対して正しく設定されていれば、フォルダを作成することができます。
設定が間違っていると、次のように警告が表示されます。
コンテナの「/srv/S1」ディレクトリーのパーミションを確認してください。
「新しいフォルダー」ができたら、フォルダ名を「バックアップ」に変更します。
下記では、「ピクチャ」ホルダをバックアップしています。
Windows10では、「ドラッグ＆ドロップ」すると「バックアップ」フォルダに「ショートカット」ができるだけなので、「コピー＆ペースト」でバックアップを行ってください。
Windowsのアクセス権限とコンテナ上のパーミション
sambaの使い方は様々です。
Windowsに準拠した拡張属性を使用することもできます。
POSIXに従ったUNIX互換のACLで使用することもできます。
「Windowsから見たアクセス権限」は、「ソフトウエアsambaのアクセス権」です。
今回の設定では、「sambaのアクセス権」は、「コンテナのLinuxのパーミション」です。
Windowsからsambaを経由して、コンテナにフォルダやファイルを保存するとき、どのような権限が設定されるかは、「smb.conf」に依存します。
今回は下記のように設定しました。
create mask = 0644
force create mode = 0644
directory mask = 0755
force directory mode = 0755これは、Windowsから書き込まれたデータが、この設定に従って、コンテナ上のLinuxパーミションに変換されます。
コンテナ上のパーミション
「smb.conf」が指示するファイルとディレクトリー作成時の権限付与は以下の通りです。
| 作成者 | グループ | それ以外 | |
| ファイル | 書込・削除/読取 | 読取 | 読取 |
| ディレクトリー | 書込・削除/実行/読取 | 実行/読取 | 実行/読取 |
先ほどWindowsから作成した「バックアップ」フォルダのコンテナ上のパーミションを表示すると、次のようになっています。
root@folders:/# ls -l /srv/S1/
合計 0
drwxr-xr-x 3 fumi fumi 26 7月 1 18:46 バックアップ
root@folders:/# ls -l /srv/S1/バックアップ/ピクチャ/
合計 21720
-rw-r--r-- 1 fumi fumi 64936 12月 13 2020 'コメント 2020-12-13 091110.png'
-rw-r--r-- 1 fumi fumi 64936 12月 13 2020 'コメント 2020-12-13 091311.png'
-rw-r--r-- 1 fumi fumi 324117 12月 13 2020 'コメント 2020-12-13 091339.png'
-rw-r--r-- 1 fumi fumi 321975 12月 13 2020 'コメント 2020-12-13 091407.png'
-rw-r--r-- 1 fumi fumi 13877 12月 13 2020 'コメント 2020-12-13 091450.png'
-rw-r--r-- 1 fumi fumi 341531 12月 13 2020 'コメント 2020-12-13 091519.png'
-rw-r--r-- 1 fumi fumi 380106 12月 13 2020 'コメント 2020-12-13 091635.png'
-rw-r--r-- 1 fumi fumi 322974 12月 13 2020 'コメント 2020-12-13 091705.png'
-rw-r--r-- 1 fumi fumi 332191 12月 13 2020 'コメント 2020-12-13 091728.png'
-rw-r--r-- 1 fumi fumi 38349 12月 13 2020 'コメント 2020-12-13 091810.png'
-rw-r--r-- 1 fumi fumi 17533 12月 13 2020 'コメント 2020-12-13 091833.png'
-rw-r--r-- 1 fumi fumi 20174 12月 13 2020 'コメント 2020-12-13 092323.png'
...「smb.conf」の設定どおりにディレクトリーとファイルが作成されていることが確認できます。
Windowsから見たアクセス権限
Windowsから見ると、作成したフォルダやファイルは、下記のように設定されます。
| ファイル / フォルダー | 作成者 | グループ | それ以外 |
|---|---|---|---|
| ファイル | 特殊 | 読み取り | 読み取り |
| フォルダー | 特殊 | 読み取りと実行 | 読み取りと実行 |
Linux（unix）のパーミションをWindowsはどのように表現するのでしょうか。
先ほどバックアップしたファイルの「プロパティ」から「セキュリティ」の内容を見てみましょう。
所有者「fumi」の「特殊」アクセス権の内容は、次のようなものです。
コンテナ上のLinuxパーミションを「そのまま」表示しています。
「smb.conf」の設定で、「ストレージ１」フォルダーに保存するファイルの実行権限は付与しませんでした。
設定どおりなら、「ストレージ１」フォルダーに保存したEXEファイルは実行できないはずです。
「ストレージ１」フォルダーに保存したEXEファイルを「ダブルクリック」すると、次のように警告されます。
WindowsからEXEファイルに実行権限を付与することができます。
実行権限を付けることで、プログラムの実行が可能になります。
今度は「バックアップ」フォルダーのアクセス権です。
ユーザー「fumi」に付与された「特殊」権限の内容は以下です。
フォルダーも、コンテナ上のLinuxパーミションを「そのまま」表示しています。
Windowsから変更したアクセス権の妙
WindowsからLinuxのパーミションを変更することができました。
Windowsから、このネットワーク ストレージ上のファイルのアクセス権を変更することは、WindowsでLinuxのパーミションを変更することにほかなりません。
foldersコンテナでLinux上のパーミションを確認すると、以下の通りでした。
変更前です。
root@folders:/# ls -l /srv/S1/バックアップ/netenum20210527
合計 4092
...
-rw-r--r-- 1 fumi fumi 2257920 5月 26 20:19 netenum5.exe
...変更後です。
root@folders:/# ls -l /srv/S1/バックアップ/netenum20210527
合計 4092
...
-rwxrwxr--+ 1 fumi fumi 2257920 5月 26 20:19 netenum5.exe
...Linux 上で、ファイルに実行権限「x」が付いていることがわかります。
ユーザーだけでなくグループにも実行権限が付与されています。
「+」が付いているのは、POSIXのACLが付与されたことを示しています。
再び、Windowsから実行権限を削除してみます。
削除後です。
root@folders:/# ls -l /srv/S1/バックアップ/netenum20210527
合計 4092
...
-rw-rwxr--+ 1 fumi fumi 2257920 5月 26 20:19 netenum5.exe
...ユーザーの実行権限はなくなりましたが、グループの権限はそのままです。
POSIXのACL情報が変更されているかもしれません。
getfacl コマンドでACLを表示してみます。
root@folders:/# getfacl /srv/S1/バックアップ/netenum20210527/netenum5.exe
getfacl: Removing leading '/' from absolute path names
# file: srv/S1/バックアップ/netenum20210527/netenum5.exe
# owner: fumi
# group: fumi
user::rw-
user:fumi:rw-
group::r--
group:fumi:r--
mask::rwx
other::r--
グループの実行権限は削除されているのが確認できます。
互換性のないWindowsとLinuxのアクセス権限を、sambaがどのように扱っているのかは、微妙なところです。
「ユーザー単位」のネットワーク ストレージが目的であれば、問題はないかもしれません。
ただし、この設定では、思うようにWindowsからの権限設定ができません。
複数のユーザーでファイルを共有するような使い方をする場合は、トラブルになることが想像できます。
vfs_acl_xattr VFSモジュールが導入される以前は、このようなトラブルを避けながらファイルサーバーを運用するには、ひと工夫が必要でした。
一般的なパーミションの概要は下記をご参照ください。
名前でアクセスできるようにする
先ほどはfoldersコンテナにipアドレス「192.168.11.10」でアクセスしました。
Windowsホストと同じように「エクスプローラーのネットワーク」に表示されて、「名前でアクセス」できると利便性が高まります。
WDSで名前解決
以前のWindowsはNetBIOSによってネットワーク上のホスト検索をしていましたが、最近のWindows10ではWSDによって名前解決を行います。
なので上記の設定ではNetBIOSを有効にせず、nmbdデーモンを起動しませんでした。
「foldes」コンテナにWDSをインストールしたいのですが、Debianにはパッケージがありません。
Pythonで作られたWDSがあるので、これをインストールします。
umi@y3:~$ docker exec -it folders bash
root@folders:/# apt -y install wget python3
root@folders:/# wget https://raw.githubusercontent.com/christgau/wsdd/master/src/wsdd.py
root@folders:/# mv wsdd.py /usr/local/bin/
root@folders:/# chmod u+x /usr/local/bin/wsdd.pyWDSサーバーのインストール完了です。
起動します。
/usr/local/bin/wsdd.py -d WORKGROUP &コンテナの起動と共にWDSを起動するために、「エントリーポイント」に登録します。
root@folders:/# sed -i '1a /usr/local/bin/wsdd.py -d WORKGROUP &' /startup.shこれで、Windows10の「エクスプローラーのネットワーク」に「foldes」が表示されます。
WSDによって検索されているかを確認するには「エクスプローラー」左側のペインで［ネットワーク］をクリックして、「表示」タブで表示形式「詳細」を選択します。
「項目の行」を右クリックして、プルダウンリストから［探索方法］にチェックを入れます。
「folders」の「探索方法」列に「WDS」が確認できます。
ｍDNSで名前解決
マッキントッシュからもアクセスする場合は、mDNSを入れておきます。
最近のWindows10はmDNSにも対応しています。
対応以前のWindowsには、AppleのBonjourをインストールすることで対応できます。
ただし、mDNSで「folders → 192.168.11.10」の解決はできますが「エクスプローラーのネットワーク」には表示されません。
次の手順でmDNSを有効にできます。
root@folders:/# apt -y install dbus avahi-daemon
root@folders:/# /etc/init.d/dbus start
root@folders:/# /etc/init.d/avahi-daemon start「エントリーポイント」に登録します。
root@folders:/# sed -i '1a /etc/init.d/dbus start && /etc/init.d/avahi-daemon start' /startup.sh「startup.sh」は以下のようになります。
#!/usr/bin/env bash
/etc/init.d/dbus start && /etc/init.d/avahi-daemon start
/usr/local/bin/wsdd.py -d WORKGROUP &
/etc/init.d/smbd start
tail -f /dev/nullそのほかの名前解決
DNSで名前解決する方法もありますが、ここでは説明しません。
また、「Active Directory」ドメインに参加させることでも名前解決はできます。
vfs_acl_xattr VFSモジュールを使ったWindows完全互換の実現
上記の設定では、Windowsと完全互換ではなかったので、Windowsからアクセスするファイルサーバーとしては使い勝手がよくありませんでした。
その代わり、WindowsからLinuxのパーミションを操作できるため、ホストOSでWindows用のファイルサーバーにSSHなどでアクセスして使うという、WindowsとLinuxの相互運用が可能す。
Sambaの「vfs_acl_xattr VFSモジュール」は、WindowsのNTFSアクセス権との完全互換を実現します。
その代わりに、Linuxのパーミションを完全に無視するので、Windowsと同じユーザーアカウントでLinuxホストを使うことが難しくなります。
今度は、「vfs_acl_xattr VFSモジュール」 を使って、先ほどのファイルサーバーをWindows互換に変更してみます。
コンテナの更新
「vfs_acl_xattr VFSモジュール」 を使うためには、Dockerコンテナを「–privileged」オプションで起動する必要があります。
いまのところ、既存のコンテナに「–privileged」を追加することはできません。
なので、以下の手順でコンテナを更新します。
foldersコンテナを停止します。
docker stop foldersfoldersコンテナをdockerイメージにします。
docker commit folders folders.no_vfs_acl_xattrfoldersという名前で新しいコンテナを作りたいので、既存のfoldersコンテナの名前を変更します。
docker rename folders folders.old新しいイメージ「 folders.no_vfs_acl_xattr 」で、同じ名前、同じipアドレスで新しいコンテナを作ります。
docker run \
--privileged \
--name=folders \
--hostname=folders \
--network=private-net \
--ip=192.168.11.10 \
--volume=/v/FOLDERS:/srv \
--detach=true \
folders.no_vfs_acl_xattrこの意味は、次の通りです。
| docker run | コンテナを作ります。 |
| –privileged | 特権モードでコンテナを実行します。 |
| –name=folders | コンテナに folders という名前を付けます。 |
| –hostname=folders | コンテナの hostname に folders を設定します。 |
| –network=private-net | private-net ネットワークに接続します。 |
| –ip=192.168.11.10 | ipアドレスを 192.168.11.10 に設定します。 |
| –volume=/v/FOLDERS:/srv | ホストの /v/FOLDERS を コンテナの /srv に対応させます。 |
| –detach=true | デタッチ モードで起動します。 |
| folders.no_vfs_acl_xattr | folders.no_vfs_acl_xattr イメージを使ってコンテナを作ります。 |
今回新しいオプションが出てきました。
「–privileged」オプションはコンテナとホスト間のセキュリティー分離をオフにします。
コンテナー内で root で実行されているプロセスは、ホストに於いてもrootの権限を持ちます。
コンテナの用途によっては、注意が必要なオプションです。
元となるイメージと「–privileged」オプション以外は前回と全く同じです。
コンテナに入ります。
docker exec -it folders bashsmbdプロセスが自動起動していますので、停止させます。
root@folders:/# /etc/init.d/smbd stopアプリケーションによっては、コンテナ上のプロセスをうまく停止できないものがあります。
その場合はkillコマンドで停止します。
これまで使っていたディレクトリーは移動して、同じ名前のディレクトリーを新規作成します。
root@folders:/# mv /srv/S1 /srv/BU1
root@folders:/# mkdir /srv/S1「/srv/S1」は拡張属性のみでアクセスコントロールします。
Linuxのアクセスコントロールは使用しないので、 「/srv/S1」のパーミションは開放します。
root@folders:/# chmod 777 /srv/S1sambaの設定ファイル「smb.conf」を書き換えます。
catとヒアドキュメントで書き込むとき、「タブは通らない」ので、スペースに替えてください。
cat <<'EOF' > /etc/samba/smb.conf
[global]
dos charset = CP932
server string = ネットワークストレージ
workgroup = WORKGROUP
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
logon home =
logon path =
domain master = No
local master = No
os level = 0
preferred master = No
acl group control = Yes
vfs objects = acl_xattr
acl_xattr:ignore system acls = yes
acl_xattr:default acl style = windows
map acl inherit = yes
inherit acls = yes
dos filemode = yes
force unknown acl user = yes
create mask = 0666
directory mask = 0777
map archive = no
map hidden = no
map readonly = no
map system = no
store dos attributes = yes
[ストレージ１]
path = /srv/S1
comment = １番目の共有
read only = No
guest ok = No
admin users = admin
EOFviで編集してもOKです。
root@folders:/# vi /etc/samba/smb.conf設定ファイルの内容は以下の通りです。
[global]
dos charset = CP932
server string = ネットワークストレージ
workgroup = WORKGROUP
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
logon home =
logon path =
domain master = No
local master = No
os level = 0
preferred master = No
acl group control = Yes
vfs objects = acl_xattr
acl_xattr:ignore system acls = yes
acl_xattr:default acl style = windows
map acl inherit = yes
inherit acls = yes
dos filemode = yes
force unknown acl user = yes
create mask = 0666
directory mask = 0777
map archive = no
map hidden = no
map readonly = no
map system = no
store dos attributes = yes
[ストレージ１]
path = /srv/S1
comment = １番目の共有
read only = No
guest ok = No
admin users = admin
この設定の肝は次のものです。
| vfs objects = acl_xattr | acl_xattr vfsモジュールを有効にする。 |
| acl_xattr:ignore system acls = yes | システムのアクセスコントロールを無視する。 |
| acl_xattr:default acl style = windows | Windows互換のアクセスコントロールを使う。 |
| admin users = fumi | 「ストレージ１」の管理権限をユーザーadminに渡します。 |
Linuxのパーミションを開放しているので、ユーザーがログインできると、なんでもできてしまいます。
既存のLinuxユーザーをログインできないように変更します。
root@folders:/# usermod -s /sbin/nologin fumi
root@folders:/# usermod -s /sbin/nologin yellow管理用ユーザーを登録しておきます。
新規ユーザーは、ログインできないように作成します。
root@folders:/# useradd -s /sbin/nologin admin
root@folders:/# pdbedit -a adminsmbdプロセスを起動します。
root@folders:/# /etc/init.d/smbd startこれでWindows完全互換のファイルサーバーが完成しました。
共有フォルダーの初期設定
Windows10パソコンのエクスプローラーのネットワークを開いて、foldersにアクセスしてみます。
まだ、何もWindowsネットワーク共有としての設定をしていないので、管理者admin以外のユーザーは「ストレージ１」フォルダーを開くことができません。
次の手順で「folders」への接続を、ユーザー「admin」で再接続します。
コマンドプロンプトを開きます。
検索ボックスに「cmd」と入力して「コマンドプロンプト」アプリを開きます。
現在の接続を切断します。
net use \\folders\ストレージ１ /deleteユーザー「admin」で接続します。
net use \\folders\ストレージ１ password /user:admin
再度「folders」にアクセスして、「ストレージ１」を開きます。
今度はアクセスできました。
smb.confの「 admin users = admin 」設定で、ユーザー「admin」は、このフォルダーにフルコントロールのアクセス権を持っています。
共有フォルダーの設計
Windows完全互換のメリットを活用して、運用の手間を省略する共有設計です。
管理者が行うのは、このアクセス許可設定とユーザーの作成だけです。
次のように設定します。
| ユーザー/グループ | 対象 | アクセス権限 |
|---|---|---|
| Everyone | このフォルダーのみ | 書き込み |
| Creator Owner | サブフォルダーとファイルのみ | フルコントロール |
「ストレージ１」には誰でもフォルダーを追加できます。
追加したフォルダーに対しては、作った人「Creator Owner」に全権を与えます。
作った人以外はこのフォルダーを変更/削除することはできません。
フォルダーを作ったユーザーが必要に応じて「自らアクセス権を設定」します。
共有フォルダーのアクセス許可設定
ユーザー「admin」で「folders」にアクセスして、「ストレージ１」のプロパティーを開きます。
「セキュリティ」タブで「詳細設定」をクリックします。
「ストレージ１のセキュリティの詳細設定」で「追加(D)」ボタンをクリックします。
「プリンシパルの選択」をクリックするとポップアップする「ユーザーまたはグループの選択」ダイアログボックスの「選択するオブジェクト名を入力してください(E):」欄に「Everyone」を入力して「OK」ボタンをクリックします。
「Everyone」に対して、次のように設定して「OK」ボタンをクリックします。
| プリンシパル | 適用先 | 基本のアクセス許可 |
|---|---|---|
| Everyone | このフォルダーのみ | ＋書き込み |
設定される「アクセス許可の詳細」を確認したい場合は、「OK」ボタンを押す前に「高度なアクセス許可を表示する」をクリックします。
ここで「OK」ボタンで設定を確定することもできますし、「基本のアクセス許可を表示する」をクリックして戻ることができます。
つづいて、「Creator Owner」を追加します。
「プリンシパルの選択」をクリックするとポップアップする「ユーザーまたはグループの選択」ダイアログボックスの「選択するオブジェクト名を入力してください(E):」欄に「creator owner」を入力して「OK」ボタンをクリックします。
「CREATOR OWNER」に対して、次のように設定して「OK」ボタンをクリックします。
| プリンシパル | 適用先 | 基本のアクセス許可 |
|---|---|---|
| CREATOR OWNER | サブフォルダーとファイルのみ | ＋フルコントロール |
次のように設定されていることを確認します。
| プリンシパル | 適用先 | 基本のアクセス許可 |
|---|---|---|
| Everyone | このフォルダーのみ | 読み取り、書込みと実行 |
| CREATOR OWNER | サブフォルダーとファイルのみ | フルコントロール |
「共有アクセス許可」についても、確認しておきます。
「Everyoneフルコントロール」になっているので、問題ありません。
「OK」ボタンで設定を終了します。
まだ何も入っていないフォルダーの初期設定なので、警告が出た場合は「OK」をクリックして進みます。
以上で初期設定は完了です。
現在の「ストレージ１」に 管理ユーザー「admin」で 接続しています。
設定が終わったので接続を切断します。
net use \\folders\ストレージ１ /delete共有のアクセス許可については、下記に説明があります。
Windowsから設定した拡張属性の確認
vfs_acl_xattr VFSモジュール を使うことで、Windows互換のNTFSアクセス コントロールを実現できます。
acl_xattr は、ファイルのNTFSアクセス権を拡張属性に格納します。
拡張属性は「getfattr」コマンドで表示することができます。
ただし、NTFSの拡張属性はヒューマン フレンドリーではありません。
fumi@y3:~$ docker exec -it folders getfattr -n security.NTACL /srv/S1
getfattr: Removing leading '/' from absolute path names
# file: srv/S1
security.NTACL=0sAwADAAAAAgAEAAIAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAScZAAAAHQAAAAAAAAAhAAAAAECAAAAAAAWAQAAAAAAAAABAgAAAAAAFgIAAAAAAAAAAgBcAAQAAAAAABgA/wEfAAECAAAAAAAWAQAAAAAAAAAAABQA/wEfAAEBAAAAAAAFEgAAAAAAFAC/ARIAAQEAAAAAAAEAAAAAAAsUAP8BHwABAQAAAAAAAwAAAAA=
一般ユーザーによる自分専用フォルダーの作成
別のユーザーで共有に接続した場合、切断してもしばらく切断処理が完了しない場合があります。
確実に接続を切断する一番いい方法は、クライアント パソコンを再起動することです。
「エクスプローラーのネットワーク」から「foldes」をクリックします。
「ストレージ１」フォルダーを開いて、自分専用のフォルダーを新規作成します。
名前を「yellowのフォルダ」にしてみます。
「yellowのフォルダ」を「右クリック」して「プロパティ(R)」を選択します。
「yellowのフォルダのプロパティ」で「セキュリティ」タブを開いて「詳細設定(V)」をクリックします。
「yellowのフォルダのセキュリティの詳細設定」でアクセス許可を確認します。
フォルダー作成ユーザー「yellow」に「フルコントロール」アクセス権が設定されています。
その他のユーザーにはアクセス権が設定されていないので、ユーザー「admin」以外はこのフォルダーにアクセスできません。
セキュリティーの確認
例えば、ユーザー「fumi」で 「yellowのフォルダ」 にアクセスしても拒否されます。
現在の「yellow」接続を切断します。
net use \\folders\ストレージ１ /deleteユーザー「fumi」で接続します。
net use \\folders\ストレージ１ password /user:fumi「yellowのフォルダに対するアクセス許可がありません。」という警告が出ます。
「fumi」の接続を切断します。
net use \\folders\ストレージ１ /deleteアクセスコントロールをユーザーに委任する
この共有設定のメリットは、初期設定後は管理者の負担が軽減できることです。
ユーザー「yellow」が必要に応じて、自分でユーザーにアクセス許可を与えれば共有フォルダーの完成です。
Windowsパソコンから使うのであれば、Windows互換のアクセスコントロールを使うことで、洗練されたセキュリティー設定ができるファイルサーバーになります。
アクセスしているユーザーの確認
Windows10では「コンピューターの管理」の共有のセッションで確認できます。
Sambaでは、「smbstatus」コマンドで確認することができます。
Dockerホストからコンテナにコマンドを流し込みます。
fumi@y3:~$ docker exec -it folders smbstatusまたはコンテナにbashでログインしてコマンドを実行します。
fumi@y3:~$ docker exec -it folders bash
root@folders:/# smbstatus以下のように出力されます。
Samba version 4.9.5-Debian
PID Username Group Machine Protocol Version Encryption Signing
----------------------------------------------------------------------------------------------------------------------------------------
1031 yellow yellow 192.168.11.31 (ipv4:192.168.11.31:55573) SMB3_11 - partial(AES-128-CMAC)
Service pid Machine Connected at Encryption Signing
---------------------------------------------------------------------------------------------
ストレージ１ 1031 192.168.11.31 水 7月 28 17時03分26秒 2021 JST - -
Locked files:
Pid Uid DenyMode Access R/W Oplock SharePath Name Time
--------------------------------------------------------------------------------------------------
1031 1002 DENY_NONE 0x100081 RDONLY NONE /srv/S1 yellowのフォルダ Wed Jul 28 17:03:34 2021
1031 1002 DENY_NONE 0x100081 RDONLY NONE /srv/S1 yellowのフォルダ Wed Jul 28 17:03:34 2021
1031 1002 DENY_NONE 0x100081 RDONLY NONE /srv/S1 . Wed Jul 28 17:03:31 2021
1031 1002 DENY_NONE 0x100081 RDONLY NONE /srv/S1 . Wed Jul 28 17:03:31 2021
1031 1002 DENY_NONE 0x100081 RDONLY NONE /srv/S1 . Wed Jul 28 17:03:31 2021Dockerホスト上のパーミション
foldersコンテナが動いている、Dockerホストのパーミションはどうなっているでしょうか。
Dockerホストの「/v/FOLDERS」は、foldersコンテナの「/srv」にバインドされています。
foldersコンテナはsambaの設定で、「/srv/S1」を「ストレージ１」フォルダとしています。
Windowsからyellowが「yellowのフォルダ」を作成しました。
Windowsからfumiが「fumiのフォルダ」を作成しました。
「folders」コンテナ上では、以下のようになっています。
root@folders:/# ls -l /srv/S1/
合計 8
drwxrwxrwx 2 fumi fumi 6 7月 29 15:13 fumiのフォルダ
drwxrwxrwx 6 yellow yellow 204 7月 27 18:08 yellowのフォルダ続いて、Dockerホスト上で確認してみます。
fumi@y3:~$ ls -l /v/FOLDERS/S1/
合計 8
drwxrwxrwx 2 fumi fumi 6 7月 29 15:13 fumiのフォルダ
drwxrwxrwx 6 1002 1002 204 7月 27 18:08 yellowのフォルダコンテナ上の「 fumiのフォルダ 」の所有者とグループは「fumi」と表示されています。
Dockerホスト上でも同じ「fumi」です。
「yellowのフォルダ」では、コンテナで「yellow」と表示されていた所有者やグループはホスト上では「1002」というuid番号に替わっています。
fumiについては、たまたま「ホスト上のユーザー」と「コンテナ上のユーザー」に「fumi」ユーザーが存在し、そのユーザーが同じ「uid」を持っているからなのです。
一方yellowはコンテナには存在しますが、ホストには対応するユーザー名がないので、番号だけが表示されているのです。
「注意が必要」なのは、コンテナの永続ファイルを「Dockerホストから別のホストに」バックアップする場合です。
rsyncはユーザーの「名前ベース」でデータを転送します。
所有者や権限なども併せて転送する場合、「名前ベース」にするのか「uid番号ベース」にするかを決めておかないと、トラブルになります。
「コンテナ側のuid番号」をベースとするのであれば、「–numeric-ids」オプションを付けて転送する必要があるのです。
また、拡張属性を合わせてバックアップする場合は、「–xattrs」オプションが必要です。
パスワードの管理
今回のようなスタンドアローンのファイルサーバーでは「 vfs_acl_xattr VFSモジュールを使ったWindows完全互換 」の場合は、管理者にパスワードの管理を委ねることになります。
Windows互換とユーザー自身でのパスワードの管理を両立させる場合は、ドメインコントローラーを立ててActive Directoryに認証を統合するのが一般的な方法です。
まとめ
Dockerとsambaで、Windows完全互換のファイルサーバーを作成しました。
個人での利用や小さなオフィスでは、十分に使える小道具です。
sambaで「Active Directory」の「ドメイン コントローラー」を作ることも可能です。
ただし、長い期間での運用を考えたとき、そのような複雑な機構を構築して、将来の負担にならないかを検討することも必要です。
