# HTML Permissions

**URL:** <https://discourse.pi-hole.net/t/html-permissions/58272>\
**Category:** Community Help\
**Tags:** apache\
**Created:** [September 30, 2022, 10:15am UTC](https://discourse.pi-hole.net/t/html-permissions/58272 "2022-09-30T10:15:32Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![deHakkelaar](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dehakkelaar/32/674_2.png) [@deHakkelaar](https://discourse.pi-hole.net/u/deHakkelaar)\
**Post date:** [October 2, 2022, 10:28am UTC](https://discourse.pi-hole.net/t/html-permissions/58272/21 "2022-10-02T10:28:39Z")

</div>

> [@awoolford](#):
>
> I would suggest.

Come v6 release of Pi-hole, the `lighttpd` and `php` dependencies are removed.  
You can find hints here on Discourse.  
So why bother when all gets replaced by a single FTL binary/daemon that does almost all the work.

---

<div class="post-metadata">

**Author:** ![awoolford](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/a/9e8a1a/32.png) [@awoolford](https://discourse.pi-hole.net/u/awoolford)\
**Post date:** [October 2, 2022, 10:32am UTC](https://discourse.pi-hole.net/t/html-permissions/58272/22 "2022-10-02T10:32:13Z")

</div>

Only that this is relelvant to installations being done right now. This might be an edge case - I don't know, but a google search indicates this is not the first time users have struggled with pihole being installed on a platform which hosts other sites. So it's another tool in the box. That's all.

---

<div class="post-metadata">

**Author:** ![awoolford](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/a/9e8a1a/32.png) [@awoolford](https://discourse.pi-hole.net/u/awoolford)\
**Post date:** [October 8, 2022, 3:08pm UTC](https://discourse.pi-hole.net/t/html-permissions/58272/23 "2022-10-08T15:08:17Z")

</div>

I have edited the solution again today on 08/10/2022 because it was discovered that on a reboot or restart of pihole, the ownership of the lighttpd log and run folders get reset to www-data, presumably by pihole FTM. So I have forced the issue by using a custom script to ensure the permissions are set to the custom lighttpd user every time lighttpd is started. This method avoids any tinkering with the pihole code.

---

<div class="post-metadata">

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\
**Post date:** [October 8, 2022, 5:26pm UTC](https://discourse.pi-hole.net/t/html-permissions/58272/24 "2022-10-08T17:26:49Z")

</div>

I'm not sure I'd follow your approach to have Pi-hole's _`lighttpd`_ coexist with another web service running under Apache requiring you to use an unconventional user.

By convention, many web-related packages would refer to `www-data` by default, including Apache, nginx, lighttpd, php-fpm,... (though this may vary by OS).  
You may be inviting all kinds of difficulties by trying to force another default web user/group on all of your system components.

I was going to suggest that you may try installing Pi-hole's web UI without installing its _`lighttpd`_ webserver when I stumbled about a post by FreePBX developers explicitly advising to completely separate FreePBX and Pi-hole:

> **[Pihole overwrote freePBX web gui](https://community.freepbx.org/t/pihole-overwrote-freepbx-web-gui/57007/4)**
>
> FreePBX and Pihole should be run on entirely different machines Why? Because Pihole assumes complete control over the system (as it should). In fact it runs lighttpd if it can, not nginx and not apache.

A clean way to separate FreePBX and Pi-hole while still using a single machine to host them both may be to run them both in Docker containers, or at least one of them.

Did you consider running a [dockered Pi-hole](https://github.com/pi-hole/docker-pi-hole#docker-pi-hole)?

---

<div class="post-metadata">

**Author:** ![awoolford](https://discourse-cdn.pi-hole.net/letter_avatar_proxy/v4/letter/a/9e8a1a/32.png) [@awoolford](https://discourse.pi-hole.net/u/awoolford)\
**Post date:** [October 8, 2022, 5:43pm UTC](https://discourse.pi-hole.net/t/html-permissions/58272/25 "2022-10-08T17:43:55Z")

</div>

You could well be right that Docker is a better way. I haven't explored that... yet.

With that said, I've pretty much got them playing well together now by using the 'asterisk' user for lighttpd (which is installed by the freepbx package alongside apache) and putting the apache GUI on a different port. I also moved the FreePBX webroot to `/var/www/raspbx` so that lighttpd has `/var/www/html` all to itself.

So, lighttpd will run on port 80 totally independently without risk of conflict with FreePBX and I have now found that the directory owner and permission changes needed for lighttpd to run as a different user, all seem to be handled by system.d during boot. I will go back and edit the solution (for the umpteenth time) to reflect this new discovery which makes it all surprisingly easy... as most things are when you do it the right way. Done 😄

---

<div class="post-metadata">

**Author:** ![chrislph](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/chrislph/32/32723_2.png) [@chrislph](https://discourse.pi-hole.net/u/chrislph)\
**Post date:** [October 8, 2022, 6:01pm UTC](https://discourse.pi-hole.net/t/html-permissions/58272/26 "2022-10-08T18:01:11Z")

</div>

Sounds good; take extra care to keep periodic backups of everything, in case an update to either service resets your modifications and breaks it.

---

<div class="post-metadata">

**Author:** ![system](https://discourse.pi-hole.net/uploads/default/original/3X/7/c/7c8792f649eeb921c5d2b4c41564ffa873d9a2b8.png) [@system](https://discourse.pi-hole.net/u/system)\
**Post date:** [October 29, 2022, 6:01pm UTC](https://discourse.pi-hole.net/t/html-permissions/58272/27 "2022-10-29T18:01:20Z")

</div>

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

[Previous page](https://discourse.pi-hole.net/t/html-permissions/58272.md?page=1)
