kamhighway

@Azza666 and @Kewjoe, Glad this post was helpful to you. I tried a lot of things, and when I finally got it working I knew that if I didn't write it down I'd never be able to redo it if I had to. Thought this was a good place to write it down so I could find it again if needed and also to see if I am the only one having these problems.

Thats right. I remember having to do that. It seemed scary to wipe out docker.img. The guys who know what they are doing said they do it all the time and it should only take a few minutes to recreate it. Trust them on this.

@Naldinho, When I had the problem I learned that in Unraid 6.2 they had upgraded the version of Docker. I don't know what the new version of Docker changed, but I was told the dockers were backward compatible to the version included with 6.1.9. I don't think that is true in all cases -- but smarter people than me have said so. After nuking the docker and reinstalling it fresh, I still had the same problem. That's when I decided to upgrade to 6.2 to test the assertion that it could not be the problem. All I can tell you is that after upgrading to 6.2, the docker started working.

I can get mybb installed and working in a container when the webroot is in the container. However, if I map /var/www/webroot to /mnt/cache/appdata/mybb and then install mybb I get a 403 Forbidden error. I think the problem is permissions. When mybb installs inside the container, everything works. When mybb is installed to a mapped UR share, it doesn't work. Has anyone else run into this problem? Update: so the answer was to set permissions to 755. chmod 755 /path/of/your/directory/ -v did the trick

@noja, glad you got it to work. Sometimes nuking things and starting over is the best way to go. Since there is such a learning curve on this one, I wrote a post to describe the whole process while it is fresh in my mind. Here is the link: http://lime-technology.com/forum/index.php?topic=51466.0 Hope it is helpful to others.

There are four files that need to be edited. First: On my system is at /mnt/cache/appdata/letsencrypt/nginx/site-confs/default. The exact location of your file depends on where you mapped /config to for Aptalca's docker. Here is my file: server { listen 443 ssl default_server; root /config/www; index index.html index.htm index.php; server_name kamhighway.com www.kamhighway.com ; ssl_certificate /config/keys/fullchain.pem; ssl_certificate_key /config/keys/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; location / { try_files $uri $uri/ /index.html /index.php?$args =404; } location /nextcloud { include /config/nginx/proxy.conf; proxy_pass https://192.168.x.xxx:xxx/nextcloud; } } Second: /mnt/cache/letsecrypt/nginx/proxy.conf. This file does not exist in a fresh install. It must be created. I copied this from Aptalca's post on page 5 of the support forum for letsencript. Here's mine: client_max_body_size 10m; client_body_buffer_size 128k; #Timeout if the real server is dead proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; # Advanced Proxy Config send_timeout 5m; proxy_read_timeout 240; proxy_send_timeout 240; proxy_connect_timeout 240; # Basic Proxy Config proxy_set_header Host $host:$server_port; 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 https; proxy_redirect http:// $scheme://; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_cache_bypass $cookie_session; proxy_no_cache $cookie_session; proxy_buffers 32 4k; Third: /mnt/cache/appdata/nextcloud/config/nginx/site-confs/defaults. Look for this: # Path to the root of your installation root /config/www/nextcloud/; # set max upload size client_max_body_size 10G; fastcgi_buffers 64 4K; Change it to this: # Path to the root of your installation root /config/www/; # set max upload size client_max_body_size 10G; fastcgi_buffers 64 4K; Fourth: /mnt/cache/appdata/nextcloud/config/www/nextcloud/config/config.php. Here is mine: <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'xxxxxxxxxxxxxxx', 'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxx', 'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'trusted_domains' => array ( 0 => '192.168.x.xxx', 1 => 'www.kamhighway.com', 2 => 'kamhighway.com', ), 'trusted_proxies' => array ( 0 => '192.168.x.xxx', ), 'overwritewebroot' => '/nextcloud', 'overwritehost' => 'kamhighway.com', 'overwrite.cli.url' => 'https://192.168.x.xxx', 'dbtype' => 'mysql', 'version' => '9.0.51.0', 'dbname' => 'nextcloud', 'dbhost' => '192.168.x.xxx:3306', 'dbtableprefix' => 'oc_', 'dbuser' => 'xxxxxxx', 'dbpassword' => 'xxxxxxxxxxxxxxxxxxxxxxxx', 'logtimezone' => 'UTC', 'installed' => true, 'mail_smtpmode' => 'smtp', 'ldapIgnoreNamingRules' => false, ); After you make these changes to the four files, make these changes to the dockers Map port 443 on Aptalca's docker to port 443 on the host. Set your router to forward port 443 to port 443 on your unraid server. On LSIO's nextcloud docker change the web UI to point to https://192.168.x.xxx:xxx/nextcloud/. Restart both dockers. You should now be able to a reach nextcloud from outside of your network at https://domain.com/nextcloud/ From inside your network, you can reach nextcloud at https://192.168.x.xxx:xxx/nextcloud/. Hope this is helpful to someone.

