noja

You know, I had a hell of a time trying to make it work myself at first. Eventually I decided give it a whirl using a subdomain (ie nextcloud.domain.com as opposed to domain.com/nextcloud). Turns out the subdomain was easier to implement and for me - easier to remember my url address. As an added benefit, its apparently also more secure! So, just to make it better for yourself, its worth it to review your installation from the ground up. Just go back one more time and follow Linuxserver's excellent step-by-step process on this very topic: https://blog.linuxserver.io/2017/05/10/installing-nextcloud-on-unraid-with-letsencrypt-reverse-proxy/ As I don't use DuckDNS I had to make sure that subdomains were possible, and apparently they are! So try this for your subdomain setup: Good luck!

Well, I hope those with more knowledge chime in for you, but the last couple times I had that exact same issue, it was because I had inadvertently allowed a file to be created where NC didn't like it. So, what worked for me was to backup your NC appdata folder, then find that offending file and delete it. It should allow the upgrade to proceed.

I'm going to sign on for this feature request as well! I saw someone else commenting about extracting individual app from the tar, but people (mostly me, myself, and I) are much more likely to fail during a non gui procedure. Part of the reason for the request is that I know exactly how well the plugin works. I managed (unsurprisingly) to pooch my Nextcloud container during the last update, and the restore option on the plugin fixed literally every issue I had. If I could have only restored the Nextcloud and associated DB containers, life would have been that much more perfect. Thanks again @Squid!

@joshz thanks for your updates! I was stuck exactly the same way you were and that fixed it for me.

FOUND MY FIX! It was issue of not knowing NGINX very well and I've learned a lot more. The correct usage should be: server { listen 443 ssl; server_name shaarli.domain.com; ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers xxxxxxxxxxxxxx; ssl_prefer_server_ciphers on; client_max_body_size 0; location / { proxy_pass http://192.168.1.1:8383; add_header X-Frame-Options "ALLOW-FROM https://domain.com/"; } } -----------------------------------------------(Original Post)----------------------------- OK - so I'm not sure if I have a letsencrypt issue or if I'm just unsure of how to make nginx work. I've been working with a new docker called Shaarli, which is interesting, but Shaarli's chrome extension keeps getting blocked due to x-frame headers being denied. One of the comments on the Shaarli Chrome plugin noted: So I ran through what I could on Google and generally failed. Currently, I've added: server { listen 443 ssl; server_name shaarli.domain.com; ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'xxxxxxxxxxxxxxxxxx'; ssl_prefer_server_ciphers on; add_header X-Frame-Options SAMEORIGIN; client_max_body_size 0; location / { proxy_pass http://192.168.1.1:8383; } } However, I've also tried changing that X-Frame-Options to ALLOW-FROM https://domain.com/ and ALLOW-FROM https://shaarli.domain.com/ Both of those options keep generating an error in the docker and don't allow access to the webpage. First, is my issue with the docker since it won't start with that "ALLOW-FROM" option? Or do I need to keep learning nginx? Second, anyone have a good idea? Thank you!

Hey Kru-x, Surprisingly, I don't have any issues at all. I installed the mongo-db and Wekan and they are both just working. Which means, THANK YOU! I do have a question though, is the mongo db usable for any other dockers or is it somehow locked in for just your wekan repo? Again, thanks a million

Do you know if the android app detects the installation if you use a "normal" address, like mydomain.net instead of a dyndns address? I use my bought domain name. It like mydomain.de. When I use the the normal Nextcloud container on the 443 Port, the Adress works correctly. So it is not that fault i guess.. Or do think it is? Then I don't think the dynsdns domain is the problem, I thought you had something like "xxx.dyndns.org". I am having some troubles with reverse proxy on the android app too, without reverse proxy it works perfectly fine. I have posted in the nextcloud forum, hope someone could help me there. https://help.nextcloud.com/t/reverse-proxy-with-android-client-does-not-work/3346 If someone is using nextcloud behind reverse proxy (prefer Nginx), does the android client work? If so, can you share your config? Well, I think you might see me up there in previous posts. I eventually did get this one to work with my nginx/letsencrypt reverse proxy as well. So its do-able. Apparently its good to note that Nextcloud recommends that you setup your domain to be "nextcloud.example.com" as opposed to "example.com/nextcloud" Once I found that out, I learned how to add a new server_name to nginx. So my nginx site-confs default file has this appended to the end: server { listen 443 ssl; server_name cloud.example.com; ssl_certificate /config/keys/fullchain.pem; ssl_certificate_key /config/keys/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'xxxxxxxxxxxxxxxxxxxxxxxx'; ssl_prefer_server_ciphers on; client_max_body_size 0; location / { proxy_pass https://192.168.1.5:8443; } } And the nextcloud config looks like: $CONFIG = array ( 'memcache.local' => '\\OC\\Memcache\\APCu', 'datadirectory' => '/data', 'instanceid' => 'ocbkgz4h8t5f', 'passwordsalt' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'secret' => 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'trusted_domains' => array ( 0 => '192.168.1.5:8443', 1 => 'example.com:8443', 2 => 'example.com:443', 3 => '192.168.1.5:443', ), 'trusted_proxies' => array ( 0 => '192.168.1.5', 1 => 'example.com', ), 'overwrite.cli.url' => 'https://example.com/nextcloud', 'dbtype' => 'mysql', 'version' => '9.0.53.0', 'dbname' => 'NextCloud', 'dbhost' => '1921.168.1.5:3306', 'dbtableprefix' => 'oc_', 'dbuser' => 'nextcloud', 'dbpassword' => 'xxxxxxxxxxxx', 'logtimezone' => 'UTC', 'installed' => true, 'maintenance' => false, 'appstore.experimental.enabled' => true, ); After all of this, I'm able to get access on the Nextcloud android app with my server set to "https://cloud.example.com"

Actually, it just takes me to a location within nextcloud - not the login screen at all @CHBMB - I remember I actually left the ssl off as I was thinking about not trying to overlay auth types - same reason i left it off on my library - already had authentication there.

Sorry! Attached location /cloud { proxy_pass http://172.16.100.5:8443/cloud; } } http should be https like the error says. Other than that I can't say anymore as I don't use nginx Yeah...no dice with that one. Funny though, I didn't have the s on it for my other locations, but still was presented with basic auth when connecting to them. I'll keep at it! Thank you

Sorry! Attached default.txt

Hi, I've got everything setup, but I'm trying to get the docker to play nice with my existing nginx/letsencrypt docker from aptalca. Are there changes I need to make to nextcloud's nginx to have it work? I'd really like to be able to access it via nextcloud.domain.com Even just implementing a proxypass in my existing setup returns "400 Bad Request - The plain HTTP request was sent to HTTPS port" I'm pretty new to reverse proxy world and I'm not sure where I'm going wrong.