EgyptianSnakeLegs

No problem, I can totally relate. I'm in grad school for mechanical and aerospace engineering right now. Thank you for the quick reply.

So I started typing up this long tutorial about the insanity it took to get PDF Exporting added to this docker container. But after 3.5 hours of work it *STILL* isn't working. XD Any chance you could officially add support for this to your docker?

Wow, thank you!

This looks awesome, thanks! How possible would it be to have this docker image include the CSV or Spectre transaction importer? It doesn't seem very useful until there's a way to get data into it that doesn't involve manual entry.

Hey all, My apologies if this has already been asked, but a search didn't return any results. I stupidly started a massive bulk book conversion job to make my library kindle friendly. However I didn't realize that Calibre was going to copy all of those files into the docker image to accomplish this. So now I'm sitting here with a full docker image and can't figure out how to clear whatever cache they're all sitting in. Is there a folder somewhere I should go in and delete? Any help is greatly appreciated, thank you! Edit: I cancelled the pending conversion jobs and increased my docker img size so I could restart the calibre docker and have some room to work. But the image usage is still very high. Definitely some temp data in there somewhere.

Hmm...I get the same error: 127.0.0.1 - 02/May/2020:18:15:01 +0000 "GET /index.php" 500 when I try to load the /install page. I must've messed up somewhere else in the install. Any advice?

I'm in a similar boat to Heciruam and have no idea what to do next to get LeanTime up and running. I went into my MariaDB docker, created a user "leantimeadmin" with a password. Granted the user ALL *.* Created the database "leantime" and then entered the appropriate data into the LeanTime docker settings. I no longer get the "Can't connect to database" error, but just a white page. The logs show the following: Creating configuration file! 2020-05-01 21:58:45,764 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message. 2020-05-01 21:58:45,767 INFO supervisord started with pid 17 2020-05-01 21:58:46,770 INFO spawned: 'httpd' with pid 19 2020-05-01 21:58:46,773 INFO spawned: 'php-fpm' with pid 20 [01-May-2020 21:58:46] NOTICE: fpm is running, pid 20 [01-May-2020 21:58:46] NOTICE: ready to handle connections 2020-05-01 21:58:47,850 INFO success: httpd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2020-05-01 21:58:47,850 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 127.0.0.1 - 01/May/2020:21:58:53 +0000 "GET /index.php" 500 127.0.0.1 - 01/May/2020:21:58:56 +0000 "GET /index.php" 500 Not sure what I'm missing, or why the error about root is there. Any help would be greatly appreciated. Cheers!

Awesome, thank you for updating. I just spent the last two-ish months troubleshooting all kinds of Ryzen problems and ended up removing all of my apps and the the docker image itself. Been adding things slowly and testing for stability as I go. So I'm hoping I won't have that issue again when I get my library set back up.

At the advice of another topic, I uninstalled all of my docker apps, deleted the docker image, deleted most of the corresponding appdata folders (except Plex), and then remade the docker image and reinstalled the apps. My primary issues seem to be gone. I'm still experiencing the mysterious crash after a parity check completes, but all other crashes appear to be gone, and system performance seems dramatically faster and more responsive. I'll update the original post to reflect this.

I remade my docker image last night, and also deleted many (most) of the corresponding app data folders. All except my Plex library config/metadata. It really seems to have solved 99% of my issues.

Wow, there are a bunch of us describing very similar problems lately. I wonder if it's all related to some bug in 6.7.x & 6.8.x? I thought mine was Ryzen related, and have been troubleshooting it for a couple months with no success. I just read another post where a guy had the same problem, but thinks he solved it by deleting and rebuilding his docker image. I think that's going to be my next attempt. I currently only have Plex and Tautulli running, but have installed and removed a bunch of different docker containers that I was experimenting with. Maybe one of them broke something. I'll let you know if I have any luck.

Well...I woke up to find the UnRAID login page still accessible, which is a first. But when I entered my credentials it took about 60-80 seconds to load the main page. I clicked over to the dashboard and it promptly crashed again. I also see that the Duplicati backup job I've been frantically trying to get completed so I have a solid backup, got hung up after only 10 GB of transfer after I went to bed last night. I saw another post by a person who deleted and remade their docker container image. I think I might try that next, before I spend 24 hours running a memtest. Any thoughts?

Let us know if that continues to be the solution. I'm still having stability issues with my system, and this is something I hadn't considered.

