July 31, 20241 yr Nobody know, why suddenly the deprecated Letsencrypt got a new update? Is it re-maintened?
August 1, 20241 yr 6 hours ago, hundsboog said: Nobody know, why suddenly the deprecated Letsencrypt got a new update? Is it re-maintened? nope, rather ask this where lsio is active, sample, their discord its still marked deprecated ... but yes, there was a update last week
August 7, 20241 yr On 6/29/2024 at 4:04 PM, nraygun said: Oh wait, found this: https://github.com/linuxserver/docker-mods/issues/853 And in that thread, someone posted this: "Alpine's libmaxmind package was only fixed in 3.20. The issue will persist until SWAG is rebased on alpine 3.20, which will be soon" So, I guess I'll wait before messing around with the script since the version I have now shows Alpine at 3.19.1 (2.11.0-ls307). I updated to ls316(released today) and the problem with libmaxmind still exists. I'm now at Alpine 3.20 according to the release notes for this container. I still get the same "tar: invalid tar magic" when I run "/etc/periodic/weekly/libmaxminddb ". Any ideas?
August 10, 20241 yr On 8/7/2024 at 11:38 AM, nraygun said: I updated to ls316(released today) and the problem with libmaxmind still exists. I'm now at Alpine 3.20 according to the release notes for this container. I still get the same "tar: invalid tar magic" when I run "/etc/periodic/weekly/libmaxminddb ". Any ideas? I think I got it! I had to change my account ID from my email address to a series of numbers. Seems to work by executing the script now.
August 19, 20241 yr Hello How can I setup swag so that any subdomain that points to swag that is not defined in proxy-conf gets redirected to another website? This was simple to setup in NPM but cant figure out the config for it in Swag
September 20, 20241 yr I am setting up a new unraid to replace my existing server. How can I get swag to pull the certs since there nothing is pointing to the new server yet? Or should I just scp them over from the existing unraid?
November 13, 20241 yr Hi all, if anyone si facing issue with AIO NextCloud proxied through SWAG and recieving 502 Bad Gateway error hope this helps you out. TLDR use IP instead of name, check correct port, use http instead https set $upstream_app YourServerIPHere; set $upstream_port 11000; set $upstream_proto http; Long version: My setup: HP mini PC at home with Unraid server and AIO Nextcloud docker. All that behind double NAT from ISP so no chance of port forwarding Remote VPS (Strato.de minimal package with unlimited bandwith for 1 EUR/month) running ubuntu and SWAG VPS is connected with home unraid server using Tailscale plugin. Using Cloud flare DNS with my own domain.com pointed to VPS with SWAG running. (Mostly inspired by SpaceInvader One YouTube 3 part setup for Tailscale that also includes SWAG setup in part 3) Worked liked charm with minal setup for Immich, Jellyfin etc finally no issues caused by cloudflare tunnel max file limits Tried to get AIO Nextcloud running in same way. I prepared A type "nextcloud" entry in CloudFlare DNS to point to my VPS. On VPS added config entry with the correct IP, installed docker app, but when I was trying to proceed from localhost setup pages I got 502 error instead of forward through my nextcloud.mydomain.com . The issue was in the SWAG config in nextcloud, I changed following lines: FROM: set $upstream_app nextcloud; set $upstream_port 443; set $upstream_proto https; TO: set $upstream_app Your.Server.IP.Here; set $upstream_port 11000; set $upstream_proto http; Hope it helps someone. Happy to share as unraid newbie.
November 25, 20241 yr I am testing SWAG and have it setup in bridge mode and was wanting to set it to a static IP like i do with all my dockers on br0 network. Can SWAG use a static IP instead of being set to bridge mode? If so what is the best way to do this? Thank you Edited November 25, 20241 yr by JM2005
November 25, 20241 yr 10 hours ago, JM2005 said: Can SWAG use a static IP instead of being set to bridge mode? sure 10 hours ago, JM2005 said: If so what is the best way to do this? the same like 10 hours ago, JM2005 said: like i do with all my dockers on br0 network. where is your issue if you ask like this ?
November 25, 20241 yr I have a working swag setup currently using the network bridge setting and i wish to switch this (swag docker) setting to a static IP on network br0. When i attempt to switch it to br0 network and give swag itself a static IP i cannot access my sites. Any ideas to how i can do this? Thank you.
November 25, 20241 yr 2 hours ago, JM2005 said: When i attempt to switch it to br0 network and give swag itself a static IP i cannot access my sites. Any ideas to how i can do this? well, how is a site setup look like ... as sample you prolly use the pre configured ones from ../proxy-confs do you use ip's as target or names, may try ip ... are your target apps also running in custom_br0 ... so your targetting should be the default ports which should be fine anyway
November 25, 20241 yr Yeah I used the swags pre-configured proxy’s files and use each apps static docker ip and those work great with swag setup as bridge. I was just thinking of switching the swag docker to a static ip as well. I have another question as well. How would I turn off the swag landing page? I would like it to just return a 444 or 403 if possible and just be able to access my otter stuff. Thank you for your help.
November 26, 20241 yr 8 hours ago, JM2005 said: Yeah I used the swags pre-configured proxy’s files and use each apps static docker ip and those work great with swag setup as bridge. I was just thinking of switching the swag docker to a static ip as well. there is nothing special todo when using br0 mode ... i have all my dockers on br0 ... sample 8 hours ago, JM2005 said: I have another question as well. How would I turn off the swag landing page? I would like it to just return a 444 or 403 if possible and just be able to access my otter stuff. what you see is the default page, may look into read into how to change the default behaviours # redirect all traffic to https server { listen 80 default_server; listen [::]:80 default_server; location / { return 301 https://$host$request_uri; } } ... .. . # main server block server { listen 443 ssl default_server; listen [::]:443 ssl default_server; server_name _; include /config/nginx/ssl.conf; root /config/www; index index.html index.htm index.php; # enable subfolder method reverse proxy confs include /config/nginx/proxy-confs/*.subfolder.conf; ... .. . you will find many ways to either redirect to "nothing" or a custom "404 page" or ... but be sensitive and beware what you do, keep the steps in mind (backups) so you can always move back and so on ... and yes, you should read into it and not just copy / paste code without knowing what you do there ... so i wont just write a sample here, go into it to understand ... its your "door" to your home from outside, so you should really know what you do.
December 14, 20241 yr I'm very confused where I am going wrong with setting up fail2ban on SWAG reverse proxy. I am using the fail2ban included with SWAG. I have looked up every guide I could find regarding SWAG, fail2ban, Docker, and tried all fixes to get fail2ban to work, to no avail. The fail2ban properly see's the login attempts to Vaultwarden, and after max retries bans the IP, but the IP is still able to access the service. I am using a Cloudflare tunnel to accept connection, so in SWAG I use Cloudflare real IP and have confirmed the banned IP's to be actual user IP's. I believe the problem resides somewhere with iptables, but lack the knowledge to know for sure. I've attached all images that could be of any use to solve this issue. Is there anything I am doing wrong? Thank you.
December 26, 20241 yr On 12/14/2024 at 7:07 AM, GayMan420 said: I'm very confused where I am going wrong with setting up fail2ban on SWAG reverse proxy. I am using the fail2ban included with SWAG. I have looked up every guide I could find regarding SWAG, fail2ban, Docker, and tried all fixes to get fail2ban to work, to no avail. The fail2ban properly see's the login attempts to Vaultwarden, and after max retries bans the IP, but the IP is still able to access the service. I am using a Cloudflare tunnel to accept connection, so in SWAG I use Cloudflare real IP and have confirmed the banned IP's to be actual user IP's. I believe the problem resides somewhere with iptables, but lack the knowledge to know for sure. I've attached all images that could be of any use to solve this issue. Is there anything I am doing wrong? Thank you. banaction = iptables-multiport [Vaultwarden] enabled = true port = https filter = bitwarden logpath = /log/vaultwarden.log maxretry = 1 bantime = 14400 findtime = 14400 [Definition] _daemon = Bitwarden-Identity failregex = ^%(__prefix_line)s\s*\[(?:W(?:RN|arning)|Bit\.Core\.[^\]]+)\]\s+Failed login attempt(?:, 2FA invalid)?\. <ADDR>$ failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$ This is mine and here it works. Edited December 26, 20241 yr by KoNeko
December 30, 20241 yr I am having issues setting up swag to work with jellyfin. I originally setup swag to work with nextcloud using spaceinvaderones videos. Nextcloud works perfectly using cloudflare for DNS records. I have made CNAMEs for jellyfin and even trying to do mealie as well as editing their conf files accordingly. I get Bad Gateway 502 for both. They are all on their own network named proxynet. Not sure why nextcloud works and not the other two.
January 3, 20251 yr Updated today to Linuxserver.io version: 3.0.1-ls348 Build-date: 2025-01-03T16:01:30+00:00 All services are down due to emergency error (contoso.com in place of my real domain); 2025/01/03 13:33:59 [emerg] 1131#1131: cannot load certificate "/etc/letsencrypt/live/contoso.com/fullchain.pem": BIO_new_file() failed (SSL: error:80000002:system library::No such file or directory:calling fopen(/etc/letsencrypt/live/contoso.com/fullchain.pem, r) error:10000080:BIO routines::no such file) The fullchain.pem file has not changed and is in the correct location. I reverted to 3.0.0-ls336 as I noticed that the certbot version was changed in the release notes after this version. Services have returned. Please update this thread when this issue is fixed so that I can revert to current updates. Thanks!
January 7, 20251 yr Thanks @sol- I too have reverted to 3.0.0-ls336 and everything is back up and running again. In case it helps anyone who may be trying to troubleshoot the latest versions, here's where I got to before I found the above post and gave up. Have had SWAG set up successfully for use with Nextcloud for around 18 months, always updating to the latest versions when they are released. It stopped working after a recent update, with this error in the logs: 2025/01/07 15:44:42 [emerg] 1128#1128: cannot load certificate "/config/keys/cert.crt": BIO_new_file() failed (SSL: error:80000002:system library::No such file or directory:calling fopen(/config/keys/cert.crt, r) error:10000080:BIO routines::no such file) I have found that there are no files within my /config/keys/ I checked an appdata backup and found the files: root@Tower:/mnt/user/appdataold/swag/keys# ls -alh total 13K drwxrwxrwx 1 nobody users 5 Apr 29 2024 ./ drwxrwxrwx 1 nobody users 13 Dec 12 2022 ../ lrwxrwxrwx 1 nobody users 27 Apr 29 2024 cert.crt -> ./letsencrypt/fullchain.pem lrwxrwxrwx 1 nobody users 25 Apr 29 2024 cert.key -> ./letsencrypt/privkey.pem lrwxrwxrwx 1 nobody users 35 Apr 29 2024 letsencrypt -> ../etc/letsencrypt/live/domain.com/ Tried to copy them across to the live appdata dir and got this error: root@Tower:/mnt/user/appdataold/swag/keys# cp -L * /mnt/user/appdata/swag/keys cp: not writing through dangling symlink '/mnt/user/appdata/swag/keys/cert.crt' cp: not writing through dangling symlink '/mnt/user/appdata/swag/keys/cert.key' cp: -r not specified; omitting directory 'letsencrypt' So I then successfully copied the files and letsencrypt dir across using: cp --remove-destination -r * /mnt/user/appdata/swag/keys cp --remove-destination cert.crt /mnt/user/appdata/swag/keys cp --remove-destination cert.key /mnt/user/appdata/swag/keys The files were there, but as soon as I started the SWAG container, they would be deleted. So I tried changing them all to read only: And yet they were still removed as soon as I started SWAG.
January 17, 20251 yr On 11/13/2024 at 6:23 PM, Drobek_MucQ said: Hi all, if anyone si facing issue with AIO NextCloud proxied through SWAG and recieving 502 Bad Gateway error hope this helps you out. TLDR use IP instead of name, check correct port, use http instead https set $upstream_app YourServerIPHere; set $upstream_port 11000; set $upstream_proto http; Long version: My setup: HP mini PC at home with Unraid server and AIO Nextcloud docker. All that behind double NAT from ISP so no chance of port forwarding Remote VPS (Strato.de minimal package with unlimited bandwith for 1 EUR/month) running ubuntu and SWAG VPS is connected with home unraid server using Tailscale plugin. Using Cloud flare DNS with my own domain.com pointed to VPS with SWAG running. (Mostly inspired by SpaceInvader One YouTube 3 part setup for Tailscale that also includes SWAG setup in part 3) Worked liked charm with minal setup for Immich, Jellyfin etc finally no issues caused by cloudflare tunnel max file limits Tried to get AIO Nextcloud running in same way. I prepared A type "nextcloud" entry in CloudFlare DNS to point to my VPS. On VPS added config entry with the correct IP, installed docker app, but when I was trying to proceed from localhost setup pages I got 502 error instead of forward through my nextcloud.mydomain.com . The issue was in the SWAG config in nextcloud, I changed following lines: FROM: set $upstream_app nextcloud; set $upstream_port 443; set $upstream_proto https; TO: set $upstream_app Your.Server.IP.Here; set $upstream_port 11000; set $upstream_proto http; Hope it helps someone. Happy to share as unraid newbie. Thanks for your detail here, I used it to get things working just! I followed Spaceinvader One's Effortless Nextcloud AIO Setup on Unraid tutorial, I wanted to use my existing proxynet swag setup from his previous Installing Nextcloud on Unraid 2022 pt1 instead of using tailscale. When I installed the nextcloud-aio-mastercontainer I selected my network type as Custom: proxynet, this is the custom docker network swag is on. Once the AIO containers all downloaded I modified my SWAG files below: My original SWAG nextcloud.subdomain.conf server { listen 443 ssl; listen [::]:443 ssl; server_name nextcloud.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app nextcloud; set $upstream_port 443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; # Hide proxy response headers from Nextcloud that conflict with ssl.conf # Uncomment the Optional additional headers in SWAG's ssl.conf to pass Nextcloud's security scan proxy_hide_header Referrer-Policy; proxy_hide_header X-Content-Type-Options; proxy_hide_header X-Frame-Options; proxy_hide_header X-XSS-Protection; # Disable proxy buffering proxy_buffering off; } } Amended SWAG when using Nextcloud AIO server { listen 443 ssl; listen [::]:443 ssl; server_name nextcloud.domain.tld; include /config/nginx/ssl.conf; client_max_body_size 0; location / { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app IPYOUACCESSUNRAIDON(EG192.168.1.80); set $upstream_port 11000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; # Hide proxy response headers from Nextcloud that conflict with ssl.conf # Uncomment the Optional additional headers in SWAG's ssl.conf to pass Nextcloud's security scan proxy_hide_header Referrer-Policy; proxy_hide_header X-Content-Type-Options; proxy_hide_header X-Frame-Options; proxy_hide_header X-XSS-Protection; # Disable proxy buffering proxy_buffering off; } } To highlight what I have changed: server_name the full url used before for your nextcloud install e.g nextcloud.yourdomainame.com upstream_app UNRAIDSERVERIP; upstream_port 11000; upstream_proto http; (this was HTTPS) I also uncommented the following in the SWAG ssl.conf file to remove the errors showing in nextcloud. add_header Referrer-Policy "same-origin" always; add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header X-XSS-Protection "1; mode=block" always; Can someone check I have this right.. its working and gets A+ on ssllabs and the nextcloud test. FYI I cannot get the nextcloud-aio-domaincheck to run, it gives me Execution error server error, I think this is due to the fact that the LAN IP:Port is the same as the nextcloud-aio-apache LAN IP:Port.
January 23, 20251 yr I'm looking for some guidance here, as I'm not sure what I'm doing wrong. I setup Kimai to work through SWAG on a non-standard HTTPS port and SWAG keeps dropping the port. SWAG is setup on its own network with Kimai and properly resolves. The external HTTPS port for SWAG is 8450. When I hit https://kimai.mydomain.com:8450, it spins for a bit and then redirects to https://kimai.mydomain.com/en/login, which doesn't work. If I manually modify the URL to https://kimai.mydomain.com:8450/en/login, then it works, but the very next thing I do within the webpage repeats the problem. Obviously it's not really usable in that state. Nextcloud container is setup basically in the same way, and works without issue. I've been searching around the documentation, the nginx documentation (which is really sparse and esoteric), stackoverflow, reddit, here, etc and trying all manner of things and I just can't figure out what changes I need to make to kimai.subdomain.conf to get it to work consistently. absolute_redirect off or on don't seem to change anything, port_on_redirect on or off don't seem to do anything, some people suggest adding a / to the end of the proxy_pass URL and that just breaks the website (502), some suggest using proxy_redirect but I can't seem to get that to work no matter what I try, so any help would be appreciated. I've added the conf file below. Some of the commented out items are things that I tried and couldn't get to work based on documentation from kimai, the swag default, the configuration for nextcloud I have that works in the way I'm expecting this to work, etc. Also, if I understand what I've read right, I think the second location here is if using kimai as a subfolder rather than a subdomain? ## Version 2024/07/16 # make sure that your kimai container is named kimai # make sure that your dns has a cname set for kimai server { listen 443 ssl; listen [::]:443 ssl; server_name kimai.*; 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 kimai; set $upstream_port 443; set $upstream_proto https; #set $dest_port 8450; proxy_pass $upstream_proto://$upstream_app:$upstream_port; #proxy_pass https://172.18.0.4/; #proxy_redirect $upstream_proto://$upstream_app:$upstream_port/ $upstream_proto://$upstream_app:$dest_port/; #absolute_redirect off; #port_in_redirect on; #proxy_set_header Host $http_host; #proxy_set_header X-Real-IP $remote_addr; #proxy_set_header X-Forwarded-Host $host:$upstream_port; #proxy_set_header X-Forwarded-Server $host; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #proxy_set_header X-Forwarded-Proto $scheme; #proxy_set_header X-Forwarded-Port $upstream_port; proxy_buffering off; } location ~ (/kimai)?/api { include /config/nginx/proxy.conf; include /config/nginx/resolver.conf; set $upstream_app kimai; set $upstream_port 443; set $upstream_proto https; #set $dest_port 8450; proxy_pass $upstream_proto://$upstream_app:$upstream_port; #proxy_pass https://172.18.0.4/; #proxy_redirect $upstream_proto://$upstream_app:$upstream_port/ $upstream_proto://$upstream_app:$dest_port/; #absolute_redirect off; #port_in_redirect on; #proxy_set_header Host $http_host; #proxy_set_header X-Real-IP $remote_addr; #proxy_set_header X-Forwarded-Host $host:$upstream_port; #proxy_set_header X-Forwarded-Server $host; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #proxy_set_header X-Forwarded-Proto $scheme; #proxy_set_header X-Forwarded-Port $upstream_port; proxy_buffering off; } } Edited January 23, 20251 yr by bhcompy
January 23, 20251 yr 45 minutes ago, bhcompy said: I do within the webpage repeats the problem. may rather take a look at the apps configuration, i dont know kimal now, but is there something to set the external url ? may your non native https port needs to be added to the url there too ... also, may if kimal is somehow calling http, your redirect rule in the default site conf from nginx will redirect to https ... may consider changing this to your custom https port too ... overall, not the best idea to use a custom https port but you will have your reasons ... and you are aware its "off" standard ...
January 29, 20251 yr I have several subdomains all pointing at my server and going through SWAG just fine, their conf files adjusted for the correct domain name and I am able to access them anywhere. Mealie however just wont work. I get a 502 bad gateway error. So I know it's getting to the server but stopping at swag. I have looked repeatedly at the conf file but it is exactly like the others that do work (mealie.*) and yet it wont point at the docker container.
January 29, 20251 yr 54 minutes ago, cosmicrelish said: and yet it wont point at the docker container. you may should provide some more infos so someone could help. how is your config ? lets say, where do you point to exactly ... and which port. and may a docker run from your mealie docker
January 29, 20251 yr Here is the conf file for Mealie that is in the swag proxy-conf folder. My subdomain is food.***.com I also have this domain listed in the SWAG container where the others are. ## Version 2024/07/16 # Ensure your DNS has a CNAME set for mealie and that mealie container is named. server { listen 443 ssl; listen [::]:443 ssl; server_name food.*; 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 mealie; set $upstream_port 9000; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; } }
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.