I am trying to run the following task:
- name: copy httpd.conf to /etc/httpd/conf folder
copy: src=httpd.conf dest=“/etc/httpd/conf”
Ownership on the server is:
drwxrwsr-x 2 root developers 4096 Sep 8 13:33 .
drwxrwsr-x 5 root developers 4096 Sep 4 17:51 …
-rw-rw-r-- 1 root developers 34744 Apr 3 16:01 httpd.conf
I am a member of the developers group. The directory and file has write permission for the developers group. However the task fails with this error message:
fatal: [my-box] => failed to parse: {“msg”: “Could not replace file: /home/steinim/.ansible/tmp/ansible-tmp-1410176741.01-248154513611723/source to /etc/httpd/conf/httpd.conf: [Errno 1] Operation not permitted: ‘/etc/httpd/conf/.ansible_tmpZ7a3MQhttpd.conf’”, “failed”: true}
Am I missing something, or should this work?
Can you please share the ansible --version as well as the command line invocation you are using and the stanza of your playbook?
Sounds like you are doing something non-sudo most likely, or non root, that doesn’t have enough permissions.
Yup. It is non-sudo and non-root.
$ ansible --version
ansible 1.7.1
stanza:
Can you show more of the playbook in context?
I’m missing task names and such and wanted to be clear about something.
I may have some other questions after that.
Hello Stein, which distro are you running? I usually run into this permission issues with SELINUX on CentOS.
I have attached the whole shebang to reproduce it.
Requirements is:
- the same username on the server set up with an authorized key and belonging to a group.
- A file: /etc/httpd/conf/httpd.conf owned by a different user, but writable for the group the first user belongs to.
(attachments)
reproduced.tgz (12.3 KB)
$ sestatus
SELinux status: disabled
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)
Your attachment does not include the httpd role. Mind sharing it? I have setup what I feel is similar to your playbook and run it successfully.
I think sharing the httpd role may help in reproducing your problem.
Can you please tar up the httpd role as you have it and attach it to a reply?
Hello Stein, which distro are you running? I usually run into this
permission issues with SELINUX on CentOS.
Shouldn't be related and I want to discourage casting such impressions of
SELinux 
SELinux is pretty darn easy to manage. Filesystem permissions rarely occur
for basic copying, but there are occasions where applications need specific
handling if constrained, which can cause frustrations on
development
This does not apply to Ansible though, since it's not really serving
anything up - so no Ansible specific SELinux config is required in nearly
any case.
As a general rule, I don’t crack open tarballs attached to the list - and I would request that since there are thousands of users on this list we don’t start using it for attachments.
(I’m not sure I can turn it off).
A gist or github repo would be welcome, or even pastebin for smaller things.
In many cases, it can just be shown inline.
Sorry about the tarball. It won’t happen again.
After some further investigation it seems that it might have something to do with SELinux ACL after all. The httpd directory in /etc/httpd/conf has a dot after its access list (drwxr-xr-x.). I don’t know if this is the problem yet, but I will do some further investigations. Thanks for mentioning SELinux.
I will keep you posted.
Yeah, please let us know.
One point of clarification - I think you may possibly be confusing SELinux and ACLs, which are different things.
ACLs do not come from SELinux, they are managed by setfacl/etc.
(There’s also a handy acl module in Ansible!)
Hi!
It took some time before i could look into this. Anyway, I think it has to do with this issue: https://github.com/ansible/ansible/issues/7372
The template-module always does chown, and that will not work when running as a non-root user when the files are owned by root even if the group has write permission.
kl. 14:35:36 UTC+2 onsdag 10. september 2014 skrev Michael DeHaan følgende:
Can you please share what version of Ansible you are using?
(ansible --version)
Thanks!
From earlier on the thread 1.7.1
And yes, there have been some fixes to the devel branch related to owner and group since 1.7.1 that might be the cause of this. In addition to the two you’ve linked to, Stein, I believe there’s a third where specifying the file name rather than the directory as the destination was a work around.
If you can checkout the development branch from git to test, that would confirm whether we’ve already fixed this for the next version or not. Some of those fixes may also have been pulled into the 1.7.2 release - the timing is right but I don’t recall whether they were added to that release or are waiting on 1.8.
-Toshio
It works
I am using 1.8.1.
kl. 17:54:30 UTC+1 onsdag 5. november 2014 skrev tkuratomi følgende: