「samba」の記事 - Crieit

Samba が動く Docker Desktop のコンテナで、ボリューム内のファイルを見る

2021-12-03T00:01:29+09:00

本記事は、 docker Advent Calendar 2021 2日目の記事だ。
昨日は、 @subretu氏の DockerfileにおけるCMDとRUNの挙動だった。

docker のコンテナやボリュームの中身を見る際に、ホスト PC から SMB ファイル共有で参照できると都合が良い。

と言うことで以前、以下のような記事を作成したが、 Docker Desktop では利用できない問題があった。

無認証 SMB を samba で秒で立ち上げる Dockerfile (& docker-compose) | Aqua Ware つぶやきブログ

今回は、それを解消する手段について紹介したい。

先に断っておくが、私自身でいくつかの PC で試したところ、上手くいく PC とダメな PC がハッキリと分かれてしまい、現時点ではどのような条件だとダメなのかハッキリわかっていない。

何故 Docker Desktop では Samba にアクセスできないのか

Windows の SMB over TCP/IP アクセス機能は、接続先が 445 番ポートでないと利用できない制限がある。

ところが、 Docker Desktop で 445 番ポートをリッスンしようとしても、ホスト OS 側の LanmanServer サービス ("Server" と言う表示名のもの) が常に localhost の 445 番ポートを占有しているため、ポートをリッスンできずに失敗してしまう。

さらに、この LanmanServer サービスは、 Docker Desktop サービスがこれに依存しているため、このサービスを止めることもできない。

このため、なんとか localhost の 445 番ポート以外をリッスンさせてる方法を考えなくてはならない。

ループバックアダプターと portproxy を使う

結論から言うと、 "ループバックアダプター" と "portproxy" という Windows 組み込みの機能を利用する。

ループバックアダプターとは、一言で言うと 仮想的なネットワークアダプタ (NIC) だ。
この仮想NIC に 適当なIPアドレス を割り当てて、その 445 番ポートにアクセスすると、 localhost の 445 番以外 のアドレスに portproxy させる ことができる。
Docker Desktop 側でその 445 番以外 のアドレスをリッスンしておけば、問題を回避できるはずだ。

ループバックアダプターのインストール

Win+R で「ファイルを指定して実行」を開き、 hdwwiz.exe を実行する
ハードウェア追加ウィザードで、「一覧から選択したハードウェアをインストールする」を選択する
ネットワークアダプタ → Microsoft → Microsoft KM-TEST Loopback Adapter を選択
ネットワーク接続の一覧 (Win+R で ncpa.cpl を実行) を開き、今作成した仮想NIC のプロパティを開く。
TCP/IPv4 のプロパティを開いて、適当な固定 IPアドレスとサブネット (例として 192.168.254.2) を設定する
管理者権限でターミナル (コマンドプロンプトや PowerShell) を立ちあげ、 netsh コマンドでポートプロキシを立ちあげる。
- 以下は、仮想NIC の固定 IP に 192.168.254.2 を設定し、プロキシ先のポートを 38445 番にする場合。
  powershell netsh interface portproxy add v4tov4 listenport=445 listenaddress=192.168.254.2 connectport=38445 connectaddres=127.0.0.1
PC を再起動 する

これで準備完了だ。

SMB で使ってみる

冒頭に紹介した、以前の記事の Dockerfile を使って、 SMB を立ちあげてみる。

この Dockerfile のあるディレクトリをカレントディレクトリにして、以下を実行する。

docker build -t simple-samba .
docker run --rm -p 38445:445 simple-samba

実用的には、 docker run の -v オプションなどで、適当なボリュームをマウントする感じになるだろう。

そして、コンテナを起動した状態でループバックアダプターの仮想NIC に設定したアドレス (上記の例だと \\192.168.254.2\) に Windows エクスプローラーからアクセスできれば成功だ。

うまく動かない場合

うまく動かない場合、 portproxy を提供する iphlpsvc (IP Helper) サービスが、 445 ポートをリッスンできているか調べてみよう。

netstat コマンドで、 192.168.254.2:445 をリッスンしているプロセスID を調べる。
そして、そのプロセスID が何のサービスなのか、 Windows PowerShell v5.1¹ Get-WmiObject Win32_Service から確認してみよう。

うまく動作していれば、以下のように iphlpsvc サービスであることが確認できるだろう。

