Thread

I was wondering if there was a better way to avoid the chmod() Operation Note Permitted errors in my log file. The CI code that attempts to do the CHMOD function precedes it with the @ sign to suppress errors.

Here is what is happening….

My production site is deployed from GitHub. Immediately after deployment I run a shell command to change all ownership of all files to www-data:www-data.

I am running Ubuntu 14.04 with Apache 2 on an EC2 Instance (Amazon).

The error shows up immediately when logging.

I then delete and re-add the Logs directory setting permissions to 777….still get the error
I then tried changing the owner of the folder to root:root (since the log files created by the script are owned by root)...still get the error.

Is there a way to disable this specific error from being logged and taking up 40% of my log?

If I did not provide enough details let me know.

Do you know if you are running phpSuExec on the remote server? 777 permissions are not allowed when running phpSuExec and can actually be responsible for generating errors.

According to phpinfo(); the “Server API” is “Apache 2.0 Handler” which according to various forums on google typically indicate that phpSuExec is not running.

However, I have noticed that while all files and folders belong to “www-data:www-data”, the log files created by codeigniter are created under “root:root”, which would seem to indicate that the root user is in fact running the php. Is that right? I would need to change it in that scenario to make sure that the root user is not running php correct?

You certainly do not want to be running PHP as root. Is your Apache user called www-data? It is normally called “nobody” but perhaps your server is running it under a different name. Since the Server API is listed as Apache 2.0 Handler, it sound like you are most likely using DSO as your PHP handler, which means you would not be using phpSuExec.

It is probably worthwhile to figure out why the root user is creating anything on your web server. When you are running DSO, both file permissions and ownership are important. When you start mixing different users, it can get complicated.

Thanks for the info. I’ll look more into this.

I discovered my problem. So simple. (as always).

My log files were often being created by root:root, which didn’t make sense because I didn’t have php running as root, I verified it was running as www-data.

I realized my mistake was in my Cron Jobs file.

When I setup my cron jobs, I ran the command “sudo crontab -e” instead of just “crontab -e”. essentially, the scripts being called by the cron job where running as root, which was causing the files to be created by root and therefore the weird permission errors. When I moved my cron jobs to the non-sudo version of crontab, they worked fine and the errors went away.