az storage share-rm list returns a different share ID
- Dominant language
- Python
- Stars
- 4.6k
- Forks
- 3.5k
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 60
Description
The share ID returned in the share-rm command accepts permissions. Those permissions can be found by looking for the assignment against the azuread object, but in the case of assigning an RBAC to that share-rm ID, it was not functional.
The difference is the the "share" vs "fileshare" in the second to last position.
I am sure there is a reason for this... but reading the share-rm ID and applying a permission to it did not give the user access. You should explain if there are any differences in behavior between using the different ID formats.
usable share ID when assigning a permission (fileshares in the second to last position)
/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts//fileServices/default/fileshares/
what share-rm returns (shares in the second to last position)
/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts//fileServices/default/shares/
---
#### Document Details
⚠ *Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.*
* ID: 87de814a-84c0-2ac6-982c-d8415b0d7571
* Version Independent ID: c18ab402-f70c-774e-a48a-c2c03695b9d5
* Content: [az storage share-rm](https://docs.microsoft.com/en-us/cli/azure/storage/share-rm?view=azure-cli-latest#az-storage-share-rm-list)
* Content Source: [latest/docs-ref-autogen/storage/share-rm.yml](https://github.com/MicrosoftDocs/azure-docs-cli/blob/main/latest/docs-ref-autogen/storage/share-rm.yml)
* Service: **storage**
* GitHub Login: @rloutlaw
* Microsoft Alias: **routlaw**
Contributor guide
Assessment
This issue has not been assessed yet.