PS > netstat -ano | findstr 445
  TCP         0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP         0.0.0.0:8445           0.0.0.0:0              LISTENING       13944
  TCP         192.168.254.2:445      0.0.0.0:0              LISTENING       4016
  TCP         192.168.254.2:60665    192.168.254.2:445      ESTABLISHED     4
PS > Get-WmiObject Win32_Service | ? ProcessId -EQ 4016;

ExitCode  : 0
Name      : iphlpsvc
ProcessId : 4016
StartMode : Auto
State     : Running
Status    : OK

もし、 192.168.254.2:445 をリッスンしているプロセスID が 4 だった場合、 OS の LanmanServer サービスに関係するカーネルプロセスがこのポートをふさいでしまっているため、 portproxy が正しく動作していないと言うことになる。

PS > netstat -ano | findstr 445
  TCP         0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP         0.0.0.0:8445           0.0.0.0:0              LISTENING       13944
  TCP         192.168.254.2:445      192.168.254.2:60665    ESTABLISHED     4
  TCP         192.168.254.2:60665    192.168.254.2:445      ESTABLISHED     4

これは、おそらく portproxy を機能させる iphlpsvc サービスが機能する前に、 LanmanServer サービスが 445 ポートを塞いでしまっているからだと考えられる。

確実ではないと思われるものの、 iphlpsvc サービスが先に機能するかもしれない対策を、いくつか紹介する。
いずれも、設定後 PC の再起動が望ましい。

Win+R で「ファイルを指定して実行」を開き、 services.msc を実行して、「サービス」の管理コンソールを立ちあげ、 "IP Helper" (iphlpsvc) のスタートアップが「自動」になっていることを確認する。
- 管理者権限で PowerShell を立ちあげ、以下のコマンドを実行するのでも OK
  Set-Service iphlpsvc -StartupType Automatic;
netsh で IPv6 のサポートを追加する
- 管理者権限でターミナル (コマンドプロンプトや PowerShell) を立ちあげ、 netsh コマンドで以下のように実行する。
  netsh interface ipv6 install
- 理由がよくわからないが、これで上手くいく場合があるらしい。
  portforwarding - NETSH port forwarding from local port to local port not working - Stack Overflow
LanmanServer サービスの起動を遅延させる:
- 管理者権限で PowerShell を立ちあげ、 LanmanServer サービスの起動を「手動」にして起動を遅延させる。
  Set-Service LanmanServer -StartupType Manual;
- 設定の → アカウント → サインインオプション → 「更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します。」の on, off を切り替えてみる。
- ただし、 off にすると OS 再起動時のログイン速度が遅くなる。
コントロールパネル → ネットワークとインターネット → ネットワークと共有センター → 共有の詳細設定で、仮想NIC が属するプロファイル（ゲストまたはパブリック）で、「ファイルとプリンターの共有を無効にする」を選択する。
- 当然、ゲストまたはパブリックネットワークへ繋いだときに、ファイル共有ができなくなる。

どうしても仮想NIC の 445 ポートが PID 4 に奪われる場合、 iphlpsvc サービスと LanmanServer サービスの起動順とかを見てみると良いかもしれないが…
確認したところで何か具体的な対策があるわけでは無いが…

$procs = Get-WmiObject Win32_Service -Filter "Name='iphlpsvc' or Name='LanmanServer'";
Get-WmiObject win32_process -Filter (($procs.ProcessId | %{ "ProcessId='$_'" }) -join ' or ') | select Name,CreationDate,ProcessId,@{Name='Service'; Exp={$procs | ? ProcessId -eq $_.ProcessId | select -exp Name}};

おわりに

後半、動作しない場合の対策についてつらつらと書いてしまったが、ちゃんと動きさえすればなかなか便利なはずだ。

明日、 docker Advent Calendar 2021 の 3日目は… 今のところ空いているようだ。
どなたか書いてみてはいかがだろう?

2021年現在、 PowerShell v7 系列だと Get-WmiObject コマンドが動かないため。 ↩︎

無認証 SMB を samba で秒で立ち上げる Dockerfile (& docker-compose)

2020-06-23T01:07:00+09:00

docker 上の Linux (alpine) で Samba を立ち上げ、無認証の SMB 共有を開始する Dockerfile をメモっておく。

https://gist.github.com/advanceboy/a315d83d900929103d858a461b673e52

FROM alpine:3.10

RUN mkdir -p /samba/share && \
    chmod -R 0777 /samba/share && \
    chown -R nobody:nobody /samba/share

# install samba
RUN apk update && \
    apk add samba
