tnorman

A couple hours later: I had a thought and decided to change the Max Memory setting in the docker's more settings area. I think I had this same issue when I installed this docker and I think that was how I actually fixed the issue mentioned earlier. I ran into an issue while doing this change. For some reason, when my changes were being rewritten, the docker would fail to be created and the error notification said a port was already in use. I checked my list of ports, it wasn't being used by another docker, but for some reason the docker thinks it is, so I also changed the ports being used in the docker. This allowed the docker to be correctly written. Now the docker is running again. So, I'm not sure if I ever really needed to change the inotify settings.

I'm unable to start the Crashplan docker. Currently I'm migrating files so I know my space usage went up significantly. And I just had an issue with the Crashplan docker running some high CPU usage that bogged down the system. I tried to stop the docker, but it wouldn't stop. So I restarted the server. Since rebooting I'm getting "[logmonitor ] ERROR: CrashPlan is exceeding inotify's max watch limit. Real-time file watching cannot work properly. The inotify watch limit needs to be increased on the host." With the Tips and Tweaks plugin, I've upped the max number to 2090000000. I don't think it can go any higher because if I increase the number any more the settings don't change even if the number is increased. Current Inotify Settings Max User Watches = 2090000000 Current User Watches = 351 Available User Watches = 2089999649 Max User instances = 128 This is a heck of a lot higher than it used to be, but Crashplan still won't start. It gives an execution error. When I look at the log for the docker container it has an error that I show above. It has couple other warnings, which I assume aren't causing the problem. (Here is a snippet showing those.) [xvnc ] Could not find any render nodes [xvnc ] Failed to initialize DRI3 extension [xvnc ] Mon Dec 8 20:01:08 2025 [xvnc ] vncext: VNC extension running! [xvnc ] vncext: Listening for VNC connections on /tmp/vnc.sock (mode 0660) [xvnc ] vncext: Listening for VNC connections on all interface(s), port 5900 [xvnc ] vncext: created VNC server for screen 0 [xvnc ] [mi] mieq: warning: overriding existing handler 0 with 0x14fddaa509b5 for event 2 [xvnc ] [mi] mieq: warning: overriding existing handler 0 with 0x14fddaa509b5 for event 3 [supervisor ] starting service 'nginx'... Thoughts on how to fix this?

I have tried a few different power and data cords. So I decided to swap out the hard drive for a new SSD that is larger. I had planned to do this at some point in time, but I had been putting it off. The hard drive connection points wouldn't hold on to the power and data cords very well. I initially thought the problem was the cords, but the cords slid on and held on the SSD nicely. Guess I'll see if there is a further issue. Thank you for the help!

I don't know if the Power Supply is at it's limits. I'm guessing at it. The more I read about power supply needs it sounds like it should be enough to handle the 1 parity drive, 8 data drives and 1 cache drive. It's an older PSU, so maybe it has just been aging and needs to be replaced. Or maybe it isn't the problem at all.

The drive has been in service for 8 years based of of smart data. But it doesn't show any problem in the smart data. I've switched data cables without any noticeable consistency. I've switched power cables without any noticeable consistency.

I've ran a scrub on the cache drive. No errors were found. I did a check file system status on the cache drive and it returned an error, but it also said not to fix it without being told to do so by a developer. The cache drive keeps going from working fine, to not working fine every time I reboot.

