Environment: Windows 10 laptop running Oracle VirtualBox + CentOS 8. Ansible 2.10.10 (team's current development standard). Filesystem on the VM is XFS (didn't have an option about that when creating the VM).
I've been working on a gnarly playbook (nearly finished with the darned thing, too) when I added a another "include_tasks" statement and the playbook got even gnarlier when it refused to load the file. The error message it spits out says that it "Could not find or access <path-to-file> on the Ansible controller."
The contents of the problem file is nothing but a "debug/msg" statement followed by a series of "set_facts". Nothing special and files like that have never been a problem in the past.
The main playbook is issuing something like:
Code:
- include_tasks: tasks/init_parms.yml
The security settings on the file and the "tasks" subdirectory are fine. I own them and permissions are 664. I can "stat" the file, run "ls -l" on it, "cat" it at a shell prompt but
anything I try to with that file from within Ansible fails with that (essentially) "file not found" message. I've even preceded the "include_tasks" with:
Code:
- name: "access file via shell"
shell: <cmd> tasks/init_parms.yml
register: shell_output
where "cmd" has been set to "stat", "ls -l", "cat", you name it. The result is always the same: "Cannot find or access"
Substituting the name of a
different file from that subdirectory? The above code snippet works perfectly.
Trying to open the file using:
Code:
- set_fact:
file_contents: "{{ lookup( 'file', 'tasks/init_parms.yml' }}"
returns the same error message.
I've looked at the directory holding the file using Emacs and vi and don't see any control characters that occasionally get into file names.
I've copied the original file I've been trying to include to different files/different names and tweaked the playbook to try and access the new file... same error.
Moved the problematic "include_tasks" statement to just before another similar to it and the statement crashes in it's new location so
where it appears in the main playbook doesn't matter.
None of this looks to some Ansible or YAML syntax problem---at least as far as yamllint can see (other than "line too long" warnings) and Ansible always catches stupid typos before even running the playbook.
I was thinking that, maybe, the "include_tasks" could be having trouble with a long path -- the length of the fully qualified path to the file is 114 characters (the filename has some equipment model numbers as a prefix) -- but other "problem-free" files accessed with "include_tasks" are in the same directory and some have longer filenames.
What I find odd about this is that the file that I'm unable to access is not even the first file I'm including from that directory (it's the 9th or 10th out of 36 total). None of the preceding "include_tasks" are having any trouble reading files in.
If I comment out the "include_tasks" line that's causing the error, the playbook happily runs until it eventually runs another "include_tasks" that pulls in a set of tasks that need parameters in the file that Ansible cannot include resulting in the playbook crashing (due to undefined variables, etc.). No big surprise there.
I mentioned XFS at the beginning in case someone knew of strange errors occurring while running Ansible on XFS. (This VM is the only case where I've ever used XFS.)
Any ideas what could be causing Ansible to be unable to access the file that all the other tools I've tried -- outside Ansible, that is -- are able to access without any trouble?
TIA...