TexasDaddy

I tried running the nodes on their own /temp directory local to them and all jobs on those nodes would fail to copy. Maybe then my issue is with tdarr?

I know this is an older topic, but tried to follow the instructions and guidance given and am unable to get this working. Perhaps it's a change in unRAID that is preventing this process from working but I wanted to try and see if I could get this to work. I have update my "go" and "smb-extra.conf" files as noted below. The share does show up, but is not accessible. Let me know what I'm missing, please. go file contents: #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & # force iptable mangle module to load (required for *vpn dockers) /sbin/modprobe iptable_mangle # Create transcodes share mkdir -p /mnt/transcodes smb-extra.conf file contents (user has been modified to protect the innocent, using actual username from configured user on server): [transcodes] path=/tmp/transcodes comment = browseable = yes valid users = <my_user> write list = <my_user> public = yes writeable = yes vfs object = The directory is created and I noticed that it is owned by root, so I "chown nobody:users /mnt/transcodes" and "chmod 777 /mnt/transcodes", but that had no change. Share is still inaccessible from my PC. My goal here is to present a ramdisk share that is accessible from multiple nodes on my network for tdarr transcoding as opposed to wearing out my temp_pool SSDs that I had setup for this. If I were only transcoding on my server then I would just pass the /temp path into /dev/shm but that isn't accessible from my other nodes and the jobs would fail.

BMC reset should have little or nothing to do with your unRAID server performance. It designed to access and manage your hardware associated with your motherboard, monitor onboard sensors, set manual fan curves, update BIOS, and remote console level access. Don't fret over a reset to defaults. Spin down of drives has several factors that are going to play into it. If you are using any SAS drives you absolutely must install the SAS drive plugin (from the apps tab). This is a known issue with SAS drives and things are getting better, but you should still use the plugin until there is better native support of SAS drive management. If you are not using SAS, then you should take a look at your Drive Settings to validate/update your spin down wait time. Also, are you using the Turbo Write plugin? This will affect drive spin up. What is your mover schedule? Are you using the Mover Tuning plugin? If you have a smaller cache, and have mover scheduled to run frequently to keep the cache from filling up, and you are doing lots of writes to your cache, then I would have at a minimum of 1 hour wait time on my spin down, with mover running every hour and turbo mode enabled for mover. Disks spinning at low speed with minimal disk activity is better for the life of the disk then lots of spin ups and spin downs. If disk life isn't a concern and you just want minimum power usage, then shorter wait times are better for your situation. Also, you may consider not using cache for those shares and have them write direct to disk. Then you can set your mover to run less frequently for those shares you need fast write speeds going to long term disk storage. These are all things to consider in building out your storage and performance plan. "I cant get the parity to stick" is a bit more concerning and very unclear as to what you mean. If you haven't yet, start a separate thread for this issue in the General support forum as this would be completely unrelated to the IPMI plugin and absolutely post with diagnostics so people don't have to ask for them to assist you. If your system is locking up or crashing before a parity check can complete then you need to take a step back, do hardware testing to find and isolate the issue, then slowly build upon a stable and working platform.

