# Nginx.http.sock recreated with incorrect selinux context
**URL:** https://meta.discourse.org/t/nginx-http-sock-recreated-with-incorrect-selinux-context/202602
**Category:** Self-hosting
**Created:** [September 4, 2021, 10:55am UTC](https://meta.discourse.org/t/nginx-http-sock-recreated-with-incorrect-selinux-context/202602 "2021-09-04T10:55:40Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@uckelman](https://meta.discourse.org/u/uckelman)
#### Post date: [September 4, 2021, 10:55am UTC](https://meta.discourse.org/t/nginx-http-sock-recreated-with-incorrect-selinux-context/202602/1 "2021-09-04T10:55:40Z")
I have a Discourse instance proxied behind Apache and communicating over a socket, as described [here](https://meta.discourse.org/t/how-to-run-discourse-as-an-apache-virtualhost/154707).
I have SELinux enabled, so in order to give httpd permission to use the socket, I’ve given the socket a context where httpd has read-write permission, as advised:
```plaintext
semanage fcontext -a -t httpd_sys_rw_content_t /var/discourse/shared/standalone/nginx.http.sock
restorecon /var/discourse/shared/standalone/nginx.http.sock
```
This works. It’s great!
(Aside: Would a more appropriate context be `httpd_var_run_t`, as the socket itself isn’t _content_ and this is the context used by httpd for other runtime infrastructure?)
However, whenever the Discourse container is restarted the socket file is recreated with its original context, not the new one—hence I have to `restorecon` it before Apache can talk to Discourse. It’s easy to forget to do this and end up with an inaccessible forum. It occurred to me that I could use a cron script to run `restorecon` periodically so I don’t have to remember to do it manually, but that’s an ugly hack.
How can I ensure that the socket file gets the correct context on creation (or at least has its context reset as part of the creation process)?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [September 4, 2021, 11:06am UTC](https://meta.discourse.org/t/nginx-http-sock-recreated-with-incorrect-selinux-context/202602/2 "2021-09-04T11:06:20Z")
I’d make a restart script that started the container and changed the permission (and another that does a rebuild).
---
### Author:  [@uckelman](https://meta.discourse.org/u/uckelman)
#### Post date: [September 4, 2021, 11:09am UTC](https://meta.discourse.org/t/nginx-http-sock-recreated-with-incorrect-selinux-context/202602/3 "2021-09-04T11:09:21Z")
The thing a restart script wouldn’t catch is doing upgrades via the web from the admin panel—that’s what got me last time and prompted me to wonder if there were a fix for all cases.
I should also say: I don’t understand _why_ the socket doesn’t get the correct context on creation. SELinux clearly knows what the default context for the socket should be, as running `restorecon` shows. (Also, I can see the entry for the socket made from running `semanage fcontext` in `/etc/selinux/targeted/contexts/files/file_contexts.local`.)