Thanks, Brian. I appreciate that the error message is outdated, but I'm still confused about what the actual problem is in this case. When I did add the ansible_remote_tmp variable to the inventory, it did seem to have *some* of the desired effect, in that the paths reported in the error message seemed to reflect that path, except for the one path that appeared to be a relative path (don't know why).
To recap: I added the var to the inventory line for that computer, and it had an effect but didn't solve the problem. The error reported is a 127, and of course error numbers need a context. If this is looked in the context of general linux errors, 127 would appear to indicate that the command isn't found. My reading of the command we were attempting to execute is that the only commands in that string are umask, mkdir, and echo, and if I ssh to the computer in question I can execute all of those with no problem. And yes, I am connecting as the same user that ansible is using. But perhaps the 127 is an ansible error and means something different (though my googling tends to suggest this is not the case). I'm sort of lost in either case. On Thursday, January 5, 2023 at 12:09:03 PM UTC-5 Brian Coca wrote: > The message is outdated, 'ansible.cfg' is not the only way to > configure this, your shell plugin (sh in this case) is configurable in > many ways, ansible.cfg is just one, you can also set a environment > variable or an ansible variable (this last one can go in many scopes, > from per run to per host and everything in between). > > -- > ---------- > Brian Coca > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e95b6ac1-70ec-4f81-a505-9fbe5cb521den%40googlegroups.com.
