I don't agree that this bug exists on Manila. This is a client issue. show/update/delete by name is a client side optimization for better user experience. The workaround workflow is: $ manila list --all-tenants --name share-that-i-am-looking-for (Grab the ID of the share you're looking for) $ manila show However, that said, we can implement jiaopengju's fix. There are a couple of downsides to this approach however: 1) Performance Impact: show/delete/update by name is implemented as a "if not UUID, list all resources and sift through them to find the resource indicated by the name specified". So, listing all the resources belonging to all the tenants of a cloud may cause the "show/delete/update" commands to respond slower for having to process all that extra data. 2) More chances of collisions: Here's the situation by example: -------------------------------- There are 4 shares in this cloud, 2 of them named the same, however, only one of them belongs to the "admin" project (e1afea08080f4834b9d9dbe3fdb412c2) stack@scspa0341462001:~/python-manilaclient$ manila list --all-tenants +--------------------------------------+----------------------+------+-------------+-----------+-----------+-----------------+---------------------------------------+-------------------+----------------------------------+ | ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone | Project ID | +--------------------------------------+----------------------+------+-------------+-----------+-----------+-----------------+---------------------------------------+-------------------+----------------------------------+ | 054ba02a-8d03-4930-8ad5-9c414be30a9e | testadminshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | f2e7e6e3a3af4e3f8a66e78b0bfa843e | | 9a58f6f1-e1cd-400e-aa6f-7619a4cee1c2 | testadmindemoshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | e1afea08080f4834b9d9dbe3fdb412c2 | | cb3f200d-767f-4b6a-9aca-56666a1e4c2b | testadminadminshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | e1afea08080f4834b9d9dbe3fdb412c2 | | f83c76b8-fba9-46e0-ab1f-fcd974f1724a | testadmindemoshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | f2e7e6e3a3af4e3f8a66e78b0bfa843e | +--------------------------------------+----------------------+------+-------------+-----------+-----------+-----------------+---------------------------------------+-------------------+----------------------------------+ Today, the behavior is to only sift through the admin project shares to find the share by name: stack@scspa0341462001:~/python-manilaclient$ manila show testadmindemoshare1 +---------------------------------------+-------------------------------------------------------------------+ | Property | Value | +---------------------------------------+-------------------------------------------------------------------+ | status | available | | share_type_name | dhss_false | | description | None | | availability_zone | nova | | share_network_id | None | | export_locations | | | | path = 10.250.117.153:/share_a67899f9_313c_4076_acba_84a1658c3862 | | | preferred = True | | | is_admin_only = False | | | id = 12054386-b45f-4232-9589-1da9cc8c41f0 | | | share_instance_id = a67899f9-313c-4076-acba-84a1658c3862 | | share_server_id | None | | share_group_id | None | | host | scspa0341462001@cmodeSSVMNFS_01#aggr1 | | revert_to_snapshot_support | False | | access_rules_status | active | | snapshot_id | None | | create_share_from_snapshot_support | False | | is_public | False | | task_state | None | | snapshot_support | False | | id | 9a58f6f1-e1cd-400e-aa6f-7619a4cee1c2 | | size | 1 | | source_share_group_snapshot_member_id | None | | user_id | 153b4a22921b4101814e3330d04667a7 | | name | testadmindemoshare1 | | share_type | 596292e2-f6a6-42dd-9aca-e670993e6bee | | has_replicas | False | | replication_type | None | | created_at | 2017-12-07T19:03:17.000000 | | share_proto | NFS | | mount_snapshot_support | False | | project_id | e1afea08080f4834b9d9dbe3fdb412c2 | | metadata | {} | +---------------------------------------+-------------------------------------------------------------------+ With the code change: --------------------- stack@scspa0341462001:~/python-manilaclient$ git fetch https://git.openstack.org/openstack/python-manilaclient refs/changes/52/522452/2 && git checkout FETCH_HEAD remote: Counting objects: 17, done. remote: Compressing objects: 100% (8/8), done. remote: Total 9 (delta 8), reused 2 (delta 1) Unpacking objects: 100% (9/9), done. From https://git.openstack.org/openstack/python-manilaclient * branch refs/changes/52/522452/2 -> FETCH_HEAD Note: checking out 'FETCH_HEAD'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 53c0e27... Fix share can not be found by name in admin context You can no longer show the details of the share by name: stack@scspa0341462001:~/python-manilaclient$ manila show testadmindemoshare1 ERROR: Multiple share matches found for 'testadmindemoshare1', use an ID to be more specific. Within a project, you can control manually that no two shares can have overlapping names, however, across projects, name collisions are certainly more probable and cannot usually be controlled. That said, we might be able to live with this behavior in the interest of being consistent with other openstack clients (cinder), since the administrator may be able to workaround the collisions by: $ manila list --name share-that-i-am-looking-for (Grab the ID of the share you're looking for) $ manila show