I'm running into a strange issue that I've tried to research but could find a working solution.

I'm archiving some directories in /var on my RHEL satellite server as it has abundant space to do just that until my backup server is complete. I have root privileges and use sudo -r unconfined_r -i to gain root.

I'm using rsync from the satellite server RHEL8 VM /var/monthly_staging (700 admin:admin) and pulling from another RHEL8 workstation /home/admin/monthly_staging (700 admin:admin) directory:

rsync -avh --progress [email protected]:/home/admin/monthly_staging/ ./

I've modified permissions (644 admin:admin) on the workstation directory to allow the appropriate exchange to the satellite server archive location, and 99% of the files and directories are being synced as expected. However, there is one file that keeps giving me an issue. Within one of the directories, a file called fix_publications.rake allows me to validate and rebuild the metadata on the satellite server if an incremental import goes sideways. I've validated that this file has the appropriate permissions:

-rw-r--r--. 1 admin admin 1445 Apr 13 16:37 fix_publications.rake

When I do the rsync, this is the error that I'm getting:

rsync: send_files failed to open "/home/admin/monthly_staging/may2023/misc_sat_items/fix_publications.rake": Operation not permitted (1)
  • I changed the permissions to 777 - no change
  • I tried to do an SCP pull on the file to the archive directory from the satellite working directory - Operation not permitted
  • I moved the original file (644 admin:admin) from my jumpbox to the satellite archive destination, and that transferred just fine
  • I can SCP the file in question from the workstation to my jumpbox just fine, but not directly from the workstation to the satellite /var directory.
  • I can move this file to and from either workstation or satellite server through an intermediary device, but not directly to each other.

I can't seem to move this particular file from the workstation to the backup location on the satellite server. Any ideas?

I understand I created a workaround to get the file in place. However, I'm now curious as to why I can't transfer this file from the workstation to my satellite server archive location. It seems there may be an issue on the satellite directory side, but I'm not entirely sure why.

Edit: Additional info added

[root@hernn-fsrw-001 misc_sat_items]# df -T fix_publications.rake 

Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/mapper/luks-5779ef65-791b-45ef-bba1-bd0835b1a6dd xfs   72263196 43541412  28721784  61% /home

[root@hernn-fsrw-001 misc_sat_items]# ls -ldZ fix_publications.rake 

-rw-r--r--. 1 admin admin staff_u:object_r:user_home_t:s0 1445 Apr 13 16:37 fix_publications.rake

[root@hernn-fsrw-001 may2023]# ls -ldZ misc_sat_items/

drwxr-xr-x. 2 admin admin staff_u:object_r:user_home_t:s0 116 Jun  9 13:14 misc_sat_items/

Issue resolved - Hauke Laging was on the right track with security, so I set selinux to permissive - transfer failed, checked extended attributes - none were appended, and stopped fapolicyd - was the culprit

  • What is the output of ls -ldZ /home/admin/monthly_staging/may2023/misc_sat_items /home/admin/monthly_staging/may2023/misc_sat_items/fix_publications.rake ; df -T /home/admin/monthly_staging/may2023/misc_sat_items/fix_publications.rake? Jun 28, 2023 at 20:22
  • Added info, thanks for taking a look Jun 28, 2023 at 22:58
  • A general hint: I don't know what exactly your descriptions I moved the original file from my jumpbox to the satellite archive and I can SCP the file in question from the workstation to my jumpbox just fine mean. You should add the command lines and the information on which host they were executed as which user. Jun 29, 2023 at 9:16

1 Answer 1


I admit this is only half an answer. I guess I found the problem but not being familiar with that technology I cannot tell you how to fix it.

This very much seems to be SELinux-related:

  • The permissions for the parent directory are OK.
  • Given that the parent directory and the file are owned by the accessing user it doesn't matter whether ACLs are in place.

You did address the SELinux issue but only on the satellite server and it is in use on the workstation, too.

Or not

Sorry, I just realize that my SELinux guess seems to be wrong. I will post this anyway as it contains some helpful thoughts.

I just notices that the SELinux settings are the same for the file and the parent directory. So SELinux would either block both or allow both. If access to the parent directoryx was blocked then not even the file name could be ready by rsync.

  • That was a good call. However, I modified selinux to permissive, and the transfer still failed. I also looked into extended attributes using lsattr on the file, and none are appended. I did just turn off fapolicyd and the transfer went through. It looks like I'll need to modify the policy on the workstation to get it to go. Thanks for all the help, you were on the right track with security. Jun 29, 2023 at 16:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .