Smooth Beaver

So you added this conf to the letsencrypt container?

It appears not all users are affected by this.. am I correct with that assumption?

Check up a few posts there was one made by @INTEL that may help with that.

In the Unraid GUi on the dockers tab open console by clicking the nextcloud icon and then clicking Console at the prompt type or copy and paste: nano /config/nginx/site-confs/default This is the file you must edit. You have to remove the request uri and add the other “try” line, here is my config: Remove: $request_uri add: try_files $fastcgi_script_name =404; Once those lines are edited exit nano with ctrl+x Go back to the unraid GUI docker tab click the nextcloud icon and click restart. While your at it go ahead and restart the letsencrypt container as well.

@saarg Do you know of anyone who has Nextcloud and ONLYOFFICE functioning together? I could really use some help here....

@almulder It would be very wise to hide/remove you password salt and secret before before posting it online.

I don't stop anything. I mount my appdata share via SMB, drill down into the Nextcloud file to find the config.php, open it with Atom (atom.io) edit the config.php save it, and then in the UnRAID GUI on the docker tab click the Nextcloud icon and select restart. Once that is done, just because I can, I restart the letsencrpt docker as well but I really don't think its needed.

I think you have the trusted proxies wrong, here is what mine looks like: Notice no brackets.... only 0 => 'letsencrypt', and notice the array 'trusted_proxies' => array ( 0 => 'letsencrypt', ),

Ummm I am going to venture out and say the data not on your PC is lost... sit tight if you can, someone else might be able to help you more than I can.... Will the sync app not connect either? I guess not it uses WebDAV which is probably though Nginx.... Have you tried copying the nextcloud app data folder over from the backup?

You can try mounting your flash drive via SMB and overwriting the "default" file that route. Nextcloud data will not be encrypted unless you specifically told it to in the settings of Nextcloud:

One way to do this would be to mount your Nextcloud share via SMB, once its mounted you should be able to see all of your data and copy what you need... When you reinstall Nextcloud I would highly recommend following @SpaceInvaderOne YouTube videos including the one on how to set it up using a reverse proxy using letsencrypt.

If that is the only thing different I think the issue is elsewhere the two lines that you added did two things; The STS line forces the browser to interact with the site via HTTPS. Where you using HTTPS or just HTTP?? If you where using HTTPS was your certificate valid or a self signed cert? And the X Frame option simply means a page can only be embedded in a frame on a page with the same origin as itself. So what are the errors you are getting again are they the same across browsers? I am still thinking this maybe the issue: How to Delete HSTS Settings in Chrome: Navigate to chrome://net-internals/#hsts This is Chrome’s UI for managing your browser’s local HSTS settings. First, to confirm the domain’s HSTS settings are recorded by Chrome, type the hostname into the Query Domain section at the bottom of the page. Click Query. If the Query box returns Found with settings information below, the domain’s HSTS settings are saved in your browser. Note that this is a very sensitive search. Only enter the hostname, such as www.example.com or example.com without a protocol or path. Type the same hostname into the Delete domain section and click Your browser will no longer force an HTTPS connection for that site! You can test if its working properly by refreshing or navigating to the page. Note that depending on the HSTS settings provided by the site, you may need to specify the proper subdomain. For example, the HSTS settings for staging.yoursite.com may be separate from yoursite.com so you may need to repeat the steps as appropriate. How to Delete HSTS Settings in Firefox: Close all open tabs in Firefox. Open the full History window with the keyboard shortcut Ctrl + Shift + H (Cmd + Shift + H on Mac). You must use this window or the sidebar for the below options to be available. Find the site you want to delete the HSTS settings for – you can search for the site at the upper right if needed. Right-click the site from the list of items and click Forget About This Site.This should clear the HSTS settings (and other cache data) for that domain. Restart Firefox and visit the site. You should now be able to visit the site over HTTP/broken HTTPS. Read more at: https://www.thesslstore.com/blog/clear-hsts-settings-chrome-firefox/

