Création de partage
L’opération Create Share crée un partage Azure Files sous le compte spécifié. Bien que cette API soit entièrement prise en charge, il s’agit d’une API de gestion héritée. Nous vous recommandons d’utiliser plutôt partages de fichiers - Créer, qui est fourni par le fournisseur de ressources Stockage Azure (Microsoft.Storage). Pour en savoir plus sur l’interaction programmatique avec FileShare les ressources à l’aide du fournisseur de ressources Stockage Azure, consultez Opérations sur les partages de fichiers.
Si un partage portant le même nom existe déjà, l’opération échoue. La ressource de partage inclut des métadonnées et propriétés pour ce partage. Il n’inclut pas de liste des fichiers contenus dans le partage.
Disponibilité du protocole
| Protocole de partage de fichiers activé | Disponible |
|---|---|
| SMB (Server Message Block) |  |
| NFS (Network File System) | |
Requête
Vous pouvez construire la Create Share requête comme indiqué ici. Nous vous recommandons d’utiliser HTTPS.
| Méthode | URI de demande | Version HTTP |
|---|---|---|
PUT |
https://myaccount.file.core.windows.net/myshare?restype=share |
HTTP/1.1 |
Remplacez les composants de chemin d’accès affichés dans l’URI de requête par le vôtre, comme suit :
| Composant Path | Description |
|---|---|
myaccount |
nom de votre compte de stockage. |
myshare |
Nom du partage de fichiers. Le nom ne peut contenir que des caractères minuscules. |
Pour plus d’informations sur les restrictions de nommage de chemin d’accès, consultez Partages de noms et références, répertoires, fichiers et métadonnées.
Paramètres URI
Vous pouvez spécifier les paramètres supplémentaires suivants dans l’URI de requête :
| Paramètre | Description |
|---|---|
timeout |
facultatif. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de service de fichiers. |
En-têtes de requête
Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :
| En-tête de requête | Description |
|---|---|
Authorization |
Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure. |
Date ou x-ms-date |
Obligatoire. Spécifie l'heure UTC (temps universel coordonné) pour la demande. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure. |
x-ms-version |
Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d’informations, consultez Contrôle de version pour les services de stockage Azure. |
x-ms-meta-name:value |
facultatif. Paire nom-valeur à associer au partage en tant que métadonnées. Les noms de métadonnées doivent respecter les règles d’affectation de noms pour les identificateurs C#. |
x-ms-share-quota |
facultatif. Pris en charge dans la version 2015-02-21 et ultérieure. Spécifie la taille maximale du partage, en gibibytes (Gio). |
x-ms-access-tier |
facultatif. Pris en charge dans la version 2019-12-12 et ultérieure. Spécifie le niveau d’accès du partage. Les valeurs correctes sont TransactionOptimized, Hot et Cool. Pour plus d’informations sur les niveaux de partage de fichiers, consultez Azure Files niveaux de stockage. |
x-ms-enabled-protocols: <SMB \| NFS> |
facultatif. Pris en charge dans la version 2019-07-07 et ultérieures. Spécifie les protocoles activés sur le partage. S’ils ne sont pas spécifiés, la valeur par défaut est SMB. - SMB: le partage est accessible par SMBv3.0, SMBv2.1 et REST.- NFS: le partage est accessible par NFSv4.1. Un compte Premium est requis pour cette option. |
x-ms-root-squash: <NoRootSquash \| RootSquash \| AllSquash> |
facultatif. NFS uniquement. Pris en charge dans la version 2019-07-07 et ultérieures. Spécifie le comportement d’écrasement racine sur le partage lorsque NFS est activé. S’il n’est pas spécifié, la valeur par défaut est NoRootSquash. - NoRootSquash: désactivez l’écrasement racine.- RootSquash: mappez les demandes de uid/gid 0 à l’uid/gid anonyme.- AllSquash: mappez tous les uids et gids à l’utilisateur anonyme. |
x-ms-client-request-id |
facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes que le serveur reçoit. Pour plus d’informations, consultez Surveiller Azure Files. |
Corps de la demande
Aucun.
Exemple de requête
PUT https://myaccount.file.core.windows.net/myshare?restype=share 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=
response
La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.
Code d’état
Une opération réussie renvoie le code d'état 201 (Créé).
Pour plus d’informations, consultez État et codes d’erreur.
En-têtes de réponse
La réponse de l'opération inclut les en-têtes suivants. La réponse peut également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.
| En-tête de réponse | Description |
|---|---|
ETag |
Contient une valeur qui représente la version du partage, placée entre guillemets. |
Last-Modified |
Retourne la date et l’heure de la dernière modification du partage. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représenter les valeurs de date/heure dans les en-têtes. Toute opération modifiant le partage ou ses propriétés ou métadonnées met à jour l'heure de la dernière modification. Les opérations sur les fichiers n’affectent pas l’heure de dernière modification du partage. |
x-ms-request-id |
Identifie de manière unique la demande et vous pouvez l’utiliser pour résoudre les problèmes de la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API |
x-ms-version |
Indique la version Azure Files utilisée pour exécuter la demande. |
Date |
Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée. |
x-ms-client-request-id |
Peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id s’il est présent dans la requête et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, il n’est pas présent dans la réponse. |
Response body
Aucun.
Exemple de réponse
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
Autorisation
Seul le propriétaire du compte peut appeler cette opération.
Remarques
Les partages sont créés immédiatement dans le compte de stockage. Il n’est pas possible d’imbriquer un partage dans un autre.
Vous pouvez spécifier des métadonnées pour un partage lorsque vous le créez en incluant un ou plusieurs en-têtes de métadonnées sur la demande. Le format de l'en-tête de métadonnées est x-ms-meta-name:value.
Si un partage du même nom est en cours de suppression lorsque vous appelez Create Share, le serveur retourne status code 409 (Conflit), et des informations d’erreur supplémentaires indiquent que le partage est en cours de suppression.
Vous pouvez utiliser le quota de taille de partage pour limiter la taille des fichiers stockés sur le partage. Le quota ne limite pas la taille des instantanés. La surcharge associée aux fichiers et utilisée pour calculer la taille de facturation du compte de stockage n’est pas prise en compte dans le quota.
Lorsque la somme des tailles des fichiers sur le partage dépasse le quota défini sur le partage, les tentatives d’augmentation de la taille d’un fichier échouent et la création de nouveaux fichiers non vides (via REST) échoue. Vous pourrez toujours créer des fichiers vides.
Modifier ou définir le quota n'a aucun effet sur la facturation. Vous êtes toujours facturé pour la taille des fichiers plus la surcharge.