[Support] Linuxserver.io - SWAG - Secure Web Application Gateway (Nginx/PHP/Certbot/Fail2ban)


Recommended Posts

Did you check log and post them? Hard diagnose a problem that you can't reproduce. Are you using latest config? Did you check if the templates has changed? There was a lot of change in the last year in swag and other, some are breaking change if you never update your config. 

 

The startup log will tell you when you have outdated config and deprecated fonction. 

Link to comment

Hi there,

I realy hope this is the right place to ask as I'm not sure my problem is related to Swag. Might be a Nextcloud or even macOS problem as well.

I'm running a Nextcloud and Swag container as shown in spaceinvaders tutorial. Everything works well so far until I recently bought myself a new Mac mini. When setting up the Nextcloud app I get an error message telling me the certificate is self signed and cannot be trusted. As one can see the URL used is https://nxtcld.my-domain.de. For this subdomain I have a CNAME configures pointing to my DuckDNS domain mynextcloud.duckdns.org. Sorry, German system so German error message. But I guess one can see the issue here.

Swag is configured for the subdomain nxtcld.my-domain.de (as well as for a Bitwarden subdomain) and not the DuckDNS URL. Why is DuckDNS even mentioned here? I do not have this issue with my iOS devices nor my WIndows computers. I renewed the certificate manually with no no change in this behavior. Setting the checkbos to trust the certificate anyway does not solve this. I tried and got the options to use another URL, try an unsecure connection or to configure a client side certificate. For the last option I have no idea what to do here. Using the unsecure http option doesn't work too beside the fact I wouldn't like to use an unsecure connection. Finaly I get the error message the server has answered "400 Bad request".

That's were I'm currently stucked. Any idea what can be the problem here?

 

Regards

petjek

Screenshot 03.03.2023 um 09.09.15 AM.png

Screenshot 03.03.2023 um 09.21.46 AM.png

Link to comment
On 3/1/2023 at 8:15 AM, lusitopp said:

Hi, 

 

I have a problem that I have had for 1-2 weeks now, every morning I cannot access my stuff that is behind SWAG.

I'm not sure if this is a unraid or a SWAG problem but after a simple restart of SWAG I can access all my stuff again.
In which logs shall I begin the troubleshooting?

Same Problem here. I created a cronjob whith "docker restart swag" which restarts my swag every hour to avoid problems, but this sucks.

 

Log of swag shows no problems.

Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Sub-domains processed are:  xxx
E-mail address entered: xxx
http validation is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Server ready

 

Link to comment
20 hours ago, petjek said:

That's were I'm currently stucked. Any idea what can be the problem here?

 

as it looks like your https connection to NCis fine (other clients working) i would suggest to look for the mac NC forums.

 

may also look in your config.php about overwrite url, trusted proxy and trusted domain(s)

 

note, your real domain is in the last pic ...

Link to comment

I was hoping to get some help with a docker I've recently added that I'd like to route through SWAG. I had to setup the Docker manually, here are the results of that Docker run:

 

-d
--name='conduit'
--net='proxynet' (<----- the unRaid Network I use for all my SWAG ssl connections)
-e TZ="America/Los_Angeles"
-e HOST_OS="Unraid"
-e HOST_HOSTNAME="rubble"
-e HOST_CONTAINERNAME="conduit"
-e 'CONDUIT_SERVER_NAME'='matrix.mydomain.com' (<---obfuscated)
-e 'CONDUIT_DATABASE_BACKEND'='rocksdb'
-e 'CONDUIT_ALLOW_REGISTRATION'='true'
-e 'CONDUIT_ALLOW_FEDERATION'='true'
-e 'CONDUIT_MAX_REQUEST_SIZE'='100000000'
-e 'CONDUIT_TRUSTED_SERVERS'='["matrix.org"]'
-e 'CONDUIT_MAX_CONCURRENT_REQUESTS'='100'
-e 'CONDUIT_LOG'='warn,rocket=off,_=off,sled=off'
-l net.unraid.docker.managed=dockerman
-l net.unraid.docker.icon='https://raw.githubusercontent.com/mozilla/fxemoji/gh-pages/svgs/nature/u26A1-bolt.svg'
-p '8448:6167/tcp'
-v '/mnt/user/appdata/matrix-conduit':'/var/lib/matrix-conduit':'rw' 'matrixconduit/matrix-conduit:latest'
c9a300cad404e7a5e9d4298ec7a2413fd3e6c5650aa7deafdcb60e411501254c

 

