FSx for Windows File Serverで共有フォルダーのアクセス権限を設定する時のTIPS

FSx for Windows File Serverで共有フォルダーのアクセス権限を設定する時のTIPS

オンプレミスWindowsファイルサーバーとは少し違った「FSx for Windows File Server」ならでは(?)のTIPSかもしれません。
Clock Icon2022.01.31

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは!
福岡オフィスの青柳です。

Amazon FSx for Windos File Serverで共有フォルダーの「NTFSアクセス権」を設定する際、次のようなメッセージダイアログが表示されたことがある、という方はいらっしゃいますでしょうか?

共有のルートでフォルダーのアクセス許可をリモートで設定すると、ルート フォルダーとサブフォルダーすべてから継承されるアクセス許可はすべて削除されます。
継承されるアクセス許可を削除しないでアクセス許可を設定するには、[いいえ] をクリックして子フォルダーのアクセス許可を変更するか、またはローカルでログインしている間に変更を実行してください。

続行しますか? [はい] [いいえ]

今回は、このような場合の対応方法をご紹介したいと思います。

どのようなシチュエーションで発生するか?

メッセージ内容でも説明されているように、このメッセージが表示されるのは「共有フォルダーのルートフォルダーに対して、アクセス許可 (NTFSアクセス権) の設定変更をリモートで行おうとした場合」です。

条件は「共有フォルダーのルートフォルダーに対して」となっていますので、ルートフォルダーの配下に作成したサブフォルダーやファイルに対してNTFSアクセス権の設定変更を行う場合には該当しません。

また、「アクセス許可の設定変更をリモートで行おうとした」という部分については、FSx for Windows File Serverはリモートデスクトップ接続 (RDP接続) などによって直接管理を行うことができないため、リモート管理になってしまうのは回避することができません。

ここで、実際に「共有フォルダーのルートフォルダー」に対して「アクセス許可 (NTFSアクセス権) の設定変更をリモート」で行い、事象を発生させてみましょう。

「TestShare」という共有フォルダーが作成されているものとして、このフォルダーのNTFSアクセス権の変更を試みます。

「TestShare」を右クリックして「プロパティ」を選択します。

「セキュリティ」タブを選択して、「詳細設定」をクリックします。

「アクセス許可」タブを選択して「追加」をクリックします。

追加するアクセス権限を設定していきます。

  • プリンシパル: 「プリンシパルの選択」をクリックして「Authenticated Users」を指定します
  • 種類: 「許可」のままにします
  • 適用先: 「このフォルダー、サブフォルダーおよびファイル」のままにします
  • 基本のアクセス許可: 「変更」と「書き込み」にチェックを入れます

「OK」をクリックします。

「セキュリティの詳細設定」画面に戻るので、追加したアクセス権限の行が表示されていることを確認します。

ここで「OK」をクリックして設定を保存しようとすると、、、

冒頭で掲載したメッセージダイアログが表示されます。

なお、ここで「はい」を選択してしまうと、メッセージに書かれている通り、親オブジェクトから継承されているアクセス許可が全て削除されてしまいます
その結果、フォルダーのNTFSアクセス権限が意図しない設定になってしまう場合があるため、安易に「はい」を選択しない方がよいでしょう。

ここでは、一旦「いいえ」を選択してダイアログを閉じ、続いて「セキュリティの詳細設定」画面の「キャンセル」をクリックして、設定を行う前の状態に戻すことにします。

対処方法

それでは、対処方法について解説します。

2パターンの対処方法がありますので、順に説明していきます。

その(1): 「継承」を無効化する

「セキュリティの詳細設定」画面でアクセス権限を追加する前の状態から再開します。

アクセス権限の追加を行う前に、まず「継承の無効化」をクリックします。

ダイアログが表示されますので「継承されたアクセス許可をこのオブジェクトの明示的なアクセス許可に変換します」の方を選択します。

アクセス権限の「継承元」列に注目してみましょう。

さきほどまで「親オブジェクト」と表示されていた箇所が、いずれも「なし」表示へと変わっています。

一方、その他の項目については変化していません。

