Disable permissions change in ftpquotacheck?

[mathuaerknedam]

When /usr/local/cpanel/scripts/ftpquotacheck runs, it changes the permissions of public_ftp to 0770, which breaks web access via a symlink in public_html to the ftp space. Despite the interval being set to 30 days, it has happened the last three time it has run. I have since set the interval to 365000, but I'm not confident this will work.

I don't need quotas, is there a way for me to disable ftpquota check that won't be undone by a future update to CPanel?

Thanks.

 

[cPanelMichael]

Hello,

When /usr/local/cpanel/scripts/ftpquotacheck runs, it changes the permissions of public_ftp to 0770, which breaks web access via a symlink in public_html to the ftp space

Could you provide us with detailed step-by-step instructions on how to reproduce this behavior?

As far as a temporary workaround, you could setup a hook for the upcp process that runs a scripting during the "pre" stage to disable the FTP server, and then runs a script again during the "post" stage to enable the FTP server. This would prevent the ftpquotacheck from running, but FTP would be disabled for the duration of the cPanel update process. Here's a thread with an example of how to use hook:

/scripts/upcp does not display output from postupcp

Here's a document for the WHM API 1 command you can use to enable and disable FTP:

WHM API 1 Functions - configureservice - Software Development Kit - cPanel Documentation

Thank you.

 

[mathuaerknedam]

Thanks for the suggestion. Unfortunately, a temporary disabling of FTP wouldn't be an acceptable solution for us.
FWIW, we first encountered this problem Oct 29, and then again Nov 29. This has a positive correlation with the interval value. However, it occurred again Nov 30. The only possible explanation Ive come up with is that the Nov 29 upcp reported a problem:

[2017-11-29 00:39:36 -0600] E Pre Maintenance ended, however it did not exit cleanly (256). Please check the logs for an indication of what happened​

But this was well after ftpquotacheck completed:

[2017-11-29 00:36:40 -0600] - Processing command `/usr/local/cpanel/scripts/ftpquotacheck`
[2017-11-29 00:36:40 -0600] [/usr/local/cpanel/scripts/ftpquotacheck] Ftp Quota Check v2.0
[2017-11-29 00:36:40 -0600] [/usr/local/cpanel/scripts/ftpquotacheck] [ftpquotacheck] Setting I/O priority to reduce system load: best-effort: prio 6
[2017-11-29 00:36:40 -0600] [/usr/local/cpanel/scripts/ftpquotacheck] Processing cPanel Account "hdfgroup":
[2017-11-29 00:36:41 -0600] [/usr/local/cpanel/scripts/ftpquotacheck] hdfgroup : ftp (/home/hdfgroup/public_ftp)...rebuilt
[2017-11-29 00:36:41 -0600] [/usr/local/cpanel/scripts/ftpquotacheck] Done
[2017-11-29 00:36:41 -0600] - Finished command `/usr/local/cpanel/scripts/ftpquotacheck` in 1.047 seconds
​

I noticed that ftpquotacheck contained:

chmod 0770, $ftphome; # ensure GID can write to it​

So I ran it again to see if it would change again, and it did. So despite the 30 day interval, the permissions were changed for 3 consecutive runs within 48 hours. Further research shows me the interval setting, which I changed to 365000, and the next run of ftpquotacheck did not change permissions. A manual run of upcp also did not change permissions, but I'm sure you can understand that I don't trust it.

The simplest way to reproduce the problem is to change the permissions from 770, change the interval to 1, and manually run ftpquotacheck. As expected (apparently working as intended), the permissions get changed to 770.

As much as I like octal, I have to wonder if that's really the best way to do this. It seems like it would better perform the task in the comment use symbolic mode g+w so that other permissions aren't needlessly overwritten. Something like that would prevent my problem where I need o+rx.

Thanks.

 

[cPanelMichael]

Hello,

Could you open a support ticket using the link in my signature so we can take a closer look at how the public_ftp directory is setup on the affected account?

Thank you.

 

[mathuaerknedam]

Thanks, I've opened ticket 9084271.

 

[mathuaerknedam]

My support ticket is resolved. The problem is related to how permissions are set due to the fact that we have anonymous downloads enabled. All of the things that apparently *should* prevent the permissions from changing did not, and there doesn't appear to be a functional "right way" to accomplish this. In the end, I have the interval set to 365000 days, an empty .ftpquota file (which should prevent ftpquotacheck form running even if it thinks the 365000 days have elapsed), and a cronjob that runs every 5 minutes between 00:00 and 00:55 to check perms, fix perms (if needed), and send an email notification that there was some downtime.

Three layers of workaround ought to be sufficient!