RUN { \
    echo "[global]"; \
    echo "  security = user"; \
    echo "  map to guest = Bad User"; \
    echo "  guest account = nobody"; \
    echo "  min protocol = SMB2"; \
    echo "[public]"; \
    echo "  path = /samba/share"; \
    echo "  writable = yes"; \
    echo "  guest ok = yes"; \
    echo "  guest only = yes"; \
    echo "  create mode = 0666"; \
    echo "  directory mode = 0777"; \
} > /etc/samba/smb.conf
EXPOSE 139 445

# start smbd as foreground
ENTRYPOINT ["/bin/ash"]
CMD ["-c", "nmbd restart -D && smbd restart -FS --no-process-group



使用例

手っ取り早く実行したい場合、以下のような docker-compose.yml を Dockerfile と同じフォルダに保存し、

```yaml:docker-compose.yml

version: '3'

services:

  smb:

    build: .

    ports:

      - 445:445


コマンドプロンプト等のターミナルで、以下のように実行する。

```bash
docker-compose build
docker-compose up


何に使うのか

docker でデータを永続化する際、 Bind Mounts を使えば、デスクトップ側にファイルが永続化されているため、そのまま永続化されたファイルを覗き見ることができる。

しかし、 Bind Mounts では一部の機能に制限があることから、 Volumes (Named Volumes, Anonymous Volumes) を使うこともあるだろう。

(とりわけ Windows デスクトップから Linux コンテナを使う場合、 ファイルシステムの違いから Bind Mounts だと期待しない動きに遭遇しやすい。)

このとき、 Volumes の中身を SMB で共有させるコンテナを起動させておくと、 デスクトップ側から Volumes の中身が簡単に見られるようになるので、開発や検証に便利になる。

（但し上記の手順だと、 認証などが一切なく、 ネットワーク内のだれからでもアクセスできるので、 実運用上では 別途認証やアクセス元の制限を加えるなど、注意は必要だ。）

Docker Desktop for Windows での回避策

ホスト側が Linux であったり、 Windows 上の Docker Toolbox であれば、上記の手順だけでも問題なく SMB 共有が実行されるだろう。

しかし、 ホスト側が Docker Desktop for Windows である場合は、 Windows とコンテナの間で 445 ポートが競合してしまい、 以下のようなエラーが出て起動に失敗するはずだ。

ERROR: for smb  Cannot start service smb: Ports are not available: listen tcp 0.0.0.0:445: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
ERROR: Encountered errors while bringing up the project.


SMB は他のポートではアクセスができない。

また、 Docker Desktop for Windows では、 Windows デスクトップにポートフォワーディングせずに、 Hyper-V 上の Linux のホストマシンにアクセスする方法が用意されていない。

このため、コンテナの SMB 共有させたければ Docker Desktop を起動している Windows 側の SMB を止めるしかない。

[blogcard url="http://sangosthi.blogspot.com/2011/03/how-to-disable-cifssmb-port-445-on.html"]



上記の記事にあるように、 Windows 側で Server サービスを止め、無効化した後に OS を再起動すると、 445 ポートが空く。

この状態で、 docker-compose up すれば、エラーなく実行できるだろう。

ただ、ファイル共有をはじめとする様々な機能が Windows 側で動かなくなるだろうが。。。

(ということもあり、あまりオススメできる方法ではない。)



開発マシンをWindowsに移行した話
2018-12-11T09:58:00+09:00
(2019/05/05追記)

一年も前に書いたジョークがいまさら発火して、もうどんな顔していいかわからないのだけど🙃 この記事には後日談があります

VSCodeのRemote Development機能が革命的な話。

(追記終わり)

2010年頃に開発マシンをMacに移行して、それからずっとMacで開発していたのだけれど、Windowsに戻してみることにした。



理由

最近なんかMacイケてないと思わない？


新型MacBook Pro1.3kgはともかく、13インチMacBook Airが1.2kgってありえないでしょ？アップルの空気はそんなに重いの？


一方で、WindowsでWEB開発する条件が整いつつある


Office 365, Adobe CCなど、大手の会社のソフトウェアはだいたいマルチプラットフォーム対応になってきたよね


VSCodeもSublime TextもWindowsで動くよ

開発環境にDocker使うんだったら、もはやWindowsでも一緒なのでは？
surfaceかっこいいよね！


つまりこういうことです


  不満を持ちながらも惰性でMacを使い続けるよりはもっと良い環境になる可能性のある方向を目指す方が生産的だよねということで、試しにいっちょWindows機に移行してみるか、ということにしました

  Web開発環境をMacBook ProからWindows機に移行してみた話


RFP


nodeとかrubyといったunixネイティブのソフトウェアは、仮想マシンを使ってlinux上で動かす。中途半端にWindowsの上で動かすと余計な手間がかかるのでやらない


WSL(Windows Subsystem for Linux)はどうなんだろう？

OfficeやAdobeソフト、エディタなどを仮想マシンで動かすと重そうなので、WindowsネイティブなアプリはWindows上で動かしたい
その間にあるものをどうするかが悩み


構成

しばらく試して落ち着いた構成がこちら。




Windowsが提供する仮想マシン環境 hyper-V でlinuxマシンを動かす
一台目dev-baseは、開発環境のベースとなるマシン


sambaサーバでディスク領域をWindowsに公開して、Windowsのネットワークドライブとしてマウントする
VSCodeやSourceTreeはすべてこのドライブに対して実行する
同じ領域を、nfsサーバでも公開する

二台目linuxは、プロジェクトごとに用意する仮想マシン


nodeとかrubyとかがインストールされる
ソースコードなどは、nfs領域上にあるものをマウントして利用



こうすることで、Windows上のアプリから読み書きしたファイルをリアルタイムでlinux上で操作することができる。

あとは、Windows上で適当なシェルを用意して、SSHでlinuxに接続してしまえばもうlinuxの世界。

試行錯誤


MacとWindowsのキーの違いは、AutoHotkeyでだいたい吸収できます
仮想デスクトップの切り替えがキーボードでできないのも、win-10-virtual-desktop-enhancerで解決 (2019/05/05追記)標準でショートカットがあることを教えてもらいました！
WindowsのPowerShell上でsshが動くので、シェルはこれでもいいのですけど、なんか使いにくかったのでKittyを入れました (2019/05/05追記) Poderosaに乗り換えました
Macに乗り換えて泣く泣く別れた秀丸エディタと感動の再開を果たしたのですが、昨今の複雑化した開発の前には、もはや単機能エディタでは力不足ですね。初恋の人と同窓会で再開したみたいだと思いました
Docker on linux試したんだけど、これdocker内からファイルを書くとrootで書いたことになっちゃうのですよね


最近のDockerだと、User Namespaceという機能で解決できるらしいのですが、うまく行かなかったので諦めました
Hyper-Vがすんなり動いたので、Docker for windowsはまだ試してない。うまく動けばこっちのほうがいいかも



良かったこと


Surface軽い！


1.3kgのMacbook Proはリュックで背負っても辛い感じだったのですが、700gのSurface Proなら肩掛けカバンでも持ち歩くことができます。封筒にだって入っちゃうぞ。

スナップ機能が便利


Windows7の頃からあった機能らしいのですが、画面を左右に分割してブラウザとエディタなどのアプリを配置することができます。MacのMoomでもできますが、Windowsだと、左70%右30%みたいなことができるのが嬉しい

Windows Hello楽しい


iPhoneのFaceIDと同様の、顔認証によるログイン機能が搭載されています。パソコン起動したときディスプレイと目を合わせるのは「よろしくね」という感じでちょっとよいです



困ったこと


なんか不安定


スリープから復帰した時に仮想マシンが起きてこなかったり、外付けディスプレイへの描画が起きてこないなどの、かゆいトラブルが発生しています。今思えばMacは安定していたなあ
とはいえ、Macでトラブルが起きないのは、長いこと使ってきてトラブルを回避するノウハウを体が覚えているみたいなところもあるので、Windowsだってしばらく使えば安定してくるんじゃないかなと期待している

surfaceビミョー


surfaceの特徴であるTypeCover(超薄型キーボード)、キーボードとしては、多少ペコペコするけど普段使いでも行けるくらいよくできています。
問題なのはタッチパネルの方で、普段はいいのだけれど、電車の中みたいに安定しないところで使おうとするとカーソルが暴走を始めます。たぶん、歪むと検出値が安定しなくなるんだと思う
だからといって外付けマウスを電車の中で使うのは不可能なので、指輪マウスを実験中w





まとめ

予想していたとおり、Macじゃないと開発できないのはiPhoneアプリくらいで、unixベースのソフトウエアを使って開発するぶんには、MacでもWindowsでもできるなという感じです。

Macは良かったんだなあ、と思うこともあるのですけど、新しい環境は楽しいのでしばらくこれで続けてみようと思います。