jfoxwoosh

I think this is fair. I love UnRaid, and I want limetech to stay around. You buy a license to a version of the software and got to keep using it with no subscription fee. If you want newer version/feature, then you pay a bit extra for the upgrade. As long as this "extra" is not outrageously expensive.

Tried this on my system: Ryzen 5900x MSI B550 Motherboard RX 6800XT UnRaid 6.12.3 I followed the instructions posted here, and tried it on one of my existing Win11 VM, which ended it with Code43. I then tried creating a Win11 VM from scratch, and it caused my host to reboot during the VM OS installation. After some more tries, it always end up causing the host to reboot. To avoid host reboot during Win11 VM creation, I had to disable ReBAR in bios.

Thank you for the insight. Does the messages in the log indicate any error? Or it is safe to ignore?

I have noticed my dashboard log size reporting to be 8% used. From my past experience, I have never seen this go over 2%, so I checked the files size by "du -sh /var/log/*" and found out the stdout.log is 9MB and have been slowly growing to near 9.5MB in the span of 2 hr. A quick look into the content of this log, I found it is the same messages repeating over and over again by the seconds. My array is currently spinned down and there is no file activities going on. 85803 [2023-07-26T09:56:35.934] [6943] [DEBUG] [app] Array was updated, publishing event 85804 [2023-07-26T09:56:40.934] [6943] [DEBUG] [emhttp] Loading state file for disks 85805 [2023-07-26T09:56:50.936] [6943] [DEBUG] [emhttp] Loading state file for disks 85806 [2023-07-26T09:56:50.940] [6943] [DEBUG] [emhttp] Loading state file for shares 85807 [2023-07-26T09:56:55.940] [6943] [DEBUG] [app] Array was updated, publishing event 85808 [2023-07-26T09:57:00.935] [6943] [DEBUG] [emhttp] Loading state file for shares 85809 [2023-07-26T09:57:00.938] [6943] [DEBUG] [emhttp] Loading state file for disks 85810 [2023-07-26T09:57:05.941] [6943] [DEBUG] [app] Array was updated, publishing event 85811 [2023-07-26T09:57:10.936] [6943] [DEBUG] [emhttp] Loading state file for disks 85812 [2023-07-26T09:57:20.938] [6943] [DEBUG] [emhttp] Loading state file for disks 85813 [2023-07-26T09:57:30.937] [6943] [DEBUG] [emhttp] Loading state file for disks 85814 [2023-07-26T09:57:30.941] [6943] [DEBUG] [emhttp] Loading state file for shares 85815 [2023-07-26T09:57:35.941] [6943] [DEBUG] [app] Array was updated, publishing event 85816 [2023-07-26T09:57:39.961] [6943] [DEBUG] [graphql] upc connected 85817 [2023-07-26T09:57:40.025] [6943] [DEBUG] [graphql] Subscribing to servers 85818 [2023-07-26T09:57:40.050] [6943] [DEBUG] [graphql] Subscribing to vars 85819 [2023-07-26T09:57:40.051] [6943] [DEBUG] [graphql] Subscribing to owner 85820 [2023-07-26T09:57:40.052] [6943] [DEBUG] [graphql] Subscribing to config 85821 [2023-07-26T09:57:40.053] [6943] [DEBUG] [graphql] Subscribing to registration 85822 [2023-07-26T09:57:40.939] [6943] [DEBUG] [emhttp] Loading state file for disks 85823 [2023-07-26T09:57:40.943] [6943] [DEBUG] [emhttp] Loading state file for shares 85824 [2023-07-26T09:57:43.418] [6943] [DEBUG] [graphql] upc disconnected. 85825 [2023-07-26T09:57:43.765] [6943] [DEBUG] [graphql] upc connected 85826 [2023-07-26T09:57:43.809] [6943] [DEBUG] [graphql] Subscribing to servers 85827 [2023-07-26T09:57:43.873] [6943] [DEBUG] [graphql] Subscribing to vars 85828 [2023-07-26T09:57:43.874] [6943] [DEBUG] [graphql] Subscribing to owner 85829 [2023-07-26T09:57:43.874] [6943] [DEBUG] [graphql] Subscribing to config 85830 [2023-07-26T09:57:43.875] [6943] [DEBUG] [graphql] Subscribing to registration 85831 [2023-07-26T09:57:50.939] [6943] [DEBUG] [emhttp] Loading state file for disks 85832 [2023-07-26T09:57:50.942] [6943] [DEBUG] [emhttp] Loading state file for shares 85833 [2023-07-26T09:57:55.942] [6943] [DEBUG] [app] Array was updated, publishing event 85834 [2023-07-26T09:58:00.939] [6943] [DEBUG] [emhttp] Loading state file for shares 85835 [2023-07-26T09:58:00.942] [6943] [DEBUG] [emhttp] Loading state file for disks 85836 [2023-07-26T09:58:05.944] [6943] [DEBUG] [app] Array was updated, publishing event 85837 [2023-07-26T09:58:10.940] [6943] [DEBUG] [emhttp] Loading state file for disks 85838 [2023-07-26T09:58:20.940] [6943] [DEBUG] [emhttp] Loading state file for shares 85839 [2023-07-26T09:58:20.944] [6943] [DEBUG] [emhttp] Loading state file for disks 85840 [2023-07-26T09:58:25.946] [6943] [DEBUG] [app] Array was updated, publishing event 85841 [2023-07-26T09:58:30.941] [6943] [DEBUG] [emhttp] Loading state file for disks

