Create Share

The Create Share operation creates a new Azure Files share under the specified account. Although this API is fully supported, this is a legacy management API. We recommend that you instead use File Shares - Create, which is provided by the Azure Storage resource provider (Microsoft.Storage). To learn more about how to programmatically interact with FileShare resources by using the Azure Storage resource provider, see Operations on FileShares.

If a share with the same name already exists, the operation fails. The share resource includes metadata and properties for that share. It doesn't include a list of the files that are contained in the share.

Protocol availability

Enabled file share protocol Available
Server Message Block (SMB) Yes
Network File System (NFS) Yes


You can construct the Create Share request as shown here. We recommend that you use HTTPS.

Method Request URI HTTP version

Replace the path components that are shown in the request URI with your own, as follows:

Path component Description
myaccount The name of your storage account.
myshare The name of your file share. The name can contain only lowercase characters.

For more information about path-naming restrictions, see Name and reference shares, directories, files, and metadata.

URI parameters

You can specify the following additional parameters on the request URI:

Parameter Description
timeout Optional. The timeout parameter is expressed in seconds. For more information, see Set time-outs for File service operations.

Request headers

The required and optional request headers are described in the following table:

Request header Description
Authorization Required. Specifies the authorization scheme, account name, and signature. For more information, see Authorize requests to Azure Storage.
Date or x-ms-date Required. Specifies the Coordinated Universal Time (UTC) time for the request. For more information, see Authorize requests to Azure Storage.
x-ms-version Required for all authorized requests. Specifies the version of the operation to use for this request. For more information, see Versioning for Azure Storage services.
x-ms-meta-name:value Optional. A name-value pair to associate with the share as metadata.

Metadata names must adhere to the naming rules for C# identifiers.
x-ms-share-quota Optional. Supported in version 2015-02-21 and later. Specifies the maximum size of the share, in gibibytes (GiB).
x-ms-access-tier Optional. Supported in version 2019-12-12 and later. Specifies the access tier of the share. Valid values are TransactionOptimized, Hot, and Cool. For detailed information about file share tiers, see Azure Files storage tiers.
x-ms-enabled-protocols: <SMB \| NFS> Optional. Supported in version 2020-02-10 and later. Specifies the enabled protocols on the share. If they're not specified, the default is SMB.

- SMB: The share can be accessed by SMBv3.0, SMBv2.1, and REST.
- NFS: The share can be accessed by NFSv4.1. A premium account is required for this option.
x-ms-root-squash: <NoRootSquash \| RootSquash \| AllSquash> Optional. Supported in version 2020-02-10 and later. Specifies the root squashing behavior on the share when NFS is enabled. If it's not specified, the default is NoRootSquash.

- NoRootSquash: Turn off root squashing.
- RootSquash: Map requests from uid/gid 0 to the anonymous uid/gid.
- AllSquash: Map all uids and gids to the anonymous user.
x-ms-client-request-id Optional. Provides a client-generated, opaque value with a 1-kibibyte (KiB) character limit that's recorded in the logs when logging is configured. We highly recommend that you use this header to correlate client-side activities with requests that the server receives. For more information, see Monitor Azure Files.

Request body


Sample request

PUT HTTP/1.1  
Request Headers:  
x-ms-version: 2020-02-10  
x-ms-date: <date>  
x-ms-meta-Name: StorageSample  
x-ms-enabled-protocols: NFS
x-ms-root-squash: RootSquash
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=  


The response includes an HTTP status code and a set of response headers.

Status code

A successful operation returns status code 201 (Created).

For more information, see Status and error codes.

Response headers

The response for this operation includes the following headers. The response might also include additional standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.

Response header Description
ETag Contains a value that represents the version of the share, enclosed in quotation marks.
Last-Modified Returns the date and time when the share was last modified. The date format follows RFC 1123. For more information, see Represent date/time values in headers.

Any operation that modifies the share or its properties or metadata updates the last modified time. Operations on files don't affect the last modified time of the share.
x-ms-request-id Uniquely identifies the request, and you can use it to troubleshoot the request. For more information, see Troubleshoot API operations
x-ms-version Indicates the Azure Files version that was used to execute the request.
Date A UTC date/time value that's generated by the service, which indicates the time when the response was initiated.
x-ms-client-request-id Can be used to troubleshoot requests and corresponding responses. The value of this header is equal to the value of the x-ms-client-request-id header if it's present in the request and the value contains no more than 1,024 visible ASCII characters. If the x-ms-client-request-id header isn't present in the request, it isn't present in the response.

Response body


Sample response

Response Status:  
HTTP/1.1 201 Created  
Response Headers:  
Transfer-Encoding: chunked  
Date: <date>  
ETag: "0x8CB14C3E29B7E82"  
Last-Modified: <date>  
x-ms-version: 2020-02-10  
Server: Windows-Azure-File/1.0 Microsoft-HTTPAPI/2.0  


Only the account owner may call this operation.


Shares are created immediately within the storage account. It's not possible to nest one share within another.

You can specify metadata for a share when you create it by including one or more metadata headers on the request. The format for the metadata header is x-ms-meta-name:value.

If a share by the same name is being deleted when you call Create Share, the server returns status code 409 (Conflict), and additional error information indicates that the share is being deleted.

You can use the share size quota to limit the size of files that are stored on the share. The quota doesn't limit the size of snapshots. The overhead that's associated with files and used to compute the billing size for the storage account isn't accounted for in the quota.

When the sum of the sizes of the files on the share exceeds the quota that's set on the share, attempts to increase the size of a file will fail, and creating new non-empty files (via REST) will fail. You'll still be able to create empty files.

Changing or setting the quota has no effect on billing. You are still billed for the size of the files plus the overhead.

See also

Operations on Azure Files shares