ansible.builtin.file fails to change permissions on hard links unless you explicitly define 'state: file'

[rhino5oh]

Summary

When using the file module to iterate over a list of files, some of which could be hardlinks, the file module fails with "src is required for creating new hardlinks" However, I am simply trying to modify the permissions of the files, not create new ones.

For example, I gather the list of files like so (keep in mind some of these are regular files, some of them are hardlinks):

  - name: Finding all *.crt files in the pki directory
    find:
      paths: "{{ item }}"
      patterns: '*.crt'
    loop: "{{ crt_directories }}"
    register: crt_find

So at this point, crt_find is a list of files and hard links.

Then, I iterate over crt_find to set the permissions on all of the files and hardlinks using the file module:

  - name: Setting certificate file Permissions
    file:
      path: "{{ item.1.path }}"
      mode: 0644
    loop: "{{ crt_find.results | subelements('files') }}"

This works perfectly fine for regular files. When it gets to a hardlink, it fails with "src is required for creating new hardlinks." The problem is, I'm not trying to create a new hardlink. I'm simply trying to modify the permissions.

Interestingly, this goes away if I explicitly define state: file as a parameter on the file module task:

  - name: Setting certificate file Permissions
    file:
      path: "{{ item.1.path }}"
      state: file  # <---------------This fixes the problem
      mode: 0644
    loop: "{{ crt_find.results | subelements('files') }}"

While I've clearly found a solution to my problem, it definitely seems like a bug with the file module, as state: file is the default if omitted.

Issue Type

Bug Report

Component Name

ansible.builtin.file

Ansible Version

$ ansible --version
ansible [core 2.11.5]
  config file = /Users/me/.ansible.cfg
  configured module search path = ['/Users/me/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/me/venv/lib/python3.8/site-packages/ansible
  ansible collection location = /Users/me/.ansible/collections:/usr/share/ansible/collections
  executable location = /Users/me/venv/bin/ansible
  python version = 3.8.2 (default, Jun  8 2021, 11:59:35) [Clang 12.0.5 (clang-1205.0.22.11)]
  jinja version = 3.0.1
  libyaml = False

Configuration

$ ansible-config dump --only-changed
DEFAULT_ROLES_PATH(/Users/me/.ansible.cfg) = ['/Users/me/repos']
DEFAULT_STDOUT_CALLBACK(env: ANSIBLE_STDOUT_CALLBACK) = yaml
HOST_KEY_CHECKING(/Users/me/.ansible.cfg) = False

OS / Environment

Control machine = MacOS
Target machine = Ubuntu 20

Steps to Reproduce

Stated in the Summary

Expected Results

Stated in the Summary

Actual Results

Stated in the Summary

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibot]

Files identified in the description:

• lib/ansible/modules/file.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[mdonoughe]

If the state is not specified, Ansible tries to autodetect it instead of continuing on and trying to apply the other parameters. The autodetection sees that the file shares its data with another file record so it detects that the file is a hard link, but it doesn't know the source because hard links aren't links to files and the module doesn't support acting on inodes. Then it tries to validate that since the target file is a link that the target of the link is specified.

It looks like a similar problem would happen if there were symbolic links in the directory. In that case, Ansible could detect the current target of the link and use that as the expected target, but it doesn't, and it's probably better that way. The user didn't specify a link target so the module shouldn't set itself up to enforce that a specific target is set. It's not what the user asked for and it introduces a small chance for race conditions.

I'm not sure it should be detecting hard links differently from regular files (and it doesn't detect hard linked directories on HFS+), but probably it'd be better to just handle the case where the desired state is unspecified, the actual state is some sort of link, and Ansible shouldn't change that so it doesn't matter if the link target was specified.