Don't really understand all these personally, so I just did some trials and errors. I found out it is when "add_header X-Frame-Options "SAMEORIGIN" always" is enabled in ssl.conf that will break the integration between nextcloud and onlyoffice. Upon further reading, this seems to be the expected behavior. https://forum.onlyoffice.com/t/error-message-when-opening-creating-a-document-from-update/4392/12 For anyone using swag and its template for nextcloud reverse proxy, comment out "proxy_hide_header X-Frame-Options" in the template so to pass nextcloud's security test as suggested in nextcloud's github issue #8550. Don't enable it within ssl.conf which will add this header to any proxy conf that calls for this file. # Hide proxy response headers from Nextcloud that conflict with ssl.conf # Uncomment the Optional additional headers in SWAG's ssl.conf to pass Nextcloud's security scan proxy_hide_header Referrer-Policy; proxy_hide_header X-Content-Type-Options; #proxy_hide_header X-Frame-Options; proxy_hide_header X-XSS-Protection;

@bigbangus I can see documentserver's welcome page from its subdomain url. Here is the update. If I revert the ssl.conf to swag's initial template state, then my onlyoffice works again. However, the only changes I made are in accordance to swag nextcloud's proxy template so to pass the nextcloud's security check (e.g. enabling add_header X-Frame-Options..., etc.). How do you deal with this?

@bigbangus I checked my reverse proxy conf file and noticed the default from swag's documentserver proxy conf template uses http/Port80 instead of https/Port443. I changed it to https and 443 just like yours and clear the cache of my browser. After restarting swag, I can access documentserver from my public domain url just fine. However, I am still suffering the same issue. No idea what is going on. For now I have setup up Collabora. Will revisit this if there is new update to either documentserver or the onlyoffice nextcloud plug in.

Well, I am late to the party. Not sure why I didn't experience this problem when the server was on 6.11.x, and the crashes only started after update to 6.12.x. My binhex-qbittorrentvpn container was running on latest tag and updated whenever there was a new one released. My host (6.12.2) GUI became unresponsive but all my docker services (except binhex-qbittorrentvpn) and VM were still functioning normal. After SSH in and kill the qbittorrent container process, the host GUI became available again. There were some error events logged in the syslog. Jul 9 01:58:04 Gandor kernel: CPU: 1 PID: 10534 Comm: qbittorrent-nox Tainted: P O 6.1.36-Unraid #1 Jul 9 01:58:04 Gandor kernel: Call Trace: I tried switching over to hotio's qbittorrent-vpn docker, but I also saw related error to "qbittorrent-nox segfault" when stop/restart the container. I then switched over to hotio's qbittorrent-vpn "legacy" version, which uses libtorrent 1.2.x. I has not seen the segfault error message yet. I will keep this setup for the next month or so and report back any error if there is any.

I encounter an issue similar to the post. The host (6.12.2) GUI became unresponsive but all my docker services (except binhex-qbittorrentvpn) and VM were still functioning normal. After SSH in and kill the qbittorrent container process, the host GUI became available again. There are some error events logged in the syslog. Jul 9 01:58:04 Gandor kernel: CPU: 1 PID: 10534 Comm: qbittorrent-nox Tainted: P O 6.1.36-Unraid #1 Jul 9 01:58:04 Gandor kernel: Call Trace: I tried switching over to hotio's qbittorrent-vpn docker, but I also saw related error to "qbittorrent-nox segfault" when stop/restart the container. I am not sure if these are related or not. Update: I switched over to hotio's qbittorrent-vpn "legacy" version, which uses libtorrent 1.2.x. So far has not see the segfault error message. I will keep this setup for the next 2 weeks or so and report back any findings. I think my issue is related to this. gandor-diagnostics-20230709-1925.zip

+1, I am having this problem as well. As far as I can tell, documentserver is working correctly. I can access through reverse proxy, and the example editor test works just fine. The nextcloud's onlyoffice plugin can connect to the document server. However, nextcloud can no longer open any of the office files within the browser. Using Edge/Chrome will result in the same error message "refused to connect." Using firefox will either show a blank page, or a warning message saying it cannot open an already embedded page within the tab.

Hi. Where can I find the updater.phar in this container? It is not in the usual /var/www/nextcloud directory.

Can you post screen captures of your unraid's "Networking Setting" page? Also, did you try traceroute from your server to devices on private vlan? You want to compare the path taken by: 1. device_on_private to server_on_core 2. server_on_core to device_on_private

Run your unraid in safe mode (this disables docker/plugin/VM) and without any external USB device connected. See if lockup happens again. If not, then you can start turning on additional services one by one.

If you can use domain name to access your services from within your home, I think you already have something like NAT reflection enabled (or perhaps split DNS)? However, since you said you can still get access as long as you are on the core vlan through domain name, I am guessing you might have asymmetric routing happening. You might want to start using tracert (on windows) and traceroute (Linux) from your each vlan to check the routing path from your server to device and vice-versa. If they take different path, then your firewall will most likely block the tcp connection from establishing.

Wow. Your problem sounded exactly like mine. I had this as well, and only until last Dec, i got everything sorted. When you say you cannot access nextcloud from private vlan, are you trying to access it through your subdomain.domain.com or by IPaddress:Port?