[BUG] nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3

[andye2801]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Swag fails to start on latest version 1.32.0-ls173 with error nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3

Reverting my container to 1.32.0-ls172 allows swag to start and function correctly.

Expected Behavior

No response

Steps To Reproduce

Update to 1.32.0-ls173

Environment

- OS:
- How docker service was installed:

CPU architecture

x86-64

Docker creation

Portainer used

Container logs

nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3

[github-actions]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[freakshock88]

Just had the same issue because watchtower updated my swag container to 1.32.0-ls173. Reverting to 1.32.0-ls172 indeed solves it.

[andye2801]

Just had the same issue because watchtower updated my swag container to 1.32.0-ls173. Reverting to 1.32.0-ls172 indeed solves it.

At least it's not just me then, occasionally using watchtower has it's downside!

[aptalca]

1. We don't recommend watchtower as it's explained in the readmes
2. Check your container log for out of date configs and update them as described

[AndersKANYE]

Like others here, I auto-updated through watchtower and it broke. Reverting to 1.32.0-ls172 fixes it.

[aptalca]

Reverting to an older version is not a fix, merely a workaround and a very poor one for a reverse proxy. Please see my comment above.

Closing.

[freakshock88]

Wait.. how can you be sure that our configs are the issue here? Why could this not be a bug? I agree with you reverting to a previous version is just a workaround. Should it not at least be investigated what causes this bug?

[andye2801]

Wait.. how can you be sure that our configs are the issue here? Why could this not be a bug? I agree with you reverting to a previous version is just a workaround. Should it not at least be investigated what causes this bug?

Given 3 people have the issue in the 1st hour after release I'm with you that it's a bug. There are no breaking changes on the GitHub release so what exactly should we be looking for in our config that's breaking it?

[thespad]

It's not a bug. The upstream package changed how they ship the default nginx configs, if your existing configs already define a stream block it will break because there can only be one.

You either need to remove that stream block or remove the include of the new one.

As we don't preconfigure or support the use of the stream module with swag it will likely be something that you've added at some point, or you just got unlucky and the default upstream configs at some point in the past included them and that's where you picked it up.

[nemchik]

Wait.. how can you be sure that our configs are the issue here? Why could this not be a bug? I agree with you reverting to a previous version is just a workaround. Should it not at least be investigated what causes this bug?

Given 3 people have the issue in the 1st hour after release I'm with you that it's a bug. There are no breaking changes on the GitHub release so what exactly should we be looking for in our config that's breaking it?

Your container logs likely have some information like this:

**** The following active confs have different version dates than the samples that are shipped. ****
**** This may be due to user customization or an update to the samples. ****
**** You should compare the following files to the samples in the same folder and update them. ****
**** Use the link at the top of the file to view the changelog. ****
/config/nginx/nginx.conf
/config/nginx/site-confs/default.conf

Whichever files are listed are outdated. We place the sample files right next to the file listed as outdated, ex:

/config/nginx/nginx.conf -> /config/nginx/nginx.conf.sample
/config/nginx/site-confs/default.conf -> /config/nginx/site-confs/default.conf.sample

Per the instructions in the logs, you will need to compare your active config files to the included samples and determine if anything in your active config was a customization that you put in place for a specific reason. Then replace the active file with the sample, and apply any customizations you need. Then restart the container. This will stop the container init from logging these messages.

If you still have the same problem after updating your config, please provide the full container log and nginx log (inside your config) and we can troubleshoot. Providing one line from the log is not enough context for us to determine how to handle the issue.

Edit:
It may be possible to modify your nginx.conf to simply remove the line that reads: include /etc/nginx/conf.d/*.conf;
This is NOT the recommended fix, and your configs may still be outdated in other ways, and we cannot support running outdated configs.
The best option is already outlined above. Update your configs as described above.

[rbrussell82]

I'm not sure which part of my nginx.conf file caused this, but replacing my .conf I've been using with the current nginx.conf.sample file worked. It seems like something updated from a previous nginx.conf that's causing this.

[aptalca]

Hence the second point in my comment above. The container log lists the configs that are out of date and tells you how to update them.

[Beaker1969]

Had the same problem.

Had already posted on the Unraid Forum. So started to go through all my .Conf files.

Then @BigBoyMarky on https://forums.unraid.net/topic/51808-support-linuxserverio-swag-secure-web-application-gateway-nginxphpcertbotfail2ban/page/237/ suggested that just replacing ssl.conf and nginx.conf solved the problem.

Did that and now up and running. I will be checking my files but now it is not so urgent.

[elforesto]

"We put the warnings in the logs nobody reads until something goes sideways" is a heck of a dodge. One of the big rules of updates is don't break a working config. Was there any consideration of attempting an automatic migration?

[nemchik]

Yes, that has been considered. We have no way of knowing what customizations users apply and how to adjust the configs in a way that keeps them up to date without breaking something intentionally customized.

[Roxedus]

The reason this became a thing because the nginx stream module started shipping with a on-by-default stream configuration, in a location we removed from the old place in in early 2021.

[andye2801]

For those that come here my fix was to replace /config/nginx/nginx.conf with /config/nginx/nginx.conf.sample. I had already updated the ssl.conf file and the error remained so the change is either in both files or only nginx.conf.
Now to check the other files that have changed since I created my proxy container!

[isriam]

For those running this in docker, this is how I fixed mine today.

~/docker/swag/nginx

mv ssl.conf ssl.conf.bak
mv ssl.conf.sample ssl.conf
mv nginx.conf nginx.conf.bak
mv nginx.conf.sample nginx.conf

[GameEnder]

I upgraded configs and now I get a unknown "denied_highrisk" variable spam in my log. From what I can tell it related to fail2ban.

This is a old container from around 2020. I have upgraded all the configs to the latest sample files other then the proxy-configs. Any Ides on what I need to remove to get that to go away so it can boot fully.

[DaveSpe]

configs to the latest sample files other then the proxy-configs.

You don't upgrade them, you upgrade the container and then stop it, then delete the nginx.conf, the container creates a new config file for you next time you start it.