TBoneStaek

Members
  • Posts

    65
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

TBoneStaek's Achievements

Rookie

Rookie (2/14)

4

Reputation

  1. 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.
  2. 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
  3. Ah, you pointed me in the right direction with some digging. I wasn't getting "errors" but I see what was needed. Thanks!
  4. 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.
  5. 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
  6. @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.
  7. 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.
  8. Not using cloudflare and also using Swag as well. @skois Thank you for always helping out!
  9. 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!
  10. 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.
  11. I switched to Toronto just fine but was originally using Montreal. Anybody using PIA wireguard Montreal successfully now?
  12. 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.
  13. I just upgraded to 6.9.1 from 6.8.3 a few days ago. And yes, wireguard.
  14. I've been okay with Toronto. Strange...
  15. 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