これは、さきほどの操作によって以下の処置が行われたということを意味します。

  • 親オブジェクトからのアクセス権限の「継承」を無効化、つまり、今まで親オブジェクトからの継承によって適用されていたアクセス権限を全てリセットする
  • 継承されていたアクセス権限と同じ権限を自分自身のアクセス権限へコピーすることによって、継承が有効であった時と同等のアクセス権限が適用された状態にする

これで問題の解決へ一歩近づきました。

設定を続けましょう。
「追加」をクリックします。

さきほどと同じように追加するアクセス権限を設定して、「OK」をクリックします。

「セキュリティの詳細設定」画面に戻るので、追加したアクセス権限の行が表示されていることを確認します。

ここで「OK」をクリックすると、さきほどとは違ってメッセージダイアログが表示されることなく、無事に設定が保存されます。

その(2): 「管理共有」を使ってNTFSアクセス権の設定を行う

アクセス権限の設定対象となるフォルダーを表示する際に「管理共有」経由で表示する方法です。

「管理共有」について (Windows Serverの管理に慣れていない方向けの解説です):

Windows ServerではOSによる管理のために「管理共有」と呼ばれる特殊な共有 (共有フォルダー) がいくつか用意されています。 管理共有には「共有名の最後に『$』が付く」「エクスプローラーを普通に開いても一覧に表示されない」という特徴があります。

管理共有には「Windowsシステムフォルダーの管理用」「プリンターの管理用」など用途別に種類がありますが、ここでは「ディスクボリュームの管理用」に用意された「d$」という名前の管理共有を使います。 「d」はディスクボリュームの「Dドライブ」を意味し、Dドライブに対してシステム権限でフルアクセスするために用意された共有ということになります。 (何故「Dドライブ」なのかと言うと、これは推測ですが、FSx for Windos File Serverが利用者向けにデータ領域として提供しているディスクボリュームが「Dドライブ」であるからだと思われます)

まずエクスプローラーを起動して、アドレスバーへ以下のように入力します。

¥¥<FSx for Windows File ServerファイルシステムのDNSホスト名>¥d$

¥は環境によっては「半角バックスラッシュ」で表示される場合もありますが、半角の「¥」記号のことです

ここから対象のフォルダーを探します。

あとは、フォルダーを右クリックして「プロパティ」を選択して、通常通りにアクセス権限の設定を行っていきます。

「セキュリティ」タブを選択して、「詳細設定」をクリックします。

「アクセス許可」タブを選択して「追加」をクリックします。

※ 「継承の無効化」を行う必要はありません!

追加するアクセス権限を設定して、「OK」をクリックします。

「セキュリティの詳細設定」画面に戻るので、追加したアクセス権限の行が表示されていることを確認します。

「OK」をクリックすると、メッセージダイアログが表示されることなく、無事に設定が保存されます。

どちらの対処方法を選ぶべきか?

(1)、(2) どちらの対処方法であっても結果的に同等のNTFSアクセス権限が設定されるため、「どちらを選んでもあまり変わらない」というのが私の見解です。

強いて言うならば、「対処方法(1)」では親オブジェクトからのアクセス権限の継承を無効化してしまうことによって、今後、親オブジェクトでアクセス権限の変更を行ったとしても子オブジェクトである共有フォルダーにはアクセス権限の変更が反映されないという点が挙げられます。

管理の一貫性の観点では「対処方法(2)」の方が好ましい、という言い方ができるかもしれません。

もちろん、企業・組織によってWindowsファイルサーバーのアクセス権限の管理方針があるかと思いますので、まずは、その考え方に準拠するのが第一なのではないかと思います。

おわりに

オンプレミスのWindowsファイルサーバーでは、ローカルサーバー上で直接「NTFSアクセス権限の設定」などの管理操作を行う場合も多いかと思いますので、今回の事象に遭遇したことが無いという方もいらっしゃるかもしれません。(実のところ私もそうでした)

FSx for Windows File Serverは「マネージドサービス」であるが故の「リモート管理」が主体であることから、オンプレミスでのWindowsサーバーの管理手法が流用できない場面が多々あります。

今後も、FSx for Windows File Serverならではの管理方法・設定方法に関するトピックをご紹介できればと思います。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.