I've got a bit of a strange issue, and its going to take a bit to explain. I'm currently running 7.2. Though I don't think the version has anything to do with the issue I'm running into. I'm thinking it might be a power supply or cache drive issue... leaning toward cache drive. But I've thought about replacing the power supply on the system since it's pretty much at it's limits. In September, I had a cache drive issue, or I thought it was a cache drive issue and I'm now wondering if it was something else or maybe it is still a cache drive issue that is only shows up in specific circumstances. I worked with someone on here to diagnose the issue. I ended up reformatting the cache drive and everything seemed to be good again. Since then I've ran into an oddity for me... maybe someone else knows what this is a sign of. Usually the issue starts with the server getting shut off because power drops or something else happens. When I upgraded to 7.2 I ran into the same issue, but rebooting a couple times seemed to fix it. My first reboot will usually show everything looking ok, but nothing functioning correctly. I couldn't access my shares from another computer because it was acting like there were no files in any share even when looking at the shares via the Unraid menu. Docker's appear to be running, but in reality I can't access any of them. So I shut it down, and power on the system a few minutes later. The power off process isn't normal though because the webpage doesn't change from the normal menu screen I was on when shutting down... but the system physically shuts off. My second bootup will usually show that the cache drive is not connected. So the server doesn't start. I shut it down again. My third bootup will look like everything is good. Cache drive is reconnected and the server appears to be up and running. However when I open up the log to see what is going on I'll have a flood of error messages about rsyslogd errors. I've tried to chase down what the errors mean or the cause, but I've learned that shutting down the server again and powering up again a few minutes later seems to fix it. So that's what I do. The fourth bootup. Everthing appears to be running fine. No cache drive issue. The server stays up and running just fine. When I look at the syslog and I see some rsyslogd errors and I/O errors dealing with the sdk which is the cache drive, but the system seems fine. No errors are stopping the system from working or raising red flags. The log isn't being flooded by rsyslogd errors. I'm seeing some rsyslogd errors and btrfs errors on the cache drive (sdk). I'm not sure if this is normal... I assume it isn't. I have a new SSD drive that I could swap out for the current cache drive. That was the plan when I bought it, but I hadn't researched how to swap a cache drive. So... is this a continuation of a cache drive issue? Maybe the drive is failing, but just hasn't fully failed yet? I'm attaching the log files. Some guidance would be appreciated. tower-diagnostics-20251112-1405.zip

I did not realize this. That may help me with a couple I have yet to setup. Thank you!

I did reformat the cache drive. That's the one has been throwing the error. I've been thinking about changing it to an SSD. I even bought one expecting I would need to put a new drive in it. I think I'll keep an eye on it for now. I also want to buy a new power supply as I'm on the limits of the current one, but I think I want to wait a month or two before doing that. Right now I need to work on getting my apps back up and running, and maybe my vm I had on there.

After a few days of issues, I finally seem to have my unraid server back in good condition. I had a few wrong turns and I learned that trusting what AI says can lead to major problems. Thankfully backups helped me when I fubared the server when a pool drive decided to disable itself. None the less, the Cache drive has no been formatted and seems to be working fine.I'm recreating the apps i was using. I know I have a backup, but I figured I'd start fresh. I've attached the diagnostic files. Please let me know if you seeing anything wrong. tower-diagnostics-20251001-2313.zip

Here is the most recent diagnostics. The cache drive continues to be in read only. I've tried moving to a different wire, but it doesn't seem to make a difference. The only indication that there is a problem is if I look at the Cache drive's pool device status information under Corruption Errors. It shows 1. The Main tab doesn't show a problem. It seems to me if the cache drive is in read only mode the Main tab should have a notification on the cache drive indicating a problem. I did a memtest for 24 hours. No errors over that time. It passed every time. I'm scratching my head and not sure what to do. tower-diagnostics-20250929-2142.zip

I scrubbed the pool. I then went to recreate the docker. I stopped the docker and deleted the disk image. When I tried to restart the docker, it wouldn't start. So I rebooted. After reboot, the docker started but the apps wouldn't run... I was surprised to even see the apps in the docker since I had deleted the disk image and the apps needed to be reinstalled. The internet went down during the reboot, which shouldn't change anything but since it was back up I thought I'd just reboot it again to see if it fixes itself. Then the computer didn't reboot like normal. It looked like it got stuck on the display of the logo for the motherboard during reboot. I'm wondering why, but it wasn't giving any details. Turned the machine off and on and seemed to boot back up ok this time... except the cache drive was started in read only mode and the docker image is not able to be written to. I've got to get some rest for work. I'm just going to look into it more tomorrow. Going to leave it running overnight. Maybe elves will come out and fix it for me. :)

I'm looking thru the diagnostics. I'm not sure what the rsyslogd errors mean. But the BTRFS error (device sdc1): incorrect extent count for 44044386304; counted 3960, expected 3959 is on the cache drive which has me wondering what to do. I've been reading about it and it sounds like there might be a problem I need to chase down.

