Adam Winter asked:
First, let me say that chmod 777 does not even work for this (though I know that would not be the correct solution).
Here’s the situation: I have a mail server receiving mail. On that server there is a cronjob that runs a .sh script that moves the mail files to a samba share. A separate app server (which is where I’m having the problem) also has a cronjob that runs a .sh script that moves those mail files from the share:
#!/bin/sh if [ "$(ls -A /samba/reports)" ]; then mv /samba/reports/* /home/adam/dmarc/reports/mail chown adam:adam /home/adam/dmarc/reports/mail/* chmod 664 /home/adam/dmarc/reports/mail/* fi
This all seems to work just fine. Note, the cronjob is run as root (it’s root’s crontab). Also, the ‘reports’ directory is mounted as a volume inside a php:apache Docker container (-./reports:/var/www/reports:z). The files are there and available to read within the container. However, when I use php (invoked from a script, not apache) I am denied permission to rename/move the files. However, if I cat each file to an identical file with a different name:
cat theProblemFile > noProblem
….then it works fine. Owner/group and permissions are exactly the same for both.
Is there something about the file having been moved from a Samba share that makes it different? What is going on here? Also, in the matter of getting the files from the mail server to the app server, is there an industry-standard/best-practice/preferred way of doing this?
You moved files (without the
-Z option) instead of copying them, so they carry their original SELinux contexts instead of the appropriate contexts for their destination.
When you created a new file, it had the correct SELinux context already.
You can use
restorecon to fix the SELinux contexts on the affected files, for example:
restorecon -rv <directory>
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.