XF 1.5 Cannot install add-ons - mkdir(): permission denied

[jflory7]

Hello XenForo community,

I recently was trying to install a new add-on to my forum community, when I ran into a new issue. Whenever I try to install the add-on from its XML file, I get the following error:

mkdir(): Permission denied

I have double-checked everything I thought should be correct on my machine, and have the following:

• Ran chmod -R 777 on both data/ and internal_data/
• Public web directory is owned by my user account and the apache account group
• SELinux permissions have been recursively restored to all of my virtual hosts (I am running this on a RHEL 7 box)

I'm confused about what the problem is and I cannot figure out what's wrong. Any thoughts? Thanks!

 

[Chris D]

It looks like the error is specifically happening during the install step of a specific add-on, therefore it would be most appropriate to contact the author of the add-on you're trying to install for support.

 

[jflory7]

It looks like the error is specifically happening during the install step of a specific add-on, therefore it would be most appropriate to contact the author of the add-on you're trying to install for support.

Thanks for the tip, I will contact the developer.

 

[Gossipy]

Thanks for the tip, I will contact the developer.

I assume you were able to fix this; what was the issue? We're having a problem with a different add-on and looking for solutions to the same error. Like you, we have all our permissions set correctly and everything else (all other add-on installs and updates) has worked fine in the past.

 

[jflory7]

I assume you were able to fix this; what was the issue? We're having a problem with a different add-on and looking for solutions to the same error. Like you, we have all our permissions set correctly and everything else (all other add-on installs and updates) has worked fine in the past.

Oof. It's been so long, I can't remember what the fix ended up being, but I think it might have actually been an issue with SELinux and the web directory not being labeled properly for a web application? I know that for SELinux, you need the data/ and internal_data/ folders to be writable by the group too, and this fixed many issues for me. I can't remember if this was the same case here, but I'm inclined to say it was.

 

[Gossipy]

Oof. It's been so long, I can't remember what the fix ended up being, but I think it might have actually been an issue with SELinux and the web directory not being labeled properly for a web application? I know that for SELinux, you need the data/ and internal_data/ folders to be writable by the group too, and this fixed many issues for me. I can't remember if this was the same case here, but I'm inclined to say it was.

Thanks. The main issue is that the plug-in can't make a needed directory (which is obvious by the mkdir) but we didn't know which one. The plug-in developer asked us to make a directory off the forum root with the right name. When we did that the install went perfectly. Trick was finding out which name the particular plug-in was expecting.

 

[jflory7]

Thanks. The main issue is that the plug-in can't make a needed directory (which is obvious by the mkdir) but we didn't know which one. The plug-in developer asked us to make a directory off the forum root with the right name. When we did that the install went perfectly. Trick was finding out which name the particular plug-in was expecting.

The more I think about it, the more I'm almost certain this was an SELinux issue. You need to make sure data/ and internal_data/ are labeled to have read/write permissions by the web server. You can temporarily relabel the directories with these commands (but note, they won't persist after a reboot).

$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/data
$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/internal_data

After running these commands, try installing the plugin again. If it works, then this is the cause of the problem. However, it's best to build a long-term solution that (1) lets you use XenForo as you wish, and (2) doesn't disable SELinux. To do that, you'll need to create a custom SELinux policy that will persist these changes after a reboot or relabel. It's not hard to do, and you can create the policy with these commands:

$ sudo semanage fcontext -a -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/data(/.*)?
$ sudo semanage fcontext -a -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/internal_data(/.*)?

Once you run this, your change will persist and you won't have to worry about running chcon every time you reboot or if the context ever changes. This is what I'm currently doing on my XF install.

 

[Gossipy]

The more I think about it, the more I'm almost certain this was an SELinux issue. You need to make sure data/ and internal_data/ are labeled to have read/write permissions by the web server. You can temporarily relabel the directories with these commands (but note, they won't persist after a reboot).

$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/data
$ sudo chcon -R -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/internal_data

After running these commands, try installing the plugin again. If it works, then this is the cause of the problem. However, it's best to build a long-term solution that (1) lets you use XenForo as you wish, and (2) doesn't disable SELinux. To do that, you'll need to create a custom SELinux policy that will persist these changes after a reboot or relabel. It's not hard to do, and you can create the policy with these commands:

$ sudo semanage fcontext -a -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/data(/.*)?
$ sudo semanage fcontext -a -t httpd_sys_rw_content_t /var/www/forum.mysite.com/public_html/internal_data(/.*)?

Once you run this, your change will persist and you won't have to worry about running chcon every time you reboot or if the context ever changes. This is what I'm currently doing on my XF install.

Thank you. I hope this is helpful for users of SELinux. It's disabled on our server, but I know it probably shouldn't be. Believe it or not we do have good security protocols in place, but I realize SELinux should be on and you've reminded me to ask our host (right now) to help us do that.

 

[jflory7]

Thank you. I hope this is helpful for users of SELinux. It's disabled on our server, but I know it probably shouldn't be. Believe it or not we do have good security protocols in place, but I realize SELinux should be on and you've reminded me to ask our host (right now) to help us do that.

When you have it running, you'll want to remember to use these commands (if you have shell access that is, not sure if you do or if it's a shared host).