Author Topic: must always fix user's permissions for Softaculous cron jobs  (Read 3438 times)

0 Members and 2 Guests are viewing this topic.

Offline
*
must always fix user's permissions for Softaculous cron jobs
« on: January 06, 2022, 01:51:24 AM »
Hello crowd,

Perhaps someone can enlighten me on what may be wrong with my CWP running on Centos 7. I noticed the exact same behaviour on two separate servers so far - Vultr deployments both, using the Vultr template.

I have to use "Fix user permissions" every time I install or save installation details of a Softaculous app, otherwise the corn jobs are not showing in the user's control panel and the backups are not running.

Did someone else encounter this, and is there something, in particular, that may be misconfigured?

Thanks in advance

Offline
*
Re: must always fix user's permissions for Softaculous cron jobs
« Reply #1 on: January 06, 2022, 11:25:44 AM »
what are permissions on the file before and after fix?

ls -la FILANAME

user crons are in the file
/var/spool/cron/USERNAME
VPS & Dedicated server provider with included FREE Managed support for CWP.
http://www.studio4host.com/

*** Don't allow that your server or website is down, choose hosting provider with included expert managed support for your CWP.

Offline
*
Re: must always fix user's permissions for Softaculous cron jobs
« Reply #2 on: January 07, 2022, 12:43:31 AM »
Thanks for replying, much appreciated!

-rw------- 1 root root 657

After fixing the permissions and saving the installations several times, I managed to see the cron jobs in the users' area, but even if I run them manually I get no backups done.

No changes were made on these systems except through the CWP interface.

Offline
*
Re: must always fix user's permissions for Softaculous cron jobs
« Reply #3 on: January 07, 2022, 01:31:59 AM »
Further info:
definitely something wrong with how user permissions are handled:
I just installed SuiteCRM and got an Internal server error and this in the logs: "End of script output before headers: index.php"
Once I ran the "fix permissions" for the user, it all worked out ok.