DieFalse

What do you get from a terminal window when you type: sensors sensors-detect

Type IT87 where LM78 is and click save. then check the drop downs.

Right now 32GB however, upgrading today to new board/cpu with 128GB. Damned VM's keep wanting more lol.

Does this still work or is there a better way? I have had my USB die off and the downtime was not fun nor was getting my backup to actually load correctly.

Perfect!!!! That got what was different. 'overwrite.cli.url' => 'https://my.xxxxxxxxx.com/nextcloud', needed to be 'overwrite.cli.url' => 'https://my.xxxxxxxxx.com', now this works as anticipated. No clue why that would cause it to revert to https://IP vs domain.... strange! Thank you for supporting and helping even though its not 100% identical. It was very helpful.

My config.php is not complicated.... its the one you posted.... Maybe you mis-read and thought the nginx site conf was also in the config.php? here is Just the config.php ( and I will simplify it even more by removing redundancies) Config.php which has the overwritewebroot in it already. <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'ocgu1s592brc', 'passwordsalt' => 'saltremoved', 'secret' => 'secretremoved', 'trusted_domains' => array ( 0 => '192.168.1.175:444', 1 => 'my.xxxxxxxx.com/nextcloud', ), 'trusted_proxies' => array ( 0 => '192.168.1.175', 1 => 'my.xxxxxxxxxx.com', 2 => 'my.xxxxxxxx.com/nextcloud', ), 'overwritewebroot' => '/nextcloud', 'overwritehost' => 'my.xxxxxxx.com', 'overwrite.cli.url' => 'https://my.xxxxxxxxx.com/nextcloud', 'overwriteprotocol' => 'https', 'dbtype' => 'sqlite3', 'version' => '13.0.0.14', 'installed' => true, MAIL INFO REDACTED );

My "Domain.com" is under a commercial SSL certificate. I am using LE for my.domain.com only. I can not use domain.com to create a wildcard through LE. I don't want to continue to derail the thread to figure that issue out as I am soon going to be registering a new domain for use solely for the server, so I will address that then. As for this config, here are the two files I modified: Config.php <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'ocgu1s592brc', 'passwordsalt' => 'saltremoved', 'secret' => 'secretremoved', 'trusted_domains' => array ( 0 => '192.168.1.175:444', 1 => 'my.xxxxxxxx.com', 2 => 'www.my.xxxxxxxx.com', 3 => 'cloud.xxxxxxxx.com', 4 => 'nextcloud.xxxxxxx.com', 5 => 'my.xxxxxxxx.com/nextcloud', ), 'trusted_proxies' => array ( 0 => '192.168.1.175', 1 => 'my.xxxxxxxxxx.com', 2 => 'nextcloud.xxxxxxx.com', 3 => 'my.xxxxxxxx.com/nextcloud', ), 'overwritewebroot' => '/nextcloud', 'overwritehost' => 'my.xxxxxxx.com', 'overwrite.cli.url' => 'https://my.xxxxxxxxx.com/nextcloud', 'overwriteprotocol' => 'https', 'dbtype' => 'sqlite3', 'version' => '13.0.0.14', 'installed' => true, MAIL INFO REDACTED ); LE-NGINX-siteconf-default server { listen 80; server_name my.xxxxxxxx.com nextcloud.xxxxxxxxx.com cloud.xxxxxxxxx.com; return 301 https://$server_name$request_uri; #enforce https } server { listen 443 ssl http2 default_server; root /config/www; index index.html index.htm index.php; server_name my.xxxxxxxxx.com nextcloud.xxxxxxxxx.com cloud.xxxxxxxxx.com; #add_header Strict-Transport-Security max-age=31536000 always; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; client_max_body_size 0; #PLEX location /web { # serve the CSS code proxy_pass http://192.168.1.175:32400; } #Main /plex rewrite location /plex { # proxy request to plex server proxy_pass http://192.168.1.175:32400/web; } location /stats { #proxy plexpy to server proxy_pass http://192.168.1.175:8181; } location /jackett { #proxy jackett to server proxy_pass http://192.168.1.175:9117; } location /couch { #proxy couchpotato to server proxy_pass http://192.168.1.175:5050; } location /sonarr { #proxy sonarr to server proxy_pass http://192.168.1.175:8989; } location /nowshowing/ { #proxy nowshowing to server proxy_pass http://192.168.1.175:6878/; } location /nextcloud { proxy_pass https://192.168.1.175:444/nextcloud; } location /htpc { #proxy htpcmanager to server proxy_pass http://192.168.1.175:8085; } location /request { return 301 $scheme://$host/request/; } location /request/ { proxy_pass http://192.168.1.175:3579; proxy_set_header Host $host; proxy_set_header X-Forwarded-Host $server_name; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Ssl on; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 90; proxy_redirect http://127.0.0.1:5000 https://$host; } if ($http_referer ~* /request/) { rewrite ^/dist/(.*) $scheme://$host/request/dist/$1 permanent; } }

