“The file path supplied in NGINX Conf File is not writable. Please supply a file path that can be written to.” - Basically iThemes is trying to modify the nginx.conf file for certain settings and is unable to do so? Do I need to create a symlink etc. to make sure everything is working fine with iThemes.?
You’ll need to change the owner to either www-data or nginx on newer versions of nginx, you can see which by looking at the user specified in /etc/nginx/nginx.conf.
To change the owner of a file or directory you use chown like so:
chown -R www-data /var/www
Breaking this down, the -R option makes chown act recursively, changing the owner of any subdirectories or files, replace www-data with the user you want to be the owner of specified files/directories and /var/www is said file/directory.
Hi @UKn0Me
Thanks for the prompt revert. I have two users one is root and the other subuser with sudo privileges is “xyz” so who should the ownership be transferred to? Sorry noob at nginx.
Also, “xyz” is already the owner of major files like wp-content and uploads but is it safe to give write permissions on nginx.conf?
In nginx.conf, a user value is specified, which is what nginx uses to read/write content. Ideally you’d want to change the user of your content to the one specified in nginx.conf to allow nginx to write. Alternatively you can change the permissions of files or directories with chmod, giving nginx’s user write permissions
Since you’re using NGINX and PHP-FPM, your files and directories should be owned by the user that is running the PHP-FPM process, not the NGINX user. When you’re using PHP-FPM, NGINX is not handling reading/writing to your files, PHP-FPM is. Even if NGINX were, you don’t want the web server to handle your files for you, PHP-FPM should be.
You can change in to your PHP-FPM directory and check the file in ./pool.d to see who the process is running as.
i.e.
cd /etc/php/*/fpm/pool.d
ls -al
You should see either www.conf or default.conf. Use nano to open that file.
nano www.conf
In this file, look for:
user =
group =
and
listen.owner =
listen.group =
On a default setup, all four of those should be set to the same user which is normally www-data. In such a case, your files and directories should be owned by www-data.
If you’re web root is /var/www then simply run:
chown -R www-data:www-data /var/www
and then try writing again.
The above should still apply even if it’s trying to write to nginx.conf as this file should reside in your web root. The same file is created and used by the W3 Total Cache plugin.
Once the file is writable, however, you need to make sure that you include it in your server block. By default, NGINX doesn’t know about that file, so even if you write to it, none of the configuration within it will work until you do.
For example, if your web root is:
/home/username/public_html
The above file should be located at:
/home/username/public_html/nginx.conf
And inside your server block, you’d need to add:
include /home/username/public_html/nginx.conf;
and then reload NGINX.
systemctl reload nginx
or
service nginx restart
Hi @jtittle Thanks for the descriptive replies. I think what you wrote in your last comment makes sense to me but I have one question - how do I ensure the same nginx.conf file is present at two different locations and is updated at both location simultaneously?
The nginx.conf file that resides in /etc/nginx/nginx.conf is your main configuration file and like others, it’s read when NGINX is started, restarted, or reloaded.
If changes are made to either the nginx.conf file in the above directory, or the one that is in your web root (i.e the one created by your security plugin), NGINX will need to be reloaded each time for the changes to take effect and actually work.
NGINX reads configuration at startup, or when reloaded, which is why you must do one or the other when you make changes.
The only way to make sure the configuration that is placed in the nginx.conf file in your web root is read is to include it in your websites server block using an include, such as:
include /home/username/public_html/nginx.conf;
Your server block isn’t the one that starts with http {, rather, it’s the one that starts with server {, so you’d need to add that include statement above (and modify the path to match that of your actual web root or the location of the file created by your security plugin).
You would then need to restart or reload NGINX.