I'm getting the "502 Bad Gateway nginx" error when I hit my subdomain, and that's an error with the SWAG conf.

screencapture-192-168-11-53-Dashboard-UpdateContainer-2023-03-07-13_57_58.thumb.png.70597f00b2c928f07c9eb6fef9f7e1d1.png

/mnt/user/appdata/swag/nginx/proxy-confs/conduit.subdomain.conf

## Version 2023/02/05
# REMOVE THIS LINE BEFORE SUBMITTING: The structure of the file (all of the existing lines
) should be kept as close as possible to this template.
# REMOVE THIS LINE BEFORE SUBMITTING: Look through this file for <tags> and replace them.
Review other sample files to see how things are done.
# REMOVE THIS LINE BEFORE SUBMITTING: The comment lines at the top of the file (below this
 line) should explain any prerequisites for using the proxy such as DNS or app settings.
# make sure that your <container_name> container is named <container_name>
# make sure that your dns has a cname set for <container_name>

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name conduit.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app conduit;
        set $upstream_port 8448;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    # REMOVE THIS LINE BEFORE SUBMITTING: Some proxies require one or more additional location blocks for things like API or RPC endpoints.
    # REMOVE THIS LINE BEFORE SUBMITTING: If the proxy you are making a sample for does not require an additional location block please remove the commented out section below.
    # location ~ (/<container_name>)?/api {
    #     include /config/nginx/proxy.conf;
    #     include /config/nginx/resolver.conf;
    #     set $upstream_app <container_name>;
    #     set $upstream_port <port_number>;
    #     set $upstream_proto <http or https>;
    #     proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    #
    #     # REMOVE THIS LINE BEFORE SUBMITTING: Additional proxy settings such as headers go below this line, leave the blank line above.
    # }
}
conduit.subdomain.conf lines 19-62/62 (END)

 

 

 

Conduit is an implementation of Matrix chat server. There is no SWAG template for it; so I've been doing the best I can repurposing a different domain template over into this one, but I'm striking out.

 

My end goal here is to bring iMessage, Whatsapp, Signal, FB Messenger, IG Messenger, and SMS all into one chat app that will work on: iPhone, android, and my windows laptop. Probably with Element app.

 

Some notes so far

https://forums.unraid.net/topic/135799-love-to-1-ditch-iphone-2-keep-imessage-and-3-combine-all-messengers/#comment-1235564

 

Link to comment
On 3/2/2023 at 10:30 PM, Nodiaque said:

Did you check log and post them? Hard diagnose a problem that you can't reproduce. Are you using latest config? Did you check if the templates has changed? There was a lot of change in the last year in swag and other, some are breaking change if you never update your config. 

 

The startup log will tell you when you have outdated config and deprecated fonction. 

I did a major check at one point, all config files were in line with latest templates (they aren't anymore, but that's for services like bitwarden and it runs fine regardless).

 

[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] done
usermod: no changes

-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/


Brought to you by linuxserver.io
-------------------------------------

To support the app dev(s) visit:
Certbot: https://supporters.eff.org/donate/support-work-on-certbot

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid:    99
User gid:    100
-------------------------------------

using keys found in /config/keys
Variables set:
PUID=99
PGID=100
TZ=Europe/Berlin
URL=### removed ###
SUBDOMAINS=### removed ###
EXTRA_DOMAINS=
ONLY_SUBDOMAINS=true
VALIDATION=http
CERTPROVIDER=
DNSPLUGIN=
EMAIL=### removed ###
STAGING=false

Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Only subdomains, no URL in cert
Sub-domains processed are:  -d ### removed ###
E-mail address entered: ### removed ###
http validation is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
**** 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. ****
┌────────────┬────────────┬────────────────────────────────────────────────────────────────────────┐
│  old date  │  new date  │ path                                                                   │
├────────────┼────────────┼────────────────────────────────────────────────────────────────────────┤
│ 2023-02-05 │ 2023-02-13 │ /config/nginx/proxy-confs/bitwarden.subdomain.conf                     │
└────────────┴────────────┴────────────────────────────────────────────────────────────────────────┘
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Server ready

 

And as I said, it's not the point that it's not working - to the contrary, it's like A+.

Once I hit the update button (which should not have anything to do with the config files in the appdata) the mentioned file will appear in the wrong directory again, I can move the file, it will work again .... rinse and repeat.

 

I am by no means a docker expert, hardly an apprentice even, but this cannot be related to the .conf file above, or any other of the .conf files in this folder as none of them refer to the stream.conf file in any way.

Link to comment

Another update from SWAG and my configuration is broken again. Same error as before:

 

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

 

I renamed /etc/nginx/conf.d/stream.conf to a non .conf name, restarted and it's back now. Why is this offending file constantly injected and start producing errors every time I update?

  • Like 1
Link to comment
15 hours ago, Born8bit said:

I am by no means a docker expert, hardly an apprentice even, but this cannot be related to the .conf file above, or any other of the .conf files in this folder as none of them refer to the stream.conf file in any way.

 

nothing to see from your logs, but as there are prolly many many swag users out there and if this would be a common issue you would see it here more and more ...

 

so, moving the file inside the docker /etc/... will only persist until a docker update runs (you can enforce it by a docker conf change) and this file will be recreated, so this always is just a temp solution.

 

for now i see only 2 choices, either you walk through your configs and check if and where you have "old" stream configurations you may have done somewhere (or still persist from older installs).

 

or for now just dont load the file into nginx which woul dbe persistent ...

 

open your nginx.conf from the appdata folder and comment the loading line

 

# Include files with config snippets into the root context.
include /etc/nginx/conf.d/*.conf;

### change to >>>

# Include files with config snippets into the root context.
#include /etc/nginx/conf.d/*.conf;

then it wont look there and wont load it ... as it seems you dont want or need the stream rules anyway it shouldnt bother now and makes it a bit easier now before taking your swag install upside / down ;)

 

by default there is no issue with this file, this just as note ... so its a config error somewhere ... and this is not a offense, its just there where some major changes and some configs needed some changes, and as we all play some time with configs and then forget about it (as all is running) ... things like this can happen ...

 

root@751e7cb78cac:/# cat /etc/nginx/conf.d/stream.conf 
# /etc/nginx/conf.d/stream.conf

stream {
        # Specifies the main log format.
        log_format main '$remote_addr [$time_local] '
                        '$protocol $status $bytes_sent $bytes_received '
                        '$session_time "$upstream_addr" '
                        '"$upstream_bytes_sent" "$upstream_bytes_received" "$upstream_connect_time"';

        access_log /var/log/nginx/stream.log main;

        # Includes servers configs.
        include stream.d/*.conf;
}
root@751e7cb78cac:/# 

image.png.6cb35c728204d423181b540dcabae42d.png

 

as you see, its also no issue here ...

 

2 hours ago, snowboardjoe said:

I renamed /etc/nginx/conf.d/stream.conf to a non .conf name, restarted and it's back now. Why is this offending file constantly injected and start producing errors every time I update?

same relies to your question ...

 

you should be fine when you replace your swag install completely fresh and insert your "known" configurations manually step by step ... then you would see your stream.conf can also rely there ... or at least know when it breaks and look for your configuration failure / missmatch and could fix it.

 

so, either look deep inside or just take the loading line out when you dont need stream directives in your reverse proxy ...

Link to comment
  • 2 weeks later...

Hey Folks,

 

I went through this setup guide posted in 2021 for using Swag with Emby:

 

https://emby.media/community/index.php?/topic/94566-guide-setup-emby-with-hw-transcoding-on-unraid-remote-access-through-reverse-proxy-using-swag/page/2/

 

I followed the guide half a dozen times and now keep getting the same result. At the very end when I go to test the subdomain (XXXX.hopto.org) it has this Swag popup and that's it. Everything says it is running fine, and all settings appear to be EXACT when compared with the guide. This is also a brand new server with no other dockers.

 

Anyone have a clue what my problem is here?

Screenshot 2023-03-23 120548.jpg

maverick-diagnostics-20230323-1222.zip

Link to comment
On 3/10/2023 at 3:12 AM, snowboardjoe said:

Another update from SWAG and my configuration is broken again. Same error as before:

 

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

 

I renamed /etc/nginx/conf.d/stream.conf to a non .conf name, restarted and it's back now. Why is this offending file constantly injected and start producing errors every time I update?

 

I'm getting the same error message, however, that pathway does not exist in krusader and I cannot see that file. How do you locate it? Thanks

Edited by unraid20
Link to comment

Hi all,

 

Looking to run Active Collab on my Unraid server. There's a probe file available on https://activecollab.com/help/books/self-hosted-activecollab/requirements if anyone wants to play along at home.

 

I know that SWAG can handle PHP sites/apps alone, but not sure it's the most appropriate solution versus a dedicated container (I assume anyone else will know better than me).

 

If I were to use a dedicated container, what container should I use? And what kind of proxy-conf would I use with it?

 

Equally, if I were to just sling it into a SWAG dir, what kind of proxy-conf would I use for that, assuming I want to run it on a subdomain?

 

Got plenty of containers already running with SWAG, but they were largely bog-standard common turn-key things. This is likely the final piece of the puzzle for me.

 

Edit: figured this out.

Edited by Hammy Havoc
Figured it out.
Link to comment
On 3/3/2023 at 2:08 PM, Retrogamer137 said:

Same Problem here. I created a cronjob whith "docker restart swag" which restarts my swag every hour to avoid problems, but this sucks.

 

Log of swag shows no problems.

Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Sub-domains processed are:  xxx
E-mail address entered: xxx
http validation is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Server ready

 

Did you figure out the cron issue? My cron tasks were running initially, gave the SWAG container a restart and noticed that my cron tasks didn't persist.

 

Just confirmed that restarting my SWAG container causes me to lose any tasks I've added to crontab. I used `(crontab -l ; echo "0 * * * * /usr/bin/php81 '/config/www/tasks/cron_jobs/run_every_hour.php'") | sort - | uniq - | crontab -`

Edit: workaround is adding cron tasks in Scheduled Tasks in Settings and executing the command within the appropriate Docker container.

Edited by Hammy Havoc
Link to comment
  • 2 weeks later...
On 3/3/2023 at 3:08 PM, Retrogamer137 said:

Same Problem here. I created a cronjob whith "docker restart swag" which restarts my swag every hour to avoid problems, but this sucks.

 

Log of swag shows no problems.

Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
SUBDOMAINS entered, processing
Sub-domains processed are:  xxx
E-mail address entered: xxx
http validation is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Server ready

 

same problem here.

 

A simple restart of the SWAG container is solving the problem temporarily.

I was thinking it was a good workaround to just restart SWAG hourly through UserScripts, but then I found out:

 

1. if I am clicking "too much" on the nextcloud webinterface and browse trough too much folders, then it crashes again

2. a reboot of SWAG is solving the problem

 

But that's not a great solution, since I can't just reboot the SWAG container manually when it happens when I am not at home 

Does anybody have a solution for this?

 

Thanks!

Link to comment
On 4/15/2023 at 9:52 PM, diederich89 said:

same problem here.

 

A simple restart of the SWAG container is solving the problem temporarily.

I was thinking it was a good workaround to just restart SWAG hourly through UserScripts, but then I found out:

 

1. if I am clicking "too much" on the nextcloud webinterface and browse trough too much folders, then it crashes again

2. a reboot of SWAG is solving the problem

 

But that's not a great solution, since I can't just reboot the SWAG container manually when it happens when I am not at home 

Does anybody have a solution for this?

 

Thanks!

 

Hi there, I switched to traefik and had the same problem.

So that did the trick for me:

 

nano /mnt/user/appdata/nextcloud/php/www2.conf

 

insert these variables:

 

pm = ondemand

pm.max_children = 300

pm.start_servers = 8

pm.min_spare_servers = 8

pm.max_spare_servers = 16

pm.max_requests = 500

Link to comment
  • 2 weeks later...

im trying to get paperless-ngx to work but i keep getting an error.

 

the paperless login comes up, when ienter username and password i get the following error

 

my conf file

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name paperless-ngx.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    include /config/nginx/authelia-server.conf;

    #Organizr ServerAuth
    #include /config/nginx/proxy-confs/organizr-auth.subfolder.conf;
    #auth_request /auth-0;

    location / {
        # enable the next two lines for http auth
        # auth_basic "Restricted";
        # auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        # auth_request /auth;
        # error_page 401 =200 /ldaplogin;

        # enable for Authelia
        # include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app 192.168.10.221;
        set $upstream_port 8000;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        # REMOVE THIS LINE BEFORE SUBMITTING: Additional proxy settings such as headers go below this line, leave the blank line above.
    }

}

 

paperless.png

 

EDIT:

this post helped fix the issue

https://github.com/paperless-ngx/paperless-ngx/issues/712

Edited by Greygoose
Link to comment
  • 2 weeks later...

If my years-old swag container has many of the nagging problems mentioned over the last couple pages and I want to start over, how should I deal with the LetsEncrypt side of things? Do I just copy over the /etc/letsencrypt folder from the old one? Are there procedural issues to watch out for, like I should copy those files over before I tell the container which subdomains to provision so it won't fail before it has the creds?

 

Link to comment

I'm a bit scared to update swag these days, and it doesn't look like there's a way to check the version I have installed if I need to roll back (besides going by time and testing for the right old version.)

 

My current install is from 2 months ago. Are there critical changes? Is the certbot update critical? I'm going by what I read on the release page.

Edited by vurt
Link to comment
Quote

dns validation via transip plugin is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
/config/nginx/geoip2.conf exists.
        Please migrate to https://github.com/linuxserver/docker-mods/tree/swag-maxmind
**** 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. ****
┌────────────┬────────────┬────────────────────────────────────────────────────────────────────────┐
│  old date  │  new date  │ path                                                                   │
├────────────┼────────────┼────────────────────────────────────────────────────────────────────────┤
│ 2022-08-16 │ 2023-04-13 │ /config/nginx/nginx.conf                                               │
│ 2023-02-09 │ 2023-04-27 │ /config/nginx/authentik-server.conf                                    │
│ 2023-02-09 │ 2023-04-27 │ /config/nginx/authentik-location.conf                                  │
│ 2022-09-22 │ 2023-04-27 │ /config/nginx/authelia-server.conf                                     │
│ 2022-08-20 │ 2023-04-27 │ /config/nginx/authelia-location.conf                                   │
│ 2022-09-01 │ 2023-02-09 │ /config/nginx/proxy.conf                                               │
│ 2022-10-03 │ 2023-04-13 │ /config/nginx/site-confs/default.conf                                  │
└────────────┴────────────┴────────────────────────────────────────────────────────────────────────┘
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Server ready

When i check my Swag log i see this

 

But when i check the files in that directory. the Dates are different. For like the nginx.conf ( and the nginx.conf.sample) the date on the server is 2023-05-19 as i just updated the container but in the log it keeps saying i should check the file.

 

Is this a static thing of does it actually check it ?

 

Edit:

 

Ah i see it takes the that date from inside the file. so going to check the differences now.

Edited by KoNeko
Link to comment

Out of nowhere today all of my domains stopped working. I'm not really seeing any errors here. Any thoughts?

 

dns validation via cloudflare plugin is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
/config/nginx/geoip2.conf exists.
        Please migrate to https://github.com/linuxserver/docker-mods/tree/swag-maxmind
/config/nginx/ldap.conf exists.
        Please apply any customizations to /config/nginx/ldap-server.conf
        Ensure your configs are updated and remove /config/nginx/ldap.conf
        If you do not use this config, simply remove it.
**** 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. ****
┌────────────┬────────────┬────────────────────────────────────────────────────────────────────────┐
│  old date  │  new date  │ path                                                                   │
├────────────┼────────────┼────────────────────────────────────────────────────────────────────────┤
│            │ 2023-02-05 │ /config/nginx/proxy-confs/sonarr.subdomain.conf                        │
│            │ 2023-02-05 │ /config/nginx/proxy-confs/sabnzbd.subdomain.conf                       │
│            │ 2023-02-05 │ /config/nginx/proxy-confs/plex.subdomain.conf                          │
│            │ 2023-02-05 │ /config/nginx/proxy-confs/radarr.subdomain.conf                        │
│            │ 2023-02-05 │ /config/nginx/proxy-confs/organizr.subdomain.conf                      │
│            │ 2023-02-05 │ /config/nginx/proxy-confs/qbittorrent.subdomain.conf                   │
└────────────┴────────────┴────────────────────────────────────────────────────────────────────────┘
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Server ready


 

 

Link to comment
  • 2 weeks later...

Hello!

So I've had SWAG running great for a few years now and I recently decided to change domains. I thought it would be as simple as editing the template and transferring the DNS records to the new domain but I'm running into a problem.

 

After updaiting SWAG I can still go to server.OLDdomain.com and still see the swag landing page

 

but when I try with my new domain, server.NewDomain.com I get "This page isn't redirecting properly."

 

This happens for any of my existing subdomains I've set up. After getting rid of oldDomian.com from the swag template and replacing it with newDomain.com the old one still shows the sites it should no longer be connected to and the new domain fails to take me to the site.

 

I can ping newdomain.com and get my personal IP, so I think its at least close to being setup right but something isn't working and I'm really not to sure.

 

if I look at the SWAG log it says the following:

 

Quote

Using Let's Encrypt as the cert provider
SUBDOMAINS entered, processing
Wildcard cert for only the subdomains of NEWDOMAIN.COM will be requested
E-mail address entered:
dns validation via cloudflare plugin is selected
Certificate exists; parameters unchanged; starting nginx
The cert does not expire within the next day. Letting the cron script handle the renewal attempts overnight (2:08am).
/config/nginx/geoip2.conf exists.
        Please migrate to https://github.com/linuxserver/docker-mods/tree/swag-maxmind
/config/nginx/ldap.conf exists.
        Please apply any customizations to /config/nginx/ldap-server.conf
        Ensure your configs are updated and remove /config/nginx/ldap.conf
        If you do not use this config, simply remove it.
**** 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. ****
┌────────────┬────────────┬────────────────────────────────────────────────────────────────────────┐
│  old date  │  new date  │ path                                                                   │
├────────────┼────────────┼────────────────────────────────────────────────────────────────────────┤
│ 2022-08-16 │ 2023-04-13 │ /config/nginx/nginx.conf                                               │
│ 2023-02-09 │ 2023-04-27 │ /config/nginx/authentik-server.conf                                    │
│ 2023-02-09 │ 2023-04-27 │ /config/nginx/authentik-location.conf                                  │
│ 2020-06-02 │ 2022-08-20 │ /config/nginx/ldap-server.conf                                         │
│ 2020-05-31 │ 2023-04-27 │ /config/nginx/authelia-location.conf                                   │
│ 2020-05-31 │ 2023-04-27 │ /config/nginx/authelia-server.conf                                     │
│ 2020-10-04 │ 2023-02-09 │ /config/nginx/proxy.conf                                               │
│ 2021-10-11 │ 2023-05-31 │ /config/nginx/proxy-confs/homeassistant.subdomain.conf                 │
│ 2021-05-18 │ 2023-05-31 │ /config/nginx/proxy-confs/overseerr.subdomain.conf                     │
│ 2020-12-09 │ 2023-05-31 │ /config/nginx/proxy-confs/nextcloud.subdomain.conf                     │
└────────────┴────────────┴────────────────────────────────────────────────────────────────────────┘
[custom-init] No custom files found, skipping...
[ls.io-init] done.
Server ready

 

 

If anyone has any ideas, I would greatly appreciate the help, thanks!

Link to comment
On 6/4/2023 at 1:34 PM, InCaseOf said:

Hello!

So I've had SWAG running great for a few years now and I recently decided to change domains. I thought it would be as simple as editing the template and transferring the DNS records to the new domain but I'm running into a problem.

 

After updaiting SWAG I can still go to server.OLDdomain.com and still see the swag landing page

 

but when I try with my new domain, server.NewDomain.com I get "This page isn't redirecting properly."

 

This happens for any of my existing subdomains I've set up. After getting rid of oldDomian.com from the swag template and replacing it with newDomain.com the old one still shows the sites it should no longer be connected to and the new domain fails to take me to the site.

 

I can ping newdomain.com and get my personal IP, so I think its at least close to being setup right but something isn't working and I'm really not to sure.

 

if I look at the SWAG log it says the following:

 

 

 

If anyone has any ideas, I would greatly appreciate the help, thanks!

 

 

 

The fix is here:

" I finally fixed it by going to the SSL/TLS tab in coiudflare and switching from "flexible" to "full" "

Link to comment
  • 4 weeks later...

Hi guys. I had this running great last year but for reasons in my own stupid mind thought I would try out OMV. Now I have returned to unraid for the life of me I cannot get Bitwarden running. I have installed swag and it seems to be running correctly saying server is ready.

 

I don't have a domain so its going to my DDNS. 

 

Following SpaceInvaders instructions carefully I thought I was golden but when I go to my DDNS address it resolves to SWAG and not to Bitwarden. I can get to bitwarden on LAN, via the unraid address, but its set to use proxy web, along with SWAG.

 

Spaceinvader offers a file download for 'subdomains' and skirts over this bit with barely any instruction, but I feel like I didn't need that file last time but perhaps I did?

 

IN any case can anyone offer a suggestion why it resolves to the swag home page and not bitwarden as its driving me dolally 

Link to comment

Well I have been at this for hours. I simply cannot get it to resolve to my bitwarden. SWAG says server is running. I even changed to another DNS provider (duck) and again it says its functioning. I tried to adjust the vaultwarden conf file that SWAG creates to point to my DNS address (as instructed by spaceinviaderone) but this does not work and when I restart swag the conf file is overwritten by the original.

 

Obviously this is something I am doing wrong but any pointers would be helpful. I am following the instructions to the letter. the outcome is I see a welcome to swag not bitwarden.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.