Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
ERR_TOO_MANY_REDIRECTS Question Question
How to prevent bad caching on Users Browsers with Virtual Hosts on NGINX Question Question

Question

iThemes security says "The file path supplied in NGINX Conf File is not writable." Do i need to make this file writable? if yes, by who?

Posted February 17, 2017 7.1k views
NginxUbuntu 16.04

“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.?

Add a comment
unicornomy
By:
unicornomy

Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
ERR_TOO_MANY_REDIRECTS Question Question
How to prevent bad caching on Users Browsers with Virtual Hosts on NGINX Question Question

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
2 answers
UKn0Me February 17, 2017

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.

Reply Report
  • unicornomy February 17, 2017

    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?

    Reply Report
    • UKn0Me February 17, 2017

      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

      Reply Report
jtittle1 February 18, 2017

@jaimamtani

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.

Reply Report
  • jtittle1 February 18, 2017

    @jaimamtani

    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
    Reply Report
    • unicornomy February 20, 2017

      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?

      Reply Report
      • jtittle1 February 20, 2017

        @jaimamtani

        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.

        Reply Report

Related

Looking for something else?

Ask a new question Search for more help