2018年12月20日木曜日

CentOS7.5から7.6にしてsamba4.8にされたらWindows10からつながらなくなった

前提条件として、ドメインなしActive Directoryなし、Workgroupのみの環境です。

smb.confに明示的にserver roleディレクティブを指定しない場合、server roleディレクティブの規定値はautoですが、samba4.8からserver roleautoの場合の判定方法が変わって、security = userと設定してあっても、従来はWindows95用にdomain logons = yesという記述を残しっ放しにしていた場合でもROLE_STANDALONEと判定されていたケースがROLE_DOMAIN_PDCと判定されるように変更されたようです。

故に、記述を削除するか、または、smb.confに明示的に
server role = standalone
を記述すれば4.7以前の挙動に戻ります。

まあ、Linux同士(というかsamba同士)ならほっぽいておいても問題なく接続できます。
Windows10からつながらないことで原因調査に小一時間も無駄にしてしまったという恥を記録する次第です。
十年単位で毎度精査せず設定ファイルを引き継ぎまくってる報いでしょう。
おハズカシイ次第です。

2018年12月10日月曜日

Windows10 October 2018 Updateの新規インストール時の回復ドライブは実は使われていない(カラッポ)

Windows8の頃から回復ドライブネタでいくつか当ブログで記事を書き散らしていますが、記事にコメントをいただいた際に、現時点での最新のWindows10 October 2018 Update(1809)のインストールメディアでクリーンインストールした場合、回復ドライブがどのように配置されるのか試した際に表題の件のような面白いことが分かりましたので記事にしてみたいと思います。

まず、クリーンインストール直後のパーティション構成は次のようになります。
相変わらず回復ドライブが先頭にあります。
なぜかディスクアドミニストレータではMSRが表示されないため、正確を期すためにdiskpartコマンドで実際のパーティション構成を表示した結果も掲載します。
DISKPART> list part
  Partition ###  Type                Size     Offset
  -------------  ------------------  -------  -------
  Partition 1    回復                 499 MB  1024 KB
  Partition 2    システム                99 MB   500 MB
  Partition 3    予約                  16 MB   599 MB
  Partition 4    プライマリ               59 GB   615 MB
なお、パーティション番号4のプライマリというところがディスクアドミニストレータでは(C:)と表示されている部分に相当し、ここにWindows10がインストールされています。

実は、そもそもこれはマイクロソフト自身が2017年に公開した新レイアウトガイドに違反しています。

回復ドライブ、システム(EFI)、マイクロソフト予約(MSR)、Windowsインストール先パーティションの順にパーティションを構成するのは旧レイアウト仕様です。
MS自身が画定した新仕様ではEFI,MSR,Windowsインストール先パーティション、回復ドライブの順でなければなりません。

おまけに、回復ドライブの容量が499MBしか切ってないので、次回のメジャーアップグレード時に確実に廃棄され、Cドライブの後方が切り取られて回復ドライブにされてしまいます。
これで見事に回復ドライブが増殖するわけです。

MS自身で決めたルールをMS自身が破っているために結果としてユーザの計算機資源を奪うことになるわけです。

まあここまでだったら、ばかばかしいけど単に「相変わらずWindowsのインストーラの品質の低さは折り紙付きだなぁ」で終わりそうです。

しかし、これだけでは終わりません。
ここからがさらにお笑いなのです。

実は折角作成された回復ドライブ用のパーティションは使われていません

何を言っているかわからないでしょう?
言い方を変えます。

回復ドライブ用のパーティションはカラッポです

実際に見てみましょう。
ディスクアドミニストレータでは回復ドライブにドライブレターを割り当てられませんので、diskpartコマンドで割り当てる必要があります。
ここではTドライブとしてアサインしました。
その中身をのぞいてみましょう。
T:\>dir /ash
 ドライブ T のボリューム ラベルは 回復 です
 ボリューム シリアル番号は 2AF2-7EC1 です
 T:\ のディレクトリ
2018/12/10  16:13    <DIR>          System Volume Information
               0 個のファイル                   0 バイト
               1 個のディレクトリ     506,253,312 バイトの空き領域

System Volume Informationディレクトリ回復ドライブとは無関係です。「システムの復元」機能により勝手に全パーティションに生成されるものですので無視してください。
本当に何もないでしょう?