Here is my full config: upstream php-handler { server 127.0.0.1:9000; } server { listen 80; listen [::]:80; server_name _; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name _; ssl_certificate /config/keys/cert.crt; ssl_certificate_key /config/keys/cert.key; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; add_header Referrer-Policy no-referrer; add_header X-Frame-Options "SAMEORIGIN"; fastcgi_hide_header X-Powered-By; root /config/www/nextcloud/; location = /robots.txt { allow all; log_not_found off; access_log off; } location = /.well-known/carddav { return 301 $scheme://$host/remote.php/dav; } location = /.well-known/caldav { return 301 $scheme://$host/remote.php/dav; } client_max_body_size 10G; fastcgi_buffers 64 4K; gzip on; gzip_vary on; gzip_comp_level 4; gzip_min_length 256; gzip_proxied expired no-cache no-store private no_last_modified no_etag auth; gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf> location / { rewrite ^ /index.php$request_uri; } location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ { deny all; } location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) { deny all; } location ~ ^\/(?:index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|ocm-provider\/.+)\.php(?:$|\/) { fastcgi_split_path_info ^(.+?\.php)(\/.*|)$; include /etc/nginx/fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param HTTPS on; fastcgi_param modHeadersAvailable true; fastcgi_param front_controller_active true; fastcgi_pass php-handler; fastcgi_intercept_errors on; fastcgi_request_buffering off; } location ~ ^\/(?:updater|ocs-provider|ocm-provider)(?:$|\/) { try_files $uri/ =404; index index.php; } location ~ \.(?:css|js|woff2?|svg|gif)$ { try_files $uri /index.php$request_uri; add_header Cache-Control "public, max-age=15778463"; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header Referrer-Policy no-referrer; access_log off; } location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ { try_files $uri /index.php$request_uri; access_log off; } }

I would say it should be in there, I would definitely grab it and compare.... I don't think there is any harm top posting the the whole thing, I don't think secret keys or other info like that is in it.. have a look first to make sure.

Here is mine for you to compare: I am not sure it will be the same as I am running letsencrypt as a reverse proxy server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name _; ssl_certificate /config/keys/cert.crt; ssl_certificate_key /config/keys/cert.key; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; add_header Referrer-Policy no-referrer; add_header X-Frame-Options "SAMEORIGIN"; fastcgi_hide_header X-Powered-By; root /config/www/nextcloud/; location = /robots.txt { allow all; log_not_found off; access_log off; }

Clear your browsers cache or use a different browser...

Also if you remove the HSTS line make sure you completely clear your browsers cache. close it and then try to navigate to the login again.

Are you running this on a subdomain? or a subfolder or neither? Change that line to this: add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload";

When I restart my Nextcloud docker even though it says its started it takes a little while after for it to actually fully load and I am able to login. I guess maybe 15-20 seconds of so after the GUI shows it started... are your dockers set to autostart?

What errors are you seeing? Are you seeing the login page but simply cannot login or are you getting the Nginx bad gateway page.... I first did this on my test server and it worked fine, so I then proceeded to do it to my production server with favorable results....

Look up about 3 posts I am working on the same issue....

To sum up the last few posts from @bastl and a few others.. If you used the directions from @SpaceInvaderOne on how to setup Nextcloud using letsencrypt reverse proxy and get these issues: Go to the Dockers tab click the Nextcloud docker icon then click >_ Console, You are NOT editing the letsencrypt docker. Now type or copy & paste: nano /config/nginx/site-confs/default You will need to enter two lines to solve those issues. Note: for some installs these lines may already be in place but are commented out by using the # simply remove the # in front of those lines, there is no need to add them again, and close nano saving the file. add_header X-Frame-Options "SAMEORIGIN"; add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; When you are done it will look like this: Note: The order does not matter. Once those lines are added close nano using ctrl + x. You can now also close the console window. Now click the Nextcloud docker icon, and click restart. You can now login to Nextcloud and should find everything is now checking out...

Has anyone gotten Nextcloud and ONLYOFFICE to work on UnRaid? If so how did you do it? Nextcloud using lets encrypt reverse proxy works great. ONLYOFFICE Docserver serves up welcome page... Linking Nextcloud to ONLYOFFFICE seems to be about as easy as finding a unicorn.... @SpaceInvaderOne any input on this? Have you ventured into this territory or know of anyone who has who may help shine some light on this?

Does this also pertain if you are using Let’s Encrypt proxy?

Did you ever get this fixed, I have the same issue...