I ran into a problem where my SSL is not valid for https://sub.vanitydomain.com as I use a ssl for https://my.vanitydomain.com so I have to use /nextcloud to use this SSL, also, with 1&1 hosting, I can not get https://nextcloud.vanitydomain.com to goto a "port" as I can only forward 443/80 to one IP in my network. If I put nextcloud.vanitydomain.com I have no way to point it to nexcloud directly. The ONLY thing from the guide that changed was pointing to the /nextcloud instead of x.y.z There has to be a setting or configuration that changes the domain call to the internal IP. I understand the not "supporting" but can you atlease point me to what would revert to internal vs external? I have the overwrite cli/web/host all set to the right endpoints. I followed the guide in the first post and the link to the "letsencrypt nginx settings page" which also spoke about /x and showed the example for it.

I followed the tutorial in the first post and all works on the local network. When accessing the reverse proxy outside of the network it changes my domain to my internal IP and fails. from: https://myvanitydomain.com/nextcloud to https://192.168.1.175/nextcloud/ If I am on VPN it works app and all, off VPN, it fails due to this. What would cause this?

Yes it is reverse proxies through nginx letsencrypt, I have read back to page 6 and only see one mention of a grey login screen but have yet to see what causes it or the proposed fix. I can access it locally non proxied so I can assume it's in the reverse proxy configuration and maybe a permissions of a resource it cant see, kind of like serving the plex css addition of /web to make plex work correctly. Am I atleast on the right track?

I've been using and love this docker for several months now, however with the latest update (now has backgrounds on login page) the page will not load on any mobile devices. It says "Loading...." and then blanks out. Has anyone heard or seen this problem yet?

Hello MarkusMcNugen, First and foremost, Thank you for these! It's nice to see alternatives! Having used binhex's dockers, I have been able to verify that there is zero traffic going out if the VPN drops with his. How can I be sure of this with your qbittorrentvpn client? I like qbittorrent better than deluge and would love to use it, but I want to be certain it can not leak info.

Yep.. I broke something. After getting the LE challenge fixed and server up, no response on http or https. [cont-init.d] 50-config: exited 0. [cont-init.d] done. [services.d] starting services [services.d] done. Server ready *** Found it. default had the old ports in it. updated and all is back online.

Yea, I got that part after you said it was a separate process. I don't know what broke, Its on port 80 and 443 with forwarding. I checked by moving the mapping of another process to port 80 and 443 and its not blocked by isp. Maybe I need to hose it. strange.

Got ya... I must have broke something then. (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain ::

I have run into a strange problem. HTTPS works perfectly however now nginx is ignoring port 80 no matter what. going to port 80 with proper mapping and all reports connection refused. Is there somewhere in the nginx config that controls regular http access?

Your docker shows 442 for the SSL but your forwarding in the router shows 443

Is there any chance the docker will be updated to support the new port-forwarding servers on PIA? one of the following port forwarding enabled gateways: CA Toronto CA Montreal CA Vancouver Czech Republic Netherlands Spain Switzerland Sweden France Germany Romania Israel Currently the script looks for: [warn] PIA endpoint 'czech.privateinternetaccess.com' doesn't support port forwarding, DL/UL speeds will be slow [info] Please consider switching to an endpoint that does support port forwarding, shown below:- [info] ca-toronto.privateinternetaccess.com (CA Toronto) [info] ca.privateinternetaccess.com (CA Montreal) [info] nl.privateinternetaccess.com (Netherlands) [info] swiss.privateinternetaccess.com (Switzerland) [info] sweden.privateinternetaccess.com (Sweden) [info] france.privateinternetaccess.com (France) [info] ro.privateinternetaccess.com (Romania) [info] israel.privateinternetaccess.com (Israel)

Ok, so I found that upnp was forcing a separate port 80 config. This caused the conflict. I cleared my conflict and now have a cert. In configuring the reverse proxy, any http(s)://my.domain.com/SERVICE pulls the main html and not the service.

Yes, I have forwarded from my subdomain.domain.com to my WAN ip. I use this same setup different.domain.com with no issues. If I went to http://sub.domain.com:anyport it will still resolve and is pingable. Tracert shows it going to my machine. Full Log (took a min to clean): ------------------------------------- _ () | | ___ _ __ | | / __| | | / \ | | \__ \ | | | () | |_| |___/ |_| \__/ Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 20-config: executing... [cont-init.d] 20-config: exited 0. [cont-init.d] 30-keygen: executing... using keys found in /config/keys [cont-init.d] 30-keygen: exited 0. [cont-init.d] 50-config: executing... 2048 bit DH parameters present SUBDOMAINS entered, processing Only subdomains, no URL in cert Sub-domains processed are: -d my.xxxxxxx.com E-mail address entered: [email protected] Different sub/domains entered than what was used before. Revoking and deleting existing certificate, and an updated one will be created usage: certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ... Certbot can obtain and install HTTPS/TLS/SSL certificates. By default, it will attempt to use a webserver both for obtaining and installing the certificate. certbot: error: argument --cert-path: No such file or directory Generating new certificate Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for my.xxxxxxx.com Waiting for verification... Cleaning up challenges Failed authorization procedure. my.xxxxxxx.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://my.xxxxxxx.com/.well-known/acme-challenge/dgTrPK7WHHxA87urYp9N1s12CdEYXcPhbZgOOsWEOag: "<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www." IMPORTANT NOTES: - The following errors were reported by the server: Domain: my.xxxxxxx.com Type: unauthorized Detail: Invalid response from http://my.xxxxxxx.com/.well-known/acme-challenge/dgTrPK7WHHxA87urYp9N1s12CdEYXcPhbZgOOsWEOag: "<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www." To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. ERROR: Cert does not exist! Please see the validation error above. The issue may be due to incorrect dns or port forwarding settings. Please fix your settings and recreate the container [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] syncing disks. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting. Helpful or Useless info: Going to http://127.0.0.1:81/ does not open any page... nor https://127.0.0.1:7443/

Run Command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="letsencrypt" --net="bridge" --privileged="true" -e TZ="America/Chicago" -e HOST_OS="unRAID" -e "EMAIL"="[email protected]" -e "URL"=xxxxxx.com" -e "SUBDOMAINS"="my," -e "ONLY_SUBDOMAINS"="true" -e "DHLEVEL"="2048" -e "PUID"="99" -e "PGID"="100" -e "HTTPVAL"="true" -p 81:80/tcp -p 7443:443/tcp -v "/mnt/user/appdata/letsencrypt":"/config":rw linuxserver/letsencrypt Firewall fwding: lan-interface eth1 rule 1 { description encrypt forward-to { address 192.168.1.175 port 81 } original-port 80 protocol tcp_udp } rule 2 { description encrypt2 forward-to { address 192.168.1.175 port 7443 } original-port 443 protocol tcp_udp } Error: Failed authorization procedure. my.xxxxxx.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://my.xxxxxx.com/.well-known/acme-challenge/1Eq0-WkG_ENPwv59yFCqtUfWQ2CqYo8F0-Bm4hXTheY: "<?xml version="1.0" encoding="iso-8859-1"?>

Ok, for the life of me, following as many different guides as I could so far, I still can not get this to work. I own a domain name and have my.domain.com set to forward to my IP. I have setup LE and keep getting this error: Failed authorization procedure. my.xxxxxx.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://my.xxxxxx.com/.well-known/acme-challenge/1Eq0-WkG_ENPwv59yFCqtUfWQ2CqYo8F0-Bm4hXTheY: "<?xml version="1.0" encoding="iso-8859-1"?> What causes this error?

Thank you, sorry I PM'd the diagnostics. what caused it?

Being new to this, would you mind telling me which diagnostics you would like?

Warning: A non-numeric value encountered in /usr/local/emhttp/plugins/fix.common.problems/include/tests.php on line 1085 This shows after the recent update.