TBoneStaek

Okay, I've searched this problem for hours and found minimal clues as to what I'm doing differently that would cause this. I setup 3 ZFS Cache Pools: 1 for Appdata & System; 1 for downloads (no critical and not even SSDs; and 1 for Domain for my VMs. I pretty much have been only doing snapshots on the Appdata/System and the Domain/VM drives. I setup datasets for each docker appdata folder to be able to rollback an individual docker folder if needed. Love the idea of not having to shutdown (especially for Plex). I'm pretty much only taking 1 snapshot right before I update a docker container which is about 1x/week (mimicking what I used to do with the appdata backup plugin). So after about 2 months, my cache drives are filling up. Should I be deleting these snapshots? It seems like some people run snapshots every hour or every day. I can't imagine if my drives are filling up just with snapshots 1x/week. Looking for guidance to make the proper adjustments for my use-case. I would like to replace what appdata backup did without having to shut down containers and VMs; ideally would back the snapshots up to the array (which I know SIO has a video on).

I just nuked it and restored from appdata backup. Not too awful of a loss. 3 days...

I had some cache pool upgrade issues and now am receiving this error in Nextcloud "MySQL server has gone away in /config/www/nextcloud/lib/private/DB/Connection.php:87" I tried poking around MariaDB's appdata to find an error log but was unsuccessful. I know nothing about MariaDB except follow SIO's videos. Any ELI5 help is appreciated. I do have an appdata backup if it comes to that but figured there may be a more appropriate and better way to fix the issue. TIA!

That’s what I suspected unfortunately. Thanks!

I'll spare the details but essentially I as trying to resolve the cache writing issues to my new cache pools and must have messed something up during mover to my array or back from my array. Now nextcloud's php error log gives me this: 2021/11/21 06:12:48 [error] 1794#1794: *63211 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2006] MySQL server has gone away in /config/www/nextcloud/lib/private/DB/Connection.php:87 Stack trace: #0 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1486): OC\DB\Connection->connect() #1 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1014): Doctrine\DBAL\Connection->getWrappedConnection() #2 /config/www/nextcloud/lib/private/DB/Connection.php(231): Doctrine\DBAL\Connection->executeQuery() #3 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Query/QueryBuilder.php(210): OC\DB\Connection->executeQuery() #4 /config/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(287): Doctrine\DBAL\Query\QueryBuilder->execute() #5 /config/www/nextcloud/lib/private/AppConfig.php(344): OC\DB\QueryBuilder\QueryBuilder->execute() #6 /config/www/nextcloud/lib/private/AppConfig.php(109): OC\AppConfig->loadConfigValues() #7" while reading response header from upstream, client: 154.3.44.228, server: _, request: "PROPFIND /remote.php/dav/files/TBoneStaek/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "nextcloud.[mydomain].com" 2021/11/21 06:12:48 [error] 1794#1794: *63213 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [2006] MySQL server has gone away in /config/www/nextcloud/lib/private/DB/Connection.php:87 Stack trace: #0 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1486): OC\DB\Connection->connect() #1 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Connection.php(1014): Doctrine\DBAL\Connection->getWrappedConnection() #2 /config/www/nextcloud/lib/private/DB/Connection.php(231): Doctrine\DBAL\Connection->executeQuery() #3 /config/www/nextcloud/3rdparty/doctrine/dbal/src/Query/QueryBuilder.php(210): OC\DB\Connection->executeQuery() #4 /config/www/nextcloud/lib/private/DB/QueryBuilder/QueryBuilder.php(287): Doctrine\DBAL\Query\QueryBuilder->execute() #5 /config/www/nextcloud/lib/private/AppConfig.php(344): OC\DB\QueryBuilder\QueryBuilder->execute() #6 /config/www/nextcloud/lib/private/AppConfig.php(109): OC\AppConfig->loadConfigValues() #7" while reading response header from upstream, client: 154.3.44.228, server: _, request: "PROPFIND /remote.php/dav/files/Coaldez341/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "nextcloud.[mydomain].com" Please ELI5 as I have very very little CLI knowledge (though Nextcloud so far has been changing this...) I can't access the web gui locally or through reverse proxy.

I just had this problem myself. I usually keep Dashboard open in Firefox on my home PC always and when I'm away I also have it open while using my laptop. I'm running 6.9.2 and this is the first time I've run unto this issue. I rebooted my server before finding this temporary fix listed above. I know the webgui becomes unresponsive once the log fills up and I didn't want to chance it. The other thing I've been doing different is tinkering with VMs and I had left one on for a few hours but that shouldn't have caused it. Just throwing in my info in case it helps lead to a solution. I couldn't grab any logs, they were taking too long to compile. Just snagged a screenshot of the syslog so I could "google" it which led me here.

Getting these errors. Any assistance appreciated! error unknown xrdp_sec_process_mcs_data tag 0xc006 size 8 error unknown xrdp_sec_process_mcs_data tag 0xc00a size 8 [2021-05-06 01:41:49] [Connection 1] Closing connection with error: Error: WS was inactive for too long at ClientConnection.checkActivity (/gclient/node_modules/guacamole-lite/lib/ClientConnection.js:154:24) at listOnTimeout (internal/timers.js:554:17) at processTimers (internal/timers.js:497:7) [2021-05-06 01:41:49] [Connection 1] Closing guacd connection [2021-05-06 01:41:49] [Connection 1] Client connection closed guacd[471]: ERROR: User is not responding. guacd[471]: INFO: User "@67cad8ea-6fbe-4a86-8f46-76cb382ba7f2" disconnected (0 users remain) guacd[471]: INFO: Last user of connection "$a113b59b-38e5-4d9b-9c3f-c9452019642f" disconnected guacd[471]: INFO: Internal RDP client disconnected guacd[384]: INFO: Connection "$a113b59b-38e5-4d9b-9c3f-c9452019642f" removed. rdpClientConRecv: g_sck_recv failed(returned 0) rdpClientConDisconnect: rdpClientConDisconnect: clientCon removed from dev list rdpClientConRecvMsg: error rdpClientConCheck: rdpClientConGotData failed

Ah, you pointed me in the right direction with some digging. I wasn't getting "errors" but I see what was needed. Thanks!

The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy. If not, this is a security issue and can allow an attacker to spoof their IP address as visible to the Nextcloud. Further information can be found in the documentation. The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly. Here's my nextcloud.subdomain.conf # make sure that your dns has a cname set for nextcloud # assuming this container is called "letsencrypt", edit your nextcloud container's config # located at /config/www/nextcloud/config/config.php and add the following lines before the ");": # 'trusted_proxies' => ['letsencrypt'], # 'overwrite.cli.url' => 'https://nextcloud.your-domain.com/', # 'overwritehost' => 'nextcloud.your-domain.com', # 'overwriteprotocol' => 'https', # # Also don't forget to add your domain name to the trusted domains array. It should look somewhat like this: # array ( # 0 => '192.168.0.1:444', # This line may look different on your setup, don't modify it. # 1 => 'nextcloud.your-domain.com', # ), server { listen 443 ssl; listen [::]:443 ssl; server_name nextcloud.*; include /config/nginx/ssl.conf; add_header X-Frame-Options "SAMEORIGIN" always; add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;"; client_max_body_size 0; location / { include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; set $upstream_nextcloud nextcloud; proxy_max_temp_file_size 2048m; proxy_pass https://$upstream_nextcloud:443; } } I've also tried uncommenting out the X-Frames-Options issue in the ssl.conf to no avail. I just don't see what I'm missing.

I'm having the same issue after pulling the latest image. It's like it "forgot" where my library is and every time I repoint to it and restart the docker it "forgets" again. I'm getting errors in my logs as well. https://privatebin.net/?6cb378d34ade868b#Euikg6Kvz2K4XK1xJq7V1U6a7Mz65Vz47f9wdraoAPUV

@luizmont Yeah, I'm talking about the config.php. I hadn't properly set mine up after deleting the appdata before my NC 20 to NC 21 upgrade (which got stuck a bunch of times). If you haven't, make sure your default.conf actually updated by comparing the above. Perhaps you still have the old lines in there and it didn't update? That's the only other thought I have towards your issue.

I. AM. AN. IDIOT. @luizmont is this your issue also? When I upgraded from NC 20 to NC 21 I had to nuke my appdata to get the update going. I failed to reconfig my reverse proxy. I've done that and now most errors have gone away. I now have two errors that I'm sure are related to failing to reconfig everything correctly: The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy. If not, this is a security issue and can allow an attacker to spoof their IP address as visible to the Nextcloud. Further information can be found in the documentation. The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly. I have the correct edit in the nextcloud.subdomain.conf so I'm not sure why I'm still getting the X-Frames error. As for the first error, not sure about that one either but I haven't had time to investigate. If someone can point me in the right direction, awesome, but if not, I'll start searching for answers to those issues tonight. Just glad to have NC functioning.

Not using cloudflare and also using Swag as well. @skois Thank you for always helping out!

I’m having the exact same issue and was about to get on here to ask. I’ve deleted the default.conf and restarted the container many times. I’ve cleared browser cache, opened new private browsers. In viewing the new default.conf, all the new lines appear to be correct as per a comparison posted above of the old and new lines in the conf. Also running 21.0.1 Waiting with bated breath for the LXC gods to share their awesome wisdom and expertise!

Dear TBoneStaek, This is the way. If you run into the same problem again 45 days later, this is the way. Signed, smarter-than-March, April TBoneStaek.

I switched to Toronto just fine but was originally using Montreal. Anybody using PIA wireguard Montreal successfully now?

Nope, not 6.9.2. I contemplated doing that today to see if that fixed it but... I imagine not. Must have been a coincidence though, again, I have Toronto working for me. Very strange.

I just upgraded to 6.9.1 from 6.8.3 a few days ago. And yes, wireguard.

I've been okay with Toronto. Strange...

I just upgraded Unraid from 6.8.3 to 6.9.1. That's the only change I've made and now delugevpn gui won't load and the log is showing a few errors which I've searched through here but can't seem to find a solution that applies to me. 2021-04-11 11:15:37,734 DEBG 'start-script' stderr output: parse error: Invalid numeric literal at line 4, column 0 2021-04-11 11:15:37,931 DEBG 'start-script' stderr output: parse error: Invalid numeric literal at line 1, column 7 2021-04-11 11:15:37,932 DEBG 'start-script' stdout output: [warn] Unable to successfully download PIA json to generate token from URL 'https://199.36.223.130/authv3/generateToken' [info] Retrying in 10 secs... attached is my salted debug log supervisord (salted).txt

Yup, so after some more scouring I found a solution that worked for me; change the config file path from app/config/config.ini to app/config/ That did it for me.

Did you ever find a solution to this? I'm getting the same error.

Getting errors when trying to snatch shows. Can't remember if I just updated this docker or not honestly. It was working fine two days ago but I am unable to snatch any show. Throws errors like this: https://ybin.me/p/726aa13478d0120b#Q6uOQrKSLmBiMgYi0Ir3XTGdlLXA9cGZ6MUUdyeWhsw=

But doing appdata cleanup, you have to re-link the database correct? You didn't restore any of your appdata from a backup right? What about Users and Settings and such?

Get anywhere with this? I'm having the same issue.