@noja, I think the missing trailing comma for your 'trusted_proxies' in your nextcloud nginx conf file is causing a lot of your problems. It may be preventing Nextcloud from starting up.

In the nextcloud config.php your trusted proxies are entered differently than mine. Here's what you have: 'trusted_proxies' => ['172.16.100.5'] Here's what I have: 'trusted_proxies' => array ( 0 => '192.168.183', ), You are missing a trailing comma, and I'm not sure what the square brackets do. If the square brackets are another way to specify an array, then they are fine. Also, you have 'overwritewebroot' => '/nextcloud/', I have 'overwritewebroot' => '/nextcloud', Your nextcloud nginx conf file looks identical to mine. Your letsencrypt nginx conf file looks like it should work.

@noja post your nginx conf file from letsencrypt, your nginx conf file from nextcloud, and your config.php from nextcloud. All three have to be in sync for this to work.

@noja, Try Peter_SM's suggestion. But I see a couple of things that might also be causing you some trouble. <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'oczmltajpdti', 'passwordsalt' => 'zzatfiwjAV0CPgMqay8ewbvahBwBj3', 'secret' => 'Yio64EkchFlzBg4GkKfsyjsktEaLmaSVu+q3LSmtBW/ZEgUu', 'trusted_domains' => array ( 0 => '172.16.100.5', 1 => 'https://domain.com' #<-------------remove https:// and just leave domain.com ), 'overwrite.cli.url' => 'https://172.16.100.5:8443', 'dbtype' => 'mysql', 'version' => '9.0.53.0', 'dbname' => 'NextCloud', 'dbhost' => '172.16.100.5:3306', 'dbtableprefix' => 'oc_', 'dbuser' => 'xxxx', 'dbpassword' => 'xxxxx', 'logtimezone' => 'UTC', 'installed' => true, 'trusted_proxies' => ['172.16.100.5'] 'overwritewebroot' => '/nextcloud', 'overwritehost' => 'https://domain.com', #<-------------remove https:// and just leave domain.com );

edit the nginx site-conf in the Nextcloud docker. It should be in your appdata folder. Change this # Path to the root of your installation root /config/www/nextcloud; to this # Path to the root of your installation root /config/www/; Then in the nginx conf file for lets encrypt, change this location /nextcloud/ { proxy_pass https://192.168.0.190:446/nextcloud; rewrite ^/nextcloud$ /nextcloud/ permanent; rewrite ^/nextcloud/(.*) /$1 break; } to this location /nextcloud { proxy_pass https://192.168.0.190:446/nextcloud; } This should get you back to the login screen with the css at either www.xxxx.com/nextcloud or 192.168.0.190:446/nextcloud.

try changing from 'trusted_domains' => array ( 0 => '192.168.0.190:446', 1 => 'www.xxxxx.com', ), to this 'trusted_domains' => array ( 0 => '192.168.0.190', 1 => 'www.xxxxx.com', ),

I may have misread your message. Are you saying that you cannot access nextcloud at www.xxxx.com/nextcloud, or that you can't access it at 192.168.9.190:446? I used to get to a login screen that looked like the png you posted. The problem I had was the proxypass codeblock in letsencrypt's nginx config file was not passing through to the login page but to a page inside of the nextcloud. That's why the css is missing. I tried the approach you used with the rewrite statements but could not get it to work. Ken-ji, however, says the rewriting statements do work for his app. I got nextcloud to work by editing the nginx config file in the Nextcloud docker to set the web root one directory above where it was originally. Then I didn't need the rewrite rules.

