Unable to modify a share whose name is used twice

[lost night]

Hello,

I have 2 shares having the same name.
They are used for 2 different qtrees located in different volumes.

I want to modify one share, used for a given qtree/volume.

When creating the share, I can specify a NAS path.

When I modify the share to add or remove users, how can I specify the path or volume/qtree ?

• name: user | create | add user
  na_ontap_cifs_acl:
  state: present
  share_name: "{{ nas_share_name }}"
  user_or_group: "{{ _nas_cifs_user | default(nas_cifs_user) }}"
  permission: "{{ nas_permission }}"
  vserver: "vs{{ target }}"
  hostname: "{{ nas_hostname }}"
  username: "{{ nas_username }}"
  password: "{{ nas_password }}"
  https: true
  validate_certs: false

Based on the documentation, there is no field to specify the path, or volume/qtree.

Context: Netapp Ontap collection 22.6.0

[edgy heron]

Hello Remi, share names will be unique under a vserver. I hope the shares are hosted on the different vserver?

[lost night]

Hello Durai,

Yes, both shares are located on the same vserver

Unique share name on a vserver does not seem to be enforced in the UI

[edgy heron]

oh okay! Actually CIFS ACL configuration has no parameter support for mentioning path or volume

You need to consider renaming one of the share as best practice as they will have conflicts

[lost night]

Ok, thx. Using ansible, we may have in fact overwritten the existing share .... beause we overlooked at the existing share name

Thx for this information

[edgy heron]

Ansible uses API calls and it would definitely fail with duplicate entry error if we try creating a new share using existing share name.

Welcome!

[lost night]

It does not seem to be the current behaviour we had with our playbook.

The playbook was completed without error.

The existing share name was replaced by the new share name

[edgy heron]

Could you please provide output of command "cifs share show <sharename>" for this share?

[lost night]

We had to urgently revert the change. It had broken the existing share

But I will perform an other test on a test envrionment

Back within minutes

Ok, so I did a test. Several times to observe the behaviour

I create a share name 'SHARE_TEST"' along path /vol/ansitest002sas_data1/qtree1

Then I created again "SHARE_TEST" along path /vol/ansitest002sas_data2/qtree1

The volume are different.

The same playbook is being used

No error

Ansible collection 22.6.0

The playbook went to completion each time.

Playbook is :

• name: share | create | create share with dict
  netapp.ontap.na_ontap_cifs:
  state: present
  comment: "{{ nas_share_comment | default('Ansible managed') }}"
  share_name: "{{ nas_share.name | default(nas_share_name) }}"
  path: "{{ nas_share.nas_path | default(nas_share_path) }}"
  vserver: "vs_{{ target }}"
  hostname: "{{ nas_hostname }}"
  username: "{{ nas_username }}"
  password: "{{ nas_password }}"
  https: true
  validate_certs: false

I use a dict nas_share containing a SDDC definition of the share (subtree of a full SVM description in fact)

This means, I have to check accross the board whether such share name is already being used.

Unless this is a missing check from the Ontap Ansible module

[edgy heron]

okay. Understood! I will test it on myside and let you know. I will also let Ansible team to check this issue. Please share the ansible verbose logging so it will be easy trace the issue

Are you looping the dictionary for this task execution?

[lost night]

A few more input : share create failed using CLI if share already exists

Issue would consequently in Ansible module

Same behaviour with GUI as for CLI

Can you remind me the flag to have ansible detailed log ?

I'am looping the dict for task execution. I mean , the full dict describes the full SVM with volumes, qtrees, shares, export, quotas.

I deal with share subtree using share playbook.

This is just a dict such as :

shares:
# True is needed to use default value if nas_svm_share_name == '' (Jenkins case)
name: "{{ nas_svm_share_name | default(nas_svm_vol_exp, true) }}"
nas_path: "{{ nas_svm_vol_path }}"
nas_comment: "Ansible managed"

    rules:
      # Remove default share access
      - user_or_group: 'Everyone'
        permission: 'full_control'
        state: 'absent'
      # User access rw
      - user_or_group: "{{ nas_cifs_user | default('') }}"
        permission: 'full_control'
        state: 'present'
      # Read only access
      - user_or_group: "{{ nas_cifs_user_ro | default('') }}"
        permission: 'read'
        state: 'present'
      # Read write access
      - user_or_group: "{{ nas_cifs_user_rw | default('') }}"
        permission: 'change'
        state: 'present'
      # Admin access
      - user_or_group: 'ADDOMAIN\xxxxxxxxxxxxxxxxxxxx'
        permission: 'full_control'
        state: 'present'

Once the share is created (without error), I continue to update the share (using only the name ...!!!) to set access. This is where it hurts when 2 shares have the same name.

[edgy heron]

Hi Remi, ignore my previous update. I did a detailed testing in lab. what I'm seeing is Ansible is not creating 2 share with same name, actually it's updating the share path with later entry.

Actually ansible is idempotent, which means if existing resource name is provided it will assume you are trying to modify the resource. This is Ansible behaviour. So you need to ensure the share name is unique always.

For example, if you executed share 'SHARE_TEST"' with path /vol/ansitest002sas_data1/qtree1 first it will create it if doesn't exists and if it exists it will try to update it if there config differences. Now later if you run ansible again with "SHARE_TEST" with path /vol/ansitest002sas_data2/qtree1, now ansible will assume that you want to move "SHARE_TEST" from path "/vol/ansitest002sas_data1/qtree1 " to "vol/ansitest002sas_data2/qtree1", so it will actually update the path.

In CLI / GUI duplicate entry alert is posted because operation you are trying is create. But ansible will assume modify if the resource name already exists.

Hope this explains

[lost night]

Hello Durai,

This is a clear explanation. I was expecting such explanation.

Thx for your responses