Recent Profile Visitors

I've found that when accessing Nextcloud via my iOS phone client externally that it takes approximately 30-60 seconds to "wake up" and connect with the server--until then it appears like a non-responsive hung app and clicking various areas of the Nextcloud iOS app do nothing. Internally it connects immediately via the app and website; externally it connects immediately via a browser--this change probably happened close to the 15.0 upgrade. Anyone seen this before and have any insights or places to start looking? Thanks!

kizer is spot on--the community here is incredible--I've had my butt saved by incredible members here. I've been using the same license (and same USB key now that I think about it hmmm) since buying a 1TB drive was considered HUGE and cost prohibitive. If you look at the cost of my license over the last decade plus, it's amounted to absolute peanuts.

EDIT: Sometimes typing something out can REALLY help. It occurred to me no more than 10 minutes after publishing this post that these lines jumped out at me:
#auth_basic "Restricted";
#auth_basic_user_file /config/nginx/.htpasswd;
I commented out those extra authentication steps and IT WORKS! I guess I was close and not as stupid as I thought--would love to hear best practices moving forward and if this approach in sites-conf/default is preferable to /proxy-conf/app.subdomain.conf and what the distinction is. Leaving this here in case it helps someone down the road.
I've been running letsencrypt perfectly with Nextcloud for years now thanks to this awesome community---I've recently decided to try more dockers than just Plex & Nextcloud (specifically Bitwarden but my questions are primarily around letsencrypt) and I'm trying to learn how to publish more than one docker. I've jumped back to square one and learning about the configs etc (from watching spaceinvader videos and reading articles at linuxserverio) and feel like I'm SUPER close but missing something subtle somewhere (or maybe just think I'm closer than I actually am).
I've got DNS working for a custom domain (was already working for nextcloud) for bitwarden, created the new docker network and moved the containers over to that network for communications (as I understand it is necessary) and then passing the bitwarden subdomain to letsencrypt successfully after working with the nginx/proxy-confs and creating a bitwarden.subdomain.conf file and then realizing there's default in nginx/site-confs that looks like the following and when I would hit bw.mydomain.com externally I'd land on the nextcloud landing page.
server {
listen 80;
listen 443 ssl;
root /config/www;
index index.html index.htm index.php;
server_name nextcloud.mydomain.com;
###SSL Certificates
ssl_certificate /config/keys/letsencrypt/fullchain.pem;
ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
###Diffieâ€“Hellman key exchange ###
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';
###Extra Settings###
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
### Add HTTP Strict Transport Security ###
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
add_header Front-End-Https on;
client_max_body_size 0;
location / {
proxy_pass https://172.23.1.31:444/;
}
}
So I tried several things from that point:
1) added a line to reference the proxy-confs (with the *.subdomain.conf file I created) with an include statement in the site-confs/default (which ended up in errors in letsencrypt log on startup).
2) ignored the proxy-confs all together and added the following to my sites-confs/default after the above code:
server {
listen 80;
listen 443 ssl;
server_name bw.mydomain.com;
include /config/nginx/ssl.conf;
client_max_body_size 0;
location / {
auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_Bitwarden Bitwarden;
proxy_pass http://172.23.1.31:8343;
}
}
I no longer land on the nextcloud landing page but get a generic prompt for a username and password for authentication and get no further (I can access the docker internally no problem). I've tweaked more than a few
I'm curious what best practice is? Is it to use the proxy-confs or to use site-confs to address the various services? In my research I've seen it done both ways...thanks in advance for any and all advice/help!

Actually windows gave me a permissions error and when I started poking around I realized I was under disk9/lost+found and not \\tower\lost+found. I'm assuming all I have to do is move the files from \\tower\lost+found to their respective \\tower\sharename and I'll be set no? Or is a more complex move needed? Usershare to usershare if I'm not mistaken...

And I suck...was trying to access via disk9 and NOT the users share lost+found. Buried under those original directories are my ACTUAL directories and files! Tried a couple and they seem to work perfectly. I think we're done here...time to check and move!

Ok I ran it and it completed....then had to stop the array and restart it. It allowed disk9 to be mounted and I can now see the disk share but nothing is there except "lost and found". Can't browse the share with windows but can under the gui. Tons of folders in there and files as well of the correctish sizes I presume. Assume I have to open them up to read them etc? They are named with simple numeric sequences--see attached picture.
Attached is the output of the --rebuild-tree.
rebuild-tree.txt

Evening update: came back home from the office and found the following in the summary of the log:
Then I unmounted the array, assigned the new disk9 and brought the array online and now I see the following: