Unable to write to your .htaccess or nginx.conf file.

I too have this issue, just updated to iThemes Security 4.0 and whether .htaccess has 0644 or 0444 it presents this message…

If you go to the admin backend, click on Security -> Dashboard. Scroll all the way down and you will see a section with the title of “Rewrite Rules.” Information in this section is what you can copy and paste in your .htaccess file.

If you go to the admin backend, click on Security -> Dashboard. Scroll all the way down and you will see a section with the title of “Rewrite Rules.” Information in this section is what you can copy and paste in your .htaccess file.

The old Better WP Security did this just fine and displayed all required changes but iThemes Security doesn’t.

As I use iTS in conjunction with other security packages I’d like to see all changes required to .htaccess and wp-config.php so I can generate them myself. Basically, because iTS does not lock the .htaccess or wp-config.php files and currently leaves them open for the public to view – even when the “protect core files” option is checked.

PeteGeek, it is best for you to use a FTP client such as FileZilla and set the file permissions for your .htaccess file.

I’m having the same problem. Which are the right permissions for the .htaccess file?

I’ve also seen this today. I have five domains set up the same, and decided to change some of the settings (SAME changes for each of the domains) after updating the iThemes Security plugin on all of them.

All changes went fine on three of the five domains, but one of the domains kept giving the same message others are seeing “Unable to write to your .htaccess or nginx.conf file” and would not make the changes I selected. After trying to make them 5 or 6 times, the message stopped appearing, and the changes finally “took”!

I made one more change after that, and I now have these messages displaying on my iThemes Security “Settings” page at the top:

Unable to release a lock on your .htaccess or nginx.conf file. If the problem persists contact support.

Unable to release a lock on your wp-config.php file. If the problem persists contact support.

even though the changes WERE made!

On the fifth domain, the first time I tried to make a change of the setting “Disable PHP in Uploads” (to true) I got “Are you sure you want to do this?” and the change was NOT made – I tried changing it again and it “Took” on my second attempt – Very Strange Behavior on both the domains that were acting like the plugin didn’t want to let me make changes – and then let me after repeated attempts and without ANY other changes in between attempts!

So (even though I have checked the box labeled:
Allow iThemes Security to write to wp-config.php and .htaccess.)-

Where there used to be a list of rewrite rules on my dashboard for each of these domains (before the change/update from BWPS to iThemes Security), there is now only the notices:

Rewrite Rules
There are no rules to write.

wp-config.php Rewrite Rules
There are no rules to write.

which makes no sense – since there ARE still rewrite rules listed in the .htaccess file and a whole section that starts with “Begin iThemes Security” and includes a section “#Begin Hide Backend” with a rule to change the login slug- which is followed by “#End Hide Backend” but not the other hide backend rule BWPS had to hide the wp-admin folder . . .?

I suspect this omission has to do with compatability – for other plugins that need access to the wp-admin folder – but aren’t those hackers out there adept at hacking thru the wp-admin to gain access to our sites?

I have the same issues, I’m guessing this is a big as the plugin has recently undergone a major rewrite and there are frequent updates. Hopefully will be addressed in next version.

Mauricio, the .htaccess file should have the permission of 644.

I had the same issue, using the latest version of this plugin.

I simply renamed the .htaccess file at the root folder of the relevant site to something else and strangely the “hide backend” feature is working fine now… although it should NOT work since there is no rewrite operation at the .htaccess file level.

The content of the file looks like the following:
# BEGIN iThemes Security
# BEGIN Hide Backend
# Rules to hide the dashboard
RewriteRule ^/<my-secret-text>/?$ /wp-login.php [QSA,L]

# END Hide Backend
# END iThemes Security

I think this is one of the worst upgrade moves I’ve seen for a long time.

PeteGeek, it is best for you to use a FTP client such as FileZilla and set the file permissions for your .htaccess file.

I do. In fact I’m required to check them every time any plugins, not just iTS, updates. Just good practice to do so.

I’m having the same problem. Which are the right permissions for the .htaccess file?

Set the permissions as follows:
.htaccess – 404
index.php – 400
wp-config.php – 400
wp-blog-header.php – 400

Basically, because iTS does not lock the .htaccess or wp-config.php files and currently leaves them open for the public to view – even when the “protect core files” option is checked.

I thought this section inside the iThemes Security section of the .htaccess protects those files. Is that incorrect, and the public can get around these rules in the .htaccess file?

# BEGIN Tweaks
# Rules to block access to WordPress specific files
<files .htaccess>
Order allow,deny
Deny from all
</files>
<files readme.html>
Order allow,deny
Deny from all
</files>
<files readme.txt>
Order allow,deny
Deny from all
</files>
<files install.php>
Order allow,deny
Deny from all
</files>
<files wp-config.php>
Order allow,deny
Deny from all
</files>

# Rules to disable XML-RPC
<files xmlrpc.php>
Order allow,deny
Deny from all
</files>

# Rules to disable directory browsing
Options -Indexes

<IfModule mod_rewrite.c>
………………
……………” etc.

so whats the solution?

Faced this issue as well. Noticed it only after I upgraded to 4.0.7.
Here was what happened. I had previously upgraded to 4.0.3, rolled back to 3.6.6 after issues with the hide backend feature. When 4.0.7 was released, decided to try my luck again with version 4.0.7 and that was when this issue floated up.
I tried going into FTP to change my htaccess file permission from 404 to 644 but no luck. Also changed my wp-config from 444 to 644 but again no luck. Plugin still says “unable to release lock.”
I then decided to deactivate the plugin and it immediately broke my site. Contacted my webhost and was told that these lines were written into my wp-config file.
define( ‘FORCE_SSL_LOGIN’, true );
define( ‘FORCE_SSL_ADMIN’, true );
The funny thing is that I did not even use the SSL feature in the plugin so not sure why those lines were even triggered.
When the webhost removed the above lines, I was able to login again via wp-admin. Given the bad experience, I once again rolled back to 3.6.6.
I am now monitoring this support forum for the date when all issues are solved before trying to upgrade once more.
Meanwhile, does anyone know why this is happening i.e. the statement that it is “unable to release lock” as well as the lines forcing SSL?

had to roll back to previous version, having this same issue even when changing file permissions. Any one having success to solving this?

Had to roll back to previous version since having thi same issue, even when changing file permissions. Any success solving this?