では、じゃあ一体回復ドライブはどこにあるんだ、ということになります。
調べ方はいたって簡単で、reagentcコマンドが教えてくれます。
試しに聞いてみましょう。
T:\>reagentc /info
Windows 回復環境 (Windows RE) およびシステム リセット構成
情報:
    Windows RE の状態:         Enabled
    Windows RE の場所:         \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
    ブート構成データ (BCD) ID: 31b21218-fc4a-11e8-9a48-f962270261aa
    回復イメージの場所:
    回復イメージ インデックス: 0
    カスタム イメージの場所:
    カスタム イメージ インデックス: 0
REAGENTC.EXE: 操作は成功しました。
赤字のパーティション番号をご覧ください。
partition4とあります。

先のdiskpartコマンドによるパーティション一覧を思い出していただきたいのですが、パーティション番号4は「Cドライブ」を示しています。
従って、C:\Recovery\WindowsRE というところに配置されているというわけです。
つまり、回復ドライブなどははなっから嘘っぱちで実際には、Cドライブに回復環境が配置されているのです

言い方を変えれば、Cドライブが回復ドライブを兼ねているということになります。

その理由はだた一つ、回復環境の容量に対して回復ドライブとしてインストーラが切ったパーティションサイズが不足しているからです。
1809の回復環境のファイルサイズは約485MBで、一見499MBあれば足りると思われるかもしれませんが、実は最低空き容量の規定があり、パーティションサイズが500MBを超える場合は320MBの容量が必要という仕様により、最低でも806MBなければならないために容量不足となってしまうわけです。
但し、最低空き容量が320MBという仕様書にある数値も眉唾でして、実際には、回復ドライブが実際に機能していたバージョンからアップグレードを重ねて1809にした別の環境では回復環境のサイズは510MBとなっておりますが、回復ドライブに奪われたサイズは878MBとなっており、その差が368MBとなっています。つまり仕様書には嘘っぱちの数値がかかれている可能性があり、実際には320MBの空き容量では足りない可能性があります。

ま、要するに新規インストール時に生成される回復ドライブというのは、現在では完全にユーザの計算機資源を無駄にするだけのものでしかないのでした。

しかも、ディスク全体ではなく、Cドライブが死ぬだけで回復環境も起動できないわけです。

自分自身の決め事を守らない上に、自分がインストールしようとするファイルのサイズをもとにパーティションサイズもろくに計算できないインストーラにはもう呆れを通り越して笑うしかないでしょう?

このような間抜けな事態を知るきっかけとなったこちらの記事にコメントをお寄せいただいた方に感謝いたします。
ありがとうございます。

なお、このような間抜けな事態を事前に回避するには、現状ですとWindows10をインストールする前に手動でパーティションを切り、それぞれのパーティションに対してidを振っておくなどパーティション構成を決定しておくほかに手段がありません。

その方法は手間ではあるものの作業としてはとても単純で、Windows10のインストールメディアさえあればdiskpartコマンドを用いてだれでもできます。
手順は本記事の末尾でご紹介いたしますMS自身が作成したご参考資料内にそのまま実行できるスクリプト形式で掲載されていますので割愛いたしますが、英語が面倒だという方は以前書いたこちらの記事が2015年の記事のため旧レイアウト仕様にあわせているものの、新レイアウトに従った順番に変えるだけですのでお役に立つかもしれません。

ただ・・・敢えてぶっちゃけていってしまいますが、今は亡きWindowsPhoneや特殊な構成のメーカお仕着せPCなどでは一般的なインストールメディアからインストールできないため必要でしょうけど、自分でWindows10をインストールできる人にとっては、この回復環境をわざわざ計算機上に配置する意味なんぞまったくないと思います。
インストールメディア上に全く同じ回復環境が用意されているからです。

今回の大型アップグレードでRedstone系列は終了し、次回はまた別シリーズとなります。
実は当ブログでも幾度か記事にさせていただきました通り、Windows8からWindows 10 November Update(1511、Threshold2)までは容量不足ならばアップグレードの際に無制限に回復ドライブの数が増えていくというとんでもない仕様でしたが、Redstone系列に入ってからは無制限な回復ドライブの増殖は行われなくなり、パーティションサイズを大きくできるなら大きくする、というように改善されました(むろん、今回のようにディスクの先頭にある場合は大きくできないので増殖することになりますが・・・)

次回以後の大型アップグレードの系列では、さらなる改善を期待したいと思います。あとインストーラを含めて品質管理をもうちょっとマシにしてください・・・

以上、お読みいただきありがとうございました。

ご参考:
UEFIの場合の新パーティションレイアウト資料はこちら:
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions

MBRの場合の新パーティションレイアウトの資料はこちら:
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-biosmbr-based-hard-drive-partitions

UEFIの場合の旧パーティションレイアウトの資料はこちら:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-7/dd744301(v=ws.10)