Here is the new diagnostics after I replaced the power cable and connected it to an extra sata connector. The docker is now running, which is better than it was the last couple of reboots. Going to feel silly if it is just the power cable. tower-diagnostics-20250927-1646.zip

Currently my cache drive is online, but the Fix Common Problems says it is not able to be written. I looked into the diagnostics in the docker log and I'm thinking the drive itself is having some issues. Last event that happened was the scsi data cable fell off the drive. I was able to physically fix this and put the drive back in and the system rebuilt the drive. A few days later is when my docker apps stopped working. I have tried rebuilding the docker image as well as increasing the docker size. I've rebooted a couple times. I'm attaching the diagnostics zip file. I just did a new one. I'm basing my thinking it is a bad drive off the docker.log from a previous diagnostic log from 2 days prior. tower-diagnostics-20250926-2027.zip

Thank you Squid. I rebooted and ran FCP. no issue came up. Thank you for the help. I'll try to remember to reboot and see if the error stays in the future.

Hello. I appreciate a little help. Recently I got a notification that there was an error with the server. Fix Common Problems reported that it found Machine Check Events detected on your server. And that it "detected hardware errors" I recently took apart my server, cleaned all the dust bunnies out, and then reassembled the server. Everything seemed ok. I ran a parity check and it finished without problem. I did have a drive error but it cleared without repetition so far. I did change out the CPU cooler because the fan was a dust bunny hideout spot. I also changed some cables. I looked at the syslog. And these are the errors it reported since the server was cleaned ... I assume Fix Common Problems is complaining about the last couple of lines about AMD Processor not supported, which makes me scratch my head since it is the same hardware that was running before and after the cleaning. I don't see a reason why this error is suddenly coming up. And from what I see this is really just a badly worded notice that Unraid is using edac_mce_amd module instead of the normal one. Should I just tell FCP to ignore this error? I'm attaching the diagnostic zip file if that helps. Any help appreciated. tower-diagnostics-20250317-2145.zip

It's funny. I thought I deleted this forum post shortly after making it. I was able to restart the server and restart the Docker Safe New Permissions which finished in just a minute or two. Yes there was a ton of small files on the folder it had stuck on initially, but it went thru that folder fairly quickly the second time. I don't know why it froze, but it's better now. Thank you for the help JorgeB !

I was removing a drive so I started to use unblance plugin to remove the files, but was told that I needed to run Docker Safe New Permissions first to fix a few permission issues. I started the Docker Safe New Permissions process about 2 days ago. I know the folder it lists that it is on has several thousand files in it. So I assume it is just happily working its way through it, but I can't tell if it is stuck on something or if it actually still working. It worked itself through half the array in just a few hours but has been stuck on this same folder for the better part of 36 hours to my knowledge. Any ideas on ways to figure out if it is actually working still? Seems like it is stuck and I'm not sure if I should do a hard reboot of the system or do something else. Anyone knowledge in the matter?

Perhaps I'm wrong. I know i looked at each drive's settings. Maybe I just putting apply/done before moving to the next drive didn't do anything. Or maybe I just forgot to do it.

Very possible. The funny thing is I went in to every disk and checked the value to see what it was set at and then set it. I didn't even think about going into the default value.

Yep. That solved it. Setting a value other than the default in the settings->disk settings for disk warning to something other than 45. I'm running a parity check. It paused at 11% when a disk reached 44. Figured I'd reply here in case someone else sees this thread. Thank you.

I sent you the files via a direct message since they appear to contain some private info.

I'm now on version 2021.06.04 I just ran a test and it paused again when the disks were at about 30- 32 degrees Celsius. I stopped the parity check... well actually stopped the array by accident. Meant to stop the parity check. But restarted the array and the parity check was stopped. I started a debug written to the flash drive. I then started a new parity check. It paused again at about 0.3% "Following drives overheated: parity(31C) disk1(32C) disk2(31C) disk3(32C) disk4(32C) disk5(30C) disk6(33C) disk7(29C) disk8(32C) Correcting Parity Check (0.3%% completed)" Attached is the debug log

I'll look into that. I have the plugin in to auto update the plugins running, It's saying I'm up to date. Hmmmm.....