Thank you all for the responses! @RedReddington & @Hoopster I just rebooted and changed the idle current setting. With any luck that will be the final piece of the puzzle. It had been in "Auto" and many of my crashes seemed to happen at night, so that seems like a logical cause. @John_M Here is the diagnostics file, as requested. Thank you in advance for taking a look at it! I also have a diagnostics file and syslog from November 24th that is when this issue started getting especially frequent. I can post those as well, if you're at all interested in them. ratasum-diagnostics-20200124-1358.zip

=======================================<UPDATE: 30 Jun 2020>======================================= These issues started randomly cropping up again about a month after this final post. Their frequency seemed to be increasing as well. It really seemed like bad memory to me, but it was a brand new system and a 12-hour memtest showed no errors. I decided to let it go, just to see what happened. Shortly after the 24 hour mark memtest started finding errors. A few hours later and it had found thousands of errors. I ended up replacing the ram and everything has been smooth sailing ever since. I suspect that may have always been the underlying issue and the fixes below were just performance improvements that obscured the issue. So...check your RAM thoroughly, folks! =======================================</UPDATE: 30 Jun 2020>======================================= =======================================<SOLVED>======================================= I believe this issue is finally solved (for me)! The following is the combination of settings that ended up working: Disable C States in the BIOS. Add the disable C6 state command in the 'go' file. Add Flash -> Syslinux Config -> label unRAID OS (and GUI Mode) -> append 'rcu_nocbs=0-7' ... Upgrade to the most recent BIOS firmware. Uninstall all Apps, stop docker service, remove/delete docker image, delete the appdata for each previously installed app (except Plex), remake docker image, reinstall apps. So far everything seems to be working as expected. I'm still getting the mysterious crash after a parity check, but I believe that to be unrelated to this original post. =======================================</SOLVED>======================================= Hello all, After months of attempted troubleshooting and much struggle, I'm finally reaching out for help with my server. About a year ago, a very kind and generous friend gifted me a new barebones server to replace the laughable Intel NUC and pile of external USB drives that was serving as my Plex server. His super generous gift was the following: Mobo: MSI B450 Tomahawk CPU: Ryzen 5 2400G with Radeon RX Vega 11 Graphics RAM: G.Skill Flare X (for AMD) DDR4 2400 - 16 GB (2 x 8 GB) PSU: Seasonic Focus Plus 550 Gold (SSR-550FX) LSI: SAS9211-8I 8PORT Int 6GB Sata+sas Pcie 2.0 A solid start to an UnRAID server that I could fill with hard drives as my college student budget allowed. After a year of saving money, I finally had enough for an UnRAID license and 3x 10 TB hard drives. So I got the system setup, following all of the glorious wisdom of @SpaceInvader One, and began the arduous task of moving all of my content over to the new system, and then got Plex setup and running. The new system seemed amazing! HOWEVER, I almost immediately began to have stability issues. The system would just randomly "crash"/lockup. It would essentially just fall off of the network, and if I happened to be logged into the admin console from my laptop, the whole interface would just stop responding. To this day I have not had more than 20 hours uptime, and it's frequently more like 1-6 hours. Basically rendering a Plex server useless, much less all of the other functionality I'd like to use on it. I quickly realized that these were the common Ryzen stability issues that people were complaining about. So I went through all of the troubleshooting steps I could find online. So far I have taken the following steps: 'SVM Mode = Enabled' in the BIOS. (I know this is just for VMs, which I'm not doing, but it's been included in many of the guides.) 'IOMMU = Enabled' in the BIOS. (Again, I know this is just for VMs, which I'm not doing, but it's been included in many of the guides.) Disable C States in the BIOS. Add the disable C6 state command in the 'go' file. Add Flash -> Syslinux Config -> label unRAID OS (and GUI Mode) -> append 'rcu_nocbs=0-7' ... Add 'IOMMU = soft' to the /boot/syslinux/syslinux.cfg BIOS UPDATES: I have tried every possible permutation of these 6 settings with each of FIVE most recent firmware versions. At this point I'm basically ready to order an Intel i7-9700K and ASUS Prime Z390-A motherboard on my credit card and throw my AMD CPU/Mobo/RAM in the dumpster. Any advice anyone has would be extremely welcome! I can provide logs of the next crash, but I can tell you that thus far there hasn't been anything meaningful in them. It's like they stop writing to the log as soon as the crash begins, so there seems to be no evidence that anything went wrong.