I have an ASRock Rack board and mine displays the IPMI/BMC IP address as soon as I power up and before the system completes the POST to access BIOS. I can then look for the MAC in my DHCP. If you are not able to do that and you have a managed switch, you should be able to SSH into your switch and use commands similar to "show arp" and/or "show mac-address" (google documentation specific to your switch) to identify the MAC addresses by port. If that is not an option for you then you could also try a network port scanner to find all active IP addresses on your network and their associated MAC addresses (https://www.softperfect.com/products/networkscanner/). I've used this one many times over the years with great success. Resetting your BMC should have no affect on your server's functionality. If your BMC was set with a static IP that is not part of your existing subnet then doing the reset will be the only way to get it back to defaults which should set the network interface to use DHCP. Any of the methods I outlined above will not work if the IP was set to static outside of your existing network scope. The only thing that might work is if your system displays the IPMI/BMC IP address pre-POST and you added an IP address to your client computer that was in that subnet scope. Example: Your home network is 192.168.0.x 255.255.255.0 and the BMC was set to 10.0.0.86 255.255.255.0. You could add a second IP address to your computer's NIC by accessing the adapter's properties and setting your IP manually to what your current address is so you maintain connectivity to your existing network, and add a second IP address that would be 10.0.0.87 255.255.255.0 (not the same as the IP of the BMC, but on the same subnet) and then you should be able to access the web interface of the BMC by going to the BMC's IP address in your web browser, log in and reset the settings. But as a side note, if it has a static IP then it probably has a non-default password and your only recourse will be to reset the BMC in BIOS.

I'm also an X570D4U-2L2T user and would LOVE to get the fan controller functionality working. This is a GREAT plugin and I love the unRAID community.

So my issue was not with Preclear, but with my memory (as suggested I think the slower clock speeds with all 4 sticks populated where causing timing issues and corruption resulting in hung processes). On the 2 sticks at full stock speed, I precleared 5 disks simultaneously without issue. Thanks for looking and offering up guidance and suggestions.

Alright, marking this solved as I've been completely stable since removing 2 sticks of memory. Multiple memory test were run with no issues found, both in my buddy's bench rig and in my server. I'm thinking the issue is with the system controller trying to run the memory at lower speeds when all 4 DIMM slots are populated. Hopefully this will be fixed with a BIOS update, but for now I'm more then happy to run with the 2 sticks at rated stock speeds and I don't really need the other 64 GB of memory at this time as my system is currently only using 14%. I'm going to use these 2 sticks for upgrading my backup server so it's just one (technically 2) less thing to buy. I GREATLY APPRECIATE all the feedback and advice.

I ran MemTest for 2 days (back in January) before I even booted into unRAID for the first time, so when I started having stability issues memory never even crossed my mind. I'm trying to avoid having my system down for several days, but if it can't be avoided then I guess I must... Things have been rock solid with just the 2 sticks so I'm kinda avoidin pokin the bear.

I've had system instability recently and someone else had mentioned they thought it looked like a memory issue from my diags. I pulled 2 sticks from my system and so far everything has been rock solid. I've got the 2 sticks I pulled being tested individually on my buddy's bench rig that he recently completed a full burn-in to validate all hardware but has not found any issues with my memory at this time. He is going to be running more extensive testing and will get back to me. If it all tests out ok, then I'm going to reach out to AsRock Rack support to see if there is anything they would like to investigate regarding the issue. The only thing that comes to mind is that the memory is 3200 MHz, and the MB slows it down to 2666 MHz with 4 sticks of DR DIMMS are populated. Perhaps there is a timing issue with the board. I finished my preclears without issue on my backup server, so I will need to get a new external drive to test if pulling the memory resolved the issue on my primary from completing the post-read process.

LOL Yes, I do really love this motherboard. Thinking of buying a second for my other server, moving this Ryzen 9 over and downgrading my primary to a 65W TDP CPU like the Ryzen 7 3700x. This server only has 2U of workable space with the 12-bays in the back and my other server has a full 4U so I can put in a much better cooler and push the CPU without feeling uncomfortable about the fan noise or the temps. Thanks for looking at the logs and my stress level has come down quite a bit since things appear to be very stable at this point. If all the memory modules pass after rigorous testing, then I'll just put all 4 sticks in. If I start having problems again then it will be time to engage AsRock to see about RMA'ing the board and/or a possible BIOS update from them. I know they are a bit slow to release stable BIOS updates, but support seems to be pretty good with providing Beta BIOS fixes.

You are correct sir. I was looking at what I'm running now, not what I was running before.

So here are my latest diags. Parity check finished successfully yesterday and I let the server continue running through the night to see if I had another hang during an idle period, and all appears to be good at this point. I performed a normal reboot today and let the system run for a while before collecting these logs. No errors that I've noticed but wouldn't mind a second set of eyes on them if anyone is up to it. I've got a friend with a bench rig testing my 2 sticks I pulled the other day with the latest version of MemTest86. Testing them individually and so far no errors. If they both pass all testing then I guess I'll be dropping them back in and see if things continue to run without issues. As for the memory speed question earlier, I'm running a Gen3 Ryzen so it supports 3200 MHz, which is the speed of the memory I purchased from the QVL (4 x KSM32ED8/32ME). titan-diagnostics-20210405-1229.zip

Just for some info/background. The CPU max settings you're seeing are accurate as I am using the Power Save CPU Governor setting from Tip and Tweaks to keep this CPU from running so hot during Handbrake transcodes. I'm going to get a 65W CPU to swap out in this server as I only have 2U worth of space to work with in this chassis so to keep the fan noise low I'm throttling for now and will swap for a lower TDP in the near future. I'll be putting this CPU in my backup unRAID server where I can put a much larger cooler in to better handle the heat and will offload the transcoding to that machine and just let it go full throttle. As for the "network errors" they are all UDP failures for syslog as I was sending my logs to a remote server during this instability and those are failures of logs trying to write while the LACP Team Trunk is being negotiated and initialized. As soon as that completes, the errors stop as it is able to write all events to the remote log server. I've since configured it to just write to the local syslog and will verify after this Parity check that those errors are no longer present during the boot process. So, after running without issue, or any errors or process kill messages in the logs since pully the pair of memory sticks I'm really thinking my issues are all related to bad memory. I'm not gonna call this solved just yet as I'd like the parity to finish and go through a significant idle period afterward to say things are now stable. Fingers cross, all goes well over the next day or two and I can start working on figuring out which stick of memory I'll need to RMA. I do completely agree that I too would like to see a clean log, so after the parity completes I'll be performing a normal restart and grab a fresh set of diags for all to look at just to make sure I'm not missing anything. More to come...

So everything just crapped out again and I was able to get diagnostics before giving a shutdown command. Time to pull a pair of RAM sticks and see if things get any better. I might pull 3 and just run on one stick at a time till I find out if it is one of them. Is it possible to get @limetech (or someone from support) to possibly take a look and give some ideas on getting this thing resolved? titan-diagnostics-20210402-2155.zip

I'm an idiot... the slow parity check was because of my Resilio Sync docker indexing my files to sync to my backup server. As soon as I stopped the docker, my parity speed shot up to about 155 MB/s. I did cancel the slow parity check, removed the line from my syslinux.cfg, enabled Global C States, and set the Power Supply Idle Control to typical. The Parity check started over after the reboot, but I'll keep my sync offline for the time being till this check completes successfully. I'm really hoping this resolves my issues as I was looking at some long downtimes and additional purchases to get to the bottom of these issues. Thanks to everyone's suggestions, ideas, and advise. I'll post back as things progress whatever the outcome.