I think you need to add your domain.com as a trusted domain. <?php $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'oc3nh4ucquft', 'passwordsalt' => 'tuSxRj4T9h5mRkB+eHqU+iZ1j/eV6l', 'secret' => 'bb+Ad/15J48oAaayi/NJ9vebkxoD3frseuwh+fZXE8HR9JAs', 'trusted_domains' => array ( 0 => '192.168.0.190:446', 1 => 'www.xxxxx.com', #<--------Add this line ), 'overwrite.cli.url' => 'https://192.168.0.190:446', 'dbtype' => 'sqlite3', 'version' => '9.0.53.0', 'logtimezone' => 'UTC', 'installed' => true, 'updater.release.channel' => 'stable', 'trusted_proxies' => array ( 0 => '192.168.0.190', ), 'overwritewebroot' => '/nextcloud', 'overwritehost' => 'www.xxxxx.com', );

@ken-ji, Thanks for letting me know. Its always good to have another way to solve a problem.

@ken-ji, I've got nextcloud working a different way which I've described in a previous post. But I'm curious to know if this approach works for you?

@lespaul and @ken-ji When I tried this -- rewrite ^/nextcloud(/.*)$ $1 break; -- the problem I had was that the application communicates through the reverse proxy at location / instead of location /nextcloud. In other words, I could get to the login screen by typing domain.com/nextcloud but then the application would send back urls that did not have the uri /nextcloud so they would get handled by location / instead of location /nextcloud. To make sure the back and forth communication through the reverse proxy is handled by the right nginx location block, the application needs to include the URI /nextcloud in any app-generated URLs.

@itsdandandan I don't use plex requests so I don't think I can help you. It seems that each application/docker needs to be configured so the app can be accessed through a URL_BASE. Some apps have a variable to set it and some don't. In the case of Nextcloud, there are also variables to set so that nextcloud generated urls will work when being accessed through the reverse proxy. This is a long way to say that each application/docker needs to be looked at individually. However, I think you need to set a URL_Base and then change the proxy pass url to http://192.168.1.xx:3000/URL_Base. Based on what Aptalca said today, the location should match the URL_Base, so replace location /requests with location /URL_Base. Give that a try.

@aptalca, Thanks for that clarification. I could not see exactly what was being passed to the proxied server, so I had to read the nginx manual -- and still got it wrong. Based on the example you posted on page 5, I thought that all the settings to get the reverse proxy working were in the config files for nginx in the letsencrypt docker. What I was missing was that the proxy pass URL needs to include the webroot of the proxied webserver. This means that any docker that enables its app to be accessed at IP:XXXX/ (such as lsio's nextcloud) needs to be reconfigured so the app can be accessed at IP:XXXX/webroot if you want to access it from behind a reverse proxy. Thank you for your work on the letsencrypt docker. Being able to use it as a reverse proxy server is going to make my life simpler.

This is a portion of Aptalca's nginx.conf from his post on page 5. server { listen 443 ssl default_server; ssl_certificate /config/keys/fullchain.pem; ssl_certificate_key /config/keys/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 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; location / { root /config/www; index index.html index.htm index.php; auth_basic "Restricted"; auth_basic_user_file /config/nginx/.htpasswd; } location /sab { include /config/nginx/proxy.conf; proxy_pass http://192.168.X.X:XXXX/sabnzbd; } } As I read the nginx reverse proxy guide https://www.nginx.com/resources/admin-guide/reverse-proxy/, when the location is anything other than "/", nginx will add it to the url that is given in the proxy_pass statement. I think this means that the location /sab in the settings file above is being passed to http://192.168.x.x:xxxx/sabnzbd/sab. If that is the correct url to access sab, then I can see how Aptalca's conf works. My problem is that lsio's nextcloud docker responds on https://192.168.x.x:xxxx. If I use this URL in a proxy_pass statement for location / it works. But if I use the same URL in a proxy_pass statement for location /nextcloud, it fails. I have attempted to use a rewrite as follows: location /nextcloud { rewrite ^/nextcloud(.*) /$1 break; proxy_pass https://192.168.x.xxx:xxxx; } But, this does not work. I'm stumped. Would appreciate some help in understanding how aptalca's conf works. Update: I think I got this working with LSIO's Nextcloud docker. The trick was to edit the default site-conf for the nextcloud docker. Look for the comment "# Path to the root of your installation." The next line will be root /config/www/nextcloud. Change that to root/config/www/ and restart the nextcloud docker. Now to get to your nextcloud instance you'll have add /nextcloud after the ip address:port you used to use. This is good because this is what makes it possible to make an nginx location such as /nextcould work. Now edit the default nginx site-conf for the letsencrypt docker to add a new location: location /nextcloud { proxy_pass https://192.168.x.xxx:xxxx/nextcloud; } Now to get to your nextcloud instance you can type domain.com/nextcloud. To get nextcloud to work through the proxy, I also found that I add these lines to nextcloud's config.php: 'trusted_proxies' => ['192.168.x.xxx'], 'overwritewebroot' => '/nextcloud', 'overwritehost' => 'domain.com', Hope this is useful for others.

@jtroberts, Your post helped me as well.

@chbmb Did you make any changes to nextcloud's config.php to make it work behind the letsencrypt reverse proxy?

@nojas, This page seems to have some relevant info: https://docs.nextcloud.com/server/9/admin_manual/configuration_server/reverse_proxy_configuration.html

@nojas, I think you need to enter the URL of the login screen

@noja, When you enter https://172.16.100.5:8443/cloud in a browser, do you get to the nextcloud login screen?