barrysagittarius

I probably worded it poorly but I assume it's restarting after a crash. How would I know the difference? I'm not seeing any errors before it does an unclean restart. If it is hardware is there anything in the diagnostics I can look at to determine? I see nothing in the syslog.

Problem: No problems with Unraid or hardware for several years. Server was turned off around July, then turned back on in September. Server began to randomly restart resulting in needing to run a parity check all the time. Eventually began to pinpoint it to using Jellyfin and server crashing while watching higher quality files that might have been more intensive for transcoding. Turned off transcoding and it felt like the crashes stopped. Starting a few weeks ago the server would restart in the middle of the night or randomly in the day when not using Jellyfin. So while it definitely crashed while using Jellyfin, that's either not the main cause, or there's now additional causes. Things I've tried changing transcoding settings. Updating Unraid/hoping an update might fix the problem if software Changing macvlan to ipvlan Syslog to server. I don't see anything showing an error before it restarts. For example (see below), It looks like it updated plugins at midnight. A little later drives spun down, a trim process happened an hour or two later, things spun down again, and then around 6:00 the server restarted (I'm assuming that's what this indicates) Jan 5 20:17:39 Tower monitor: Stop running nchan processes Jan 5 22:00:07 Tower emhttpd: read SMART /dev/sdh Jan 6 00:00:01 Tower Plugin Auto Update: Checking for available plugin updates Jan 6 00:00:09 Tower Plugin Auto Update: NerdTools.plg version 2024.01.06 does not meet age requirements to update - 0 days old Jan 6 00:00:09 Tower Plugin Auto Update: Checking for language updates Jan 6 00:00:09 Tower Plugin Auto Update: Community Applications Plugin Auto Update finished Jan 6 00:05:41 Tower emhttpd: spinning down /dev/sdc Jan 6 00:16:01 Tower emhttpd: spinning down /dev/sde Jan 6 00:17:00 Tower emhttpd: spinning down /dev/sdd Jan 6 00:17:02 Tower emhttpd: spinning down /dev/sdg Jan 6 01:02:28 Tower root: /var/lib/docker: 11.3 GiB (12100575232 bytes) trimmed on /dev/loop2 Jan 6 01:02:28 Tower root: /mnt/cache: 38 GiB (40803491840 bytes) trimmed on /dev/sdf1 Jan 6 02:02:22 Tower emhttpd: spinning down /dev/sdh Jan 6 06:03:32 Tower file.activity: Starting File Activity Jan 6 06:03:32 Tower emhttpd: Starting File Activity... Jan 6 06:03:32 Tower file.activity: File Activity inotify starting Jan 6 06:03:32 Tower inotifywait[14355]: Setting up watches. Beware: since -r was given, this may take a while! I'm currently not sure if this is a software problem (it seemed like there were problems with Unraid OS update over the summer/fall for some people) or a hardware problem (I've run a ram test. not sure why there's not an error before shutdown). No idea what else to try or how why I'm not finding errors, but I don't know how to read the diagnostic logs to understand this further. Any help would be greatly appreciated! tower-diagnostics-20240106-0643.zip

@purplewalrus I solved my problem, which I think was the same as your problem. When installing the docker, I set Network Type: Bridge Then I added the following by Path/Port/Variable Port -Config Type: Port -Name: WebUI -Container Port: 8080 -Default Value: 8080 -Connection Type: TCP Variable -Config Type: Variable -Name: OPENPROJECT_HTTPS -Key: OPENPROJECT_HTTPS -Value: False -Default: False I think the key for not getting the SSL error was the OPENPROJECT_HTTPS variable. To get it to work otherwise, with https, I think requires setting up Swag/nginx which I was able to do for Nextcloud but is beyond my paygrade for this (didn't have time to figure out). More info is here https://www.openproject.org/docs/installation-and-operations/installation/docker/ Hope that solves your problem.

I'm unable to troubleshoot what is causing slow transfer speeds to my server. Previously I was able to transfer from my computer to server at more than 100mbps. Now it's around 10. The only changes I made were installing an LSI 9207-8i SAS card, Switching a new hard drive in for parity, and using the old parity drive as a new drive in the array (this is all functioning fine). I've checked the following: 1) When copying to the server, the Cache drive is being used, and is an ssd card (which was previously the case) 2) Using both open speed test, and speed test dockers, the DL network speed for the server is ~100mbps. Using ethtool eth0 I get "Speed: 1000Mb/s" 3) Using Diskspeed Docker, all HDs, including SSD are operating as expected, and one isn't a bottleneck. Am I missing something? It seems like even with installing the SAS and new HDs, with nothing changing to the SSD Cache (it's not connecting through the SAS card) that transfer speed to the server shouldn't have changed.