Gog

Radarr is looking for the file /home11/mih... but it doesn't have access to that. It only has access to /downloads. The link @jonathanm gave you applies

dumb question but did you tell your downloader to use /downloads instead of /data? What is the error message in the application? If you open a command prompt in both dockers, you should be able to see the file uing the same path.

You should not have to open a port in the firewall, your reverse proxy should pick up the request on 443 and send the request to the heimdall's port. That is the whole point of a reverse proxy, to block your internal ports from direct access from the internet. It seems you need to configure heimdall in the letsencrypt config folder. Take a look at the samples the linuxserver team already has ready: https://github.com/linuxserver/reverse-proxy-confs

There are many config files that have an impact on the nextcloud uploads, especially if you use a reverse proxy. Letsencrypt's proxy.conf and nextcloud config plus nextcloud's own nginx config files. Have you looked for size limitation in all of those? In my case it was letsencrypt's proxy conf that was bugging me

looks like MariaDB is refusing access to your xnextcloud user. Make sure the user is ser to accept connections from the IP of the nextcloud container. Try "from host %" in the xnextcloud user permissions

There you go: server { listen 80; server_name _; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name gallery.*; include /config/nginx/ssl.conf; client_max_body_size 0; location / { proxy_pass http://192.168.1.111:8093/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # try_files $uri $uri/ /index.html /index.php?$args =404; } }

I have it configured now as a subdomain and it works. Haven't tried to set it as a subfolder in ages. I'll post the nginx .conf file tonight.

Mine autoupdated 2 nights ago and it's still working through the proxy

Anybody else is seeing some tiles losing the "pinned" status without intervention and the tiles move around? I may be going mad...

I did an update of the container yesterday and the grocy template is not there. The samples timestamps look like they are from the last container restart but no groxy. How can I force that?

Care to share the LE config?

In nginx config, change proxy pass to the url you use internally to reach HA Sent from my SM-G930W8 using Tapatalk

I just tried installing the container and it is configured as host network. It may not like the bridge config. Can you try changing network type to host in the container config? Nging won't reach it after that but we can fix it later Sent from my SM-G930W8 using Tapatalk

I forget the choices for connection type.. Is there TCP and rdp? Does the container start with that port? Something else may be using it. I dont see it in your screenshot though so it's probably not that... Sent from my SM-G930W8 using Tapatalk

That looks good. Sent from my SM-G930W8 using Tapatalk

It looks like you are not exposing any ports to the outside. It works for nginx because the traffic goes through proxynet, the custom network interface. In HomeAutomation, add a port mapping with the + at the bottom of the container settings. Map 8123 to 8123. You are telling the docker to let requests that hit your unraid server on port 8123 to let that through the HomeAutomation container on port 8123.

Hi Speedmax For local access you are not going through nginx. When you use 192.168.*.* the settings you need to look at are your docker container port mapping. Can you share the docker config? Sent from my SM-G930W8 using Tapatalk

Are you using a custom network interface? This: set $upstream_bitwarden Bitwarden Will not work until you do. With a custom docker network interface, internal DNS will translate "Bitwarden" to 10.10.8.28 but it won't work with the standard bridge interface. Sent from my SM-G930W8 using Tapatalk

That is exactly what @mkono87 did just before you. Use LetsEncrypt handle the SSL certificate for you and reverse proxy nextcloud through it. No need to go through the certificate generation and worry about renewal, letsencrypt is free and auto renews.

I wouldn't be too worried about the hash size. Do you get the same behavior if you try to connect with https://192.168.0.50:446 ? Do you see the connection go through in the letsencrypt access log?

config.php looks good. I'm not sure 'trusted_proxies' => ['letsencrypt'] is essential, it was missing from mine for the site-config, change proxy_pass https://$upstream_nextcloud:443; to proxy_pass https://192.168.0.50:446; and you can remove: set $upstream_nextcloud nextcloud; That's the bit that needs the custom network interface.

It can work without the custom interface but you'll have to modify the template, give it your server IP. Please start by reading the template, all the info is in there as to what you need to modify to get it working. If you can't figure out how to put your server's IP in there, I can help.

Did you check the instructions in the nextcloud config sample? Do you have a custom network interface defined? (docker network create forletsencrypt0). Is nextcoud using that network interface in the container definition?

delete the docker and also delete the appdata subdirectory for the docker

What do you mean? Your VPN provider is not using a username and password to authenticate you? There is also this feature in your ovpn file that doesn't seem to be supported: block-outside-dns