srepper Posted March 2 Share Posted March 2 On 3/1/2023 at 2:57 AM, mgranger said: I am not getting 502 errors for a lot of my subdomains? A few work but most are getting this error? I have taken the sample file and tried to modify it to work but I am not having much luck. same Quote Link to comment
Peglah Posted March 2 Share Posted March 2 On 2/25/2023 at 12:45 PM, Born8bit said: At this point, swag is driving me crazy ... After each update, I get this error message: nginx: [emerg] "stream" directive is not allowed here in /etc/nginx/conf.d/stream.conf:3 So I move the file like this: mv -v /etc/nginx/conf.d/stream.conf /etc/nginx/stream.d/ and restart the docker, all is fine. Next update, same procedure - and I don't get it, how come this file always ends up where supposedly it's not supposed to be? I checked all the config files that were outdated, but none were related to stream.conf, most were just newer templates, I transitioned but keep getting the same problem. I have the same problem. I've not changed my config for at least a year and this suddenly happens on every update now. Quote Link to comment
Nodiaque Posted March 2 Share Posted March 2 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. Quote Link to comment
petjek Posted March 3 Share Posted March 3 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 Quote Link to comment
Retrogamer137 Posted March 3 Share Posted March 3 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 Quote Link to comment
Squid Posted March 3 Share Posted March 3 Best place for support on LSIO containers would be their Discord site (click on the icon and select discord) 1 Quote Link to comment
alturismo Posted March 4 Share Posted March 4 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 ... Quote Link to comment
rutherford Posted March 7 Share Posted March 7 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. /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 Quote Link to comment
Born8bit Posted March 9 Share Posted March 9 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. Quote Link to comment
snowboardjoe Posted March 10 Share Posted March 10 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? 1 Quote Link to comment
alturismo Posted March 10 Share Posted March 10 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 ... [email protected]:/# 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; } [email protected]:/# 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 ... Quote Link to comment
Ezekial66 Posted March 23 Share Posted March 23 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? maverick-diagnostics-20230323-1222.zip Quote Link to comment
unraid20 Posted March 30 Share Posted March 30 (edited) 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 March 30 by unraid20 Quote Link to comment
alturismo Posted March 30 Share Posted March 30 1 hour ago, unraid20 said: 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 i think i posted a solution (quick & dirty) 1 or 2 pages before ... you will find it. 1 Quote Link to comment
Hammy Havoc Posted March 30 Share Posted March 30 (edited) 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 April 2 by Hammy Havoc Figured it out. Quote Link to comment
Hammy Havoc Posted April 2 Share Posted April 2 (edited) 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 April 2 by Hammy Havoc Quote Link to comment
diederich89 Posted April 15 Share Posted April 15 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! Quote Link to comment
diederich89 Posted April 21 Share Posted April 21 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 Quote Link to comment
Greygoose Posted May 1 Share Posted May 1 (edited) 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. } } EDIT: this post helped fix the issue https://github.com/paperless-ngx/paperless-ngx/issues/712 Edited May 1 by Greygoose Quote Link to comment
cthrumplu Posted May 9 Share Posted May 9 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? Quote Link to comment
vurt Posted May 14 Share Posted May 14 (edited) 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 May 14 by vurt Quote Link to comment
KoNeko Posted May 18 Share Posted May 18 (edited) 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 May 18 by KoNeko Quote Link to comment
druck21 Posted May 24 Share Posted May 24 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 Quote Link to comment
InCaseOf Posted Sunday at 05:34 PM Share Posted Sunday at 05:34 PM 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! Quote Link to comment
InCaseOf Posted 1 hour ago Share Posted 1 hour ago 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" " Quote Link to comment
Recommended Posts
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.