Issue
- The users who have CageFS enabled have the issue with the mail pipe - their emails are bounced back:
------ pipe to |/usr/local/cpanel/bin/autorespond
<mailto:username@domain.com> username@domain.com
/home/user1/.autorespond
generated by <mailto:username@domain.com>
username@domain.com ------
You are not authorized to run this command - You can see the following errors in email logs:
2020-04-12 21:49:46 1f6jA9-004Fzw-OF ** |/usr/local/cpanel/bin/autorespond username@domain.com /home/user1/.autorespond (username@domain.com) <username@domain.com> R=virtual_aliases_nostar T=cagefs_virtual_address_pipe: Child process of cagefs_virtual_address_pipe transport returned 1 from command: /bin/cagefs_enter
2020-04-12 21:49:46 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> -E1f6jA9-004Fzw-OF
2020-04-12 21:49:46 1f6jAA-004G13-Ab <= <> R=1f6jA9-004Fzw-OF U=mailnull P=local S=6651 T="Mail delivery failed: returning message to sender" for test@gmail.com
- If you disable the CageFS, the autoresponders begin to work.
Solution
There could be several reasons why users with CageFS enabled have those problems. Here's the list of the most common issues that cause it.
- Make sure that the proxyexecd service is running:
# service proxyexecd status
If it doesn't work, start the service:
# service proxyexecd start
- The /etc/cagefs/proxy.commands file should contain the following entries:
# cat /etc/cagefs/proxy.commands | grep send
If your /etc/cagefs/proxy.commands file doesn't have the lines above, add those lines and restart the proxyexecd service:
SENDMAIL=/usr/sbin/sendmail
SENDMAILQ=/var/qmail/bin/sendmail
SENDMAILS=/usr/sbin/sendmail.sendmail
SENDMAIL_CPANEL=/usr/local/cpanel/bin/sendmail# service proxyexecd restart
- Check the permissions for the following directories
"/usr/sbin", "/usr/bin/" and "/bin":
# ls -ld /usr/sbin
drwxr-xr-x. 3 root root 16384 Apr 11 02:36 /usr/sbin/
# ls -ld /usr/bin
drwxr-xr-x. 3 root root 40960 Apr 11 02:36 /usr/bin/
# ls -ld /bin/
drwxr-xr-x. 2 root root 4096 Apr 14 00:25 /binIf you see permissions other than 755, change them to 755 and update the CageFS skeleton:
# chmod 755 /directory/filename
# cagefsctl --force-update - If you still have the issue, try to remove the .cagefs.token file:
# rm /var/cagefs/$(cagefsctl --getprefix USERNAME)/USERNAME/.cagefs/.cagefs.token
Then, apply the changes:
# cagefsctl --update-etc
# cagefsctl --remount-all - In rare cases, the issue can be related to the ".proxyexec.log" file with incorrect data. Please check:
# find /var/cagefs -name '.proxy*' | xargs file
If there is no issue with ".proxyexec.log" files, then you should see the output like this:
/var/cagefs/XX/user1/.proxyexec.log.lock: empty
/var/cagefs/XX/user1/.proxyexec.log: data- In case of the incorrect ".proxyexec.log" file, the output will look like this:
/var/cagefs/XX/user2/.proxyexec.log.lock: empty
/var/cagefs/XX/user2/.proxyexec.log: ASCII text, with very long lines, with no line terminatorsTo fix that, remove the file:
rm /var/cagefs/$(cagefsctl --getprefix USERNAME)/USERNAME/.proxyexec.log
- In case you received such an error:
/usr/sbin/sendmail: line 33: /usr/sbin/proxyexec: No such file or directory
Reinstall the bsock package:
# yum reinstall bsock
and update CageFS:
# cagefsctl --force-update && cagefsctl -M
- In case of the incorrect ".proxyexec.log" file, the output will look like this:
Note: In case you stumble upon this last issue described in this article, contact our Support Team for further investigation and finding out the root cause. Feel free to contact us here: https://cloudlinux.zendesk.com/hc/requests/new
Comments
0 comments
Please sign in to leave a comment.