次の方法で共有

共有 ACL の設定

  • [アーティクル]

この操作により Set Share ACL 、共有アクセス署名で使用する格納されたアクセス ポリシーが設定されます。 アクセス ポリシーの設定の詳細については、「 共有アクセス署名を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。

プロトコルの可用性

有効なファイル共有プロトコル 利用可能
SMB はい
NFS いいえ

要求

要求は Set Share ACL 次のように構築できます。 HTTPS をお勧めします。 myaccount をストレージ アカウントの名前に置き換えます。

Method 要求 URI HTTP バージョン
PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1

URI パラメーター

次の追加パラメーターを要求 URI に指定できます。

パラメーター 説明
timeout 省略可能。 timeout パラメーターは、秒単位で表されます。 詳細については、「Azure Files操作のタイムアウトを設定する」を参照してください。

要求ヘッダー

次の表では、必須および省略可能な要求ヘッダーについて説明します。

要求ヘッダー 説明
Authorization 必須。 承認スキーム、アカウント名、署名を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
Date または x-ms-date 必須。 要求に対して協定世界時 (UTC) を指定します。 詳細については、「Azure Storage への要求を承認する」をご覧ください。
x-ms-version すべての承認された要求に必要です。 この要求に使用する操作のバージョンを指定します。 この操作は、バージョン 2015-02-21 以降でのみ使用できます。

詳細については、「Azure Storage サービスのバージョン管理」を参照してください。
x-ms-client-request-id 省略可能。 ログ記録の構成時にStorage Analytics ログに記録される 1 kibibyte (KiB) 文字制限を使用して、クライアントによって生成された不透明な値を提供します。 このヘッダーを使用して、クライアント側のアクティビティとサーバーが受信する要求を関連付けるよう強くお勧めします。 詳細については、「Azure Blob Storageの監視」を参照してください。
x-ms-lease-id:<ID> コピー先のファイル共有にアクティブなリースがある場合は必須です。 バージョン 2020-02-10 以降で使用できます。 要求にリース ID が含まれていないか、有効でない場合、状態コード 412 (前提条件が失敗) で操作が失敗します。

このヘッダーが指定されていて、コピー先のファイル共有に現在アクティブなリースがない場合、操作は状態コード 412 (前提条件に失敗) で失敗します。

要求本文

保存されているアクセス ポリシーを指定するには、Set Share ACL 操作の要求本文で一意識別子とアクセス ポリシーを指定します。

要素には SignedIdentifier 、 要素で指定されている一意の識別子が Id 含まれます。 SignedIdentifier には、 要素で指定されているアクセス ポリシーの AccessPolicy 詳細も含まれます。 一意識別子の最大長は 64 文字です。

フィールドと Expiry フィールドは Start UTC 時刻で表され、有効な ISO 8061 形式に準拠している必要があります。 サポートされている ISO 8061 形式は次のとおりです。

  • YYYY-MM-DD
  • YYYY-MM-DDThh:mmTZD
  • YYYY-MM-DDThh:mm:ssTZD
  • YYYY-MM-DDThh:mm:ss.fffffffTZD

これらの形式の日付部分では、YYYY は 4 桁の年表現、MM は 2 桁の月表現、DD は 2 桁の日付表現です。 時間部分では、hh は 24 時間表記の時間表現、mm は 2 桁の分表現、ss は 2 桁の秒表現、fffffff は 7 桁のミリ秒表現です。 時刻指定子 T は、文字列の日付と時刻の部分を区切ります。 タイム ゾーン指定子 TZD は、タイム ゾーンを指定します。

<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>unique-64-character-value</Id>  
    <AccessPolicy>  
      <Start>start-time</Start>  
      <Expiry>expiry-time</Expiry>  
      <Permission>abbreviated-permission-list</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

要求のサンプル

Request Syntax:  
PUT https://myaccount.file.core.windows.net/myshare?restype=share&comp=acl HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Authorization: SharedKey myaccount:V47F2tYLS29MmHPhiR8FyiCny9zO5De3kVSF0RYQHmo=  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<SignedIdentifiers>  
  <SignedIdentifier>   
    <Id>MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=</Id>  
    <AccessPolicy>  
      <Start>2015-07-01T08:49:37.0000000Z</Start>  
      <Expiry>2015-07-02T08:49:37.0000000Z</Expiry>  
      <Permission>rwd</Permission>  
    </AccessPolicy>  
  </SignedIdentifier>  
</SignedIdentifiers>

Response

応答には、HTTP 状態コードおよび一連の応答ヘッダーが含まれています。

状態コード

操作に成功すると、状態コード 200 (OK) が返されます。

応答ヘッダー

この操作の応答には、次のヘッダーが含まれています。 応答には、追加の標準 HTTP ヘッダーも含まれる場合があります。 すべての標準ヘッダーは 、HTTP/1.1 プロトコル仕様に準拠しています。

応答ヘッダー 説明
ETag コンテナーが最後に変更された日時を返します。 日付形式は RFC 1123 に従います。 詳細については、「 ヘッダーでの日付/時刻値の表現」を参照してください。
Last-Modified 共有またはそのプロパティまたはメタデータを変更する操作は、ファイルのアクセス許可の設定を含め、最終変更時刻を更新します。 ファイルに対する操作は、共有の最終変更時刻には影響しません。
x-ms-request-id 行われた要求を一意に識別し、要求のトラブルシューティングに使用できます。 詳細については、「 API 操作のトラブルシューティング」を参照してください。
x-ms-version 要求の実行に使用されたAzure Filesのバージョンを示します。
Date または x-ms-date サービスが応答を送信した時刻を示す UTC 日付/時刻値。
x-ms-client-request-id 要求と対応する応答のトラブルシューティングに使用できます。 このヘッダーの値は、要求に存在し、その値 x-ms-client-request-id が最大 1,024 文字の可視 ASCII 文字である場合、ヘッダーの値と同じです。 ヘッダーが x-ms-client-request-id 要求に存在しない場合、このヘッダーは応答に存在しません。

応答のサンプル

Response Status:  
HTTP/1.1 200 OK  
  
Response Headers:  
Transfer-Encoding: chunked  
Date: <date>  
ETag: "0x8CB171613397EAB"  
Last-Modified: <date>  
x-ms-version: 2015-02-21  
Server: Windows-Azure-File/1.0 Microsoft-HTTPAPI/2.0

承認

この操作を呼び出すことができるのは、アカウント所有者だけです。

注釈

次のいずれかの条件が当てはまる場合を除き、アカウント所有者のみが特定の共有内のリソースにアクセスできます。

  • 所有者は、共有に対するアクセス許可を設定することで、共有リソースをパブリック アクセスに使用できるように指定しました。
  • 所有者は、共有内のリソースに対して共有アクセス署名を発行しました。

コンテナーのアクセス許可を設定すると、既存のアクセス許可が置換されます。 コンテナーのアクセス許可を更新するには、 Get Share ACL を 呼び出して、コンテナーに関連付けられているすべてのアクセス ポリシーをフェッチします。 変更するアクセス ポリシーを変更し、完全なデータ セットを使用して を呼び出 Set Share ACL して更新を実行します。

共有レベルのアクセス ポリシーの確立

保存されているアクセス ポリシーでは、関連付けられている共有アクセス署名の開始時刻、有効期限、アクセス許可を指定できます。 共有またはファイル リソースへのアクセスを制御する方法に応じて、次のことができます。

  • 格納されているアクセス ポリシー内でこれらのパラメーターをすべて指定し、共有アクセス署名の URL から省略します。 これにより、関連付けられている署名の動作を変更したり、いつでも取り消したりすることができます。
  • 格納されているアクセス ポリシー内の 1 つ以上のアクセス ポリシー パラメーターを指定し、URL に他のパラメーターを指定します。
  • URL のすべてのパラメーターを指定します。 この場合、格納されているアクセス ポリシーを使用して署名を取り消すことができますが、その動作を変更することはできません。

アクセス ポリシーの設定の詳細については、「 共有アクセス署名を使用して Azure Storage リソースへの制限付きアクセスを許可する」を参照してください。

共有アクセス署名と格納されているアクセス ポリシーには、署名を承認するために必要なすべてのフィールドを含める必要があります。 必須フィールドが欠落している場合、要求は失敗します。 同様に、共有アクセス署名 URL と格納されているアクセス ポリシーの両方でフィールドが指定されている場合、要求は状態コード 400 (無効な要求) で失敗します。 共有アクセス署名を作成するフィールドの詳細については、「Shared Access Signature を 使用する」を参照してください。

1 つの共有に対して、いつでも最大 5 つの個別のアクセス ポリシーを設定できます。 要求本文で 5 つ以上のアクセス ポリシーが渡された場合、サービスは状態コード 400 (無効な要求) を返します。

共有アクセス署名は、コンテナー データが匿名読み取りアクセスに使用できるかどうかに関係なく、共有またはファイルで発行できます。 共有アクセス署名を使用すると、リソースをアクセス可能にする方法、タイミング、およびユーザーをより詳細に制御できます。

共有スナップショットのアクセス ポリシーを設定または取得することはできません。 アクセス ポリシーを設定しようとすると、サービスは状態コード 400 (InvalidQueryParameterValue) を返します。

注意

コンテナーに格納されているアクセス ポリシーを確立すると、有効になるまでに最大 30 秒かかる場合があります。 この期間中、保存されているアクセス ポリシーに関連付けられている共有アクセス署名は、アクセス ポリシーがアクティブになるまで、状態コード 403 (禁止) で失敗します。

関連項目

FileShare リソースに対する操作 (Azure Files)