If you suspect it may be selinux, try this: run: "getenforce"
This will report whether or not SELINUX is enforcing. If it is in ENFORCING, then it may. Try setting it to "permissive" which will allow access but report it in the audit log. run: "setenforce 0" Then re-run your operations. If they succeed then it is, in fact, SELINUX. Then grep for "avc" in the audit log, dmesg, and journalctl. This will display what access is denied and why. At this point you can try "restorecon" to see if it is just that a file was replaced and needs it context restored. If it is a new access pattern, you can pipe the "avc" message through "audit2allow" https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-allowing_access_audit2allow#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow > discuss-requ...@driftwood.blu.org writes: >> From: Brandon Vogel <brandon.vo...@gmail.com> >> Could it be selinux related possibly? > > Yeah, definitely check Selinux. In general, daemons have lesser > privileges than user-login processes precisely so they can't write into > random files that happen to have broad write permissions. I once gotten > mysteriously bitten by this and it took me quite a while to track down > (and figure out a workaround). My vague memory is that they don't get > the "unconfined" privileges. > > Dale > _______________________________________________ > Discuss mailing list > Discuss@lists.blu.org > https://lists.blu.org/mailman/listinfo/discuss > _______________________________________________ Discuss mailing list Discuss@lists.blu.org https://lists.blu.org/mailman/listinfo/discuss
