stuckless

Thanks I'll rebuild. This is the second time in 2 months that I'll be rebuilding the parity drive. Wish I fully understood why this was happening Thanks for help. Much appreciated.

I adjusted all the sata cables and power cables and rebooted. here's the new log. The drive is still disabled. Does that mean that the system thinks it is physically not there? mediaserver-diagnostics-20230109-1736.zip Thanks

By a power/connection issue, do you think it could be power supply issue? Bad cable? loose cable? I'll open up the box and reseat all the power connectors, and then re-run a diag and post it here. Thanks, Sean.

The SMART shows OK, and the last parity check (7 days ago) showed OK, but now the drive is showing READ errors and is disabled. About a month ago, I noticed the same issue, and I removed and then re-aded the partity drive and it added/rebuilt fine, but now I'm back to this again. Is this a bad disk? Something else goin on? Hopefully someone smarter than me can see something in the logs. Thanks for any help. mediaserver-diagnostics-20230108-0806.zip

I realize this is an old topic, but I wanted to chime in with an alternate fix for this. First off, it's worth noting that on Ubuntu at least, this the default color for a directory that is set with world writeable permissions (ie, anyone can write to it). And while it's hard to read, on Ubuntu, it's easier to read than the unRAID web console implementation. My guess is that in linux they really want you to know that this folder is basically insecure. While you could use the color=never option, I actually like having color, just not this color. So this is what I did. 1. I made a backup of /etc/DIR_COLORS 2. I edited the /etc/DIR_COLORS (nano /etc/DIR_COLORS) and changed the lines STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w) OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky to STICKY_OTHER_WRITABLE 01;33 # dir that is sticky and other-writable (+t,o+w) OTHER_WRITABLE 01;33 # dir that is other-writable (o+w) and not sticky This file talks about what those numbers are, and they explain them in the comments before this section. # Below are the color init strings for the basic file types. A color init # string consists of one or more of the following numeric codes: # Attribute codes: # 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed # Text color codes: # 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white # Background color codes: # 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white So you see that 34;42 is blue text on green background and changed it to bold (01) yellow (33) text with no background. 3. This changes this at the system level, but it likely will not survice a reboot, so, I made a backup of this file in the config area. cp /etc/DIR_COLORS /boot/config/DIR_COLORS.sean I don't reboot my unraid server very often, but, when I do, then then login and copy my backup from config to the /etc/DIR_COLORS. Although I haven't done this yet, and it'll likely be months before I actually verify this part. So now ls still shows me that those files are world writeable, but it's easier to read (for me). Given that these folders are created by unRAID is there an option in unRAID to never create world writeable folders? (because that would solve the problem as well, since they'd just show the normal blue)

Yeah, the umountable drive scared me, since my expectation was that unRAID could continue to work with a single drive failure. I'm happy that it did in fact recovery everything, and that the unmountable drive became mountable again. Maybe unraid "fixed" the problems??

I've steered many people to unRAID for a variety of reasons. It's a decent "server" technology for running containers, with the added benefit of getting data protection. I've not experienced a drive failure since running unRAID, but, I've had many leading up to unRAID, which was why I decided to use it myself. This past week a friend of mine called me up and said, 'My unRAID is toast". I remoted into his machine and sure enough one of his drives was "missing" and the other drive was "unmountable" and the parity drive was good. My first thought was "oh crap" he lost 2 drives and now he lost everything. I admit I didn't do much research, but I told him to order a new drive and install it, which he did. I then remoted in and assigned it, and unRAID came back with a message about rebuilding the data, so I was hopeful. 5 hours later, it was done, and after a restart on the Array, all data was back. unRAID worked, and it did what it supposed to do. So just wanted to say "thanks". You always hope when you buy something that it'll work as advertised, but you never know Great job guys.

@Blacksmoke Thanks for the find... It does seem like this is my issue as well. Once I can get access the system, I'll try the solution posted there, but I'm pretty confident that it's the same issue, so hopefully the same solution works. @trurl thanks for that explanation. I didn't realize /etc was a memory fs, but that explains why my edits did take. Thanks guys for the help. I'll report back once I get confirmation of the fix.

@Squid thanks, I'll try to get that as soon as I can. Unfortunately this was a client update in another city, so when they are back on Monday, I'll remote into their machine and perform the diagnostics. Does unRAID have a backout from a failed upgrade -- something that can be run from a console? Is there a way, from a console, to downgrade? Now that I've hacked it to get the UI working, is there a plugin that can do a downgrade? (I thought about maybe installing the dvb plugin and using its list of kernels to see if I could downgrade.. but not sure what that would do, and I really don't want to mess up their system any more than it is). One thing that comes to mind when I did the upgrade on their machine, is that I clicked the "update" link, twice. The first time it ran through the download and extract process, and I clicked done, and then I got distracted with some other tasks, so when I came back, I clicked the "update" again, and it did the download and extract. I can't imagine that doing this twice could be this destructive, especially since unRAID doesn't force a reboot and they don't disable or check if the update happened before doing it again.

I was finally able to hack the configuration to allow the UI to start by commenting out the ssl cert stuff in the nginx configuration. # Ok to use concatenated pem files; nginx will do the right thing. # ssl_certificate /etc/ssl/certs/unraid_bundle.pem; # ssl_certificate_key /etc/ssl/certs/unraid_bundle.pem; # ssl_trusted_certificate /etc/ssl/certs/unraid_bundle.pem; but this is just a hack, since on a reboot, it appear to uncomment them, and then the UI won't start again. Hopefully unRAID can determine what is going on and provide a fix.

Just upgraded to 6.5 and now I can't access the web ui. I finally logged into the physical machine and booted into gui and tried to access the web UI from there, but still can't connect. Tried starting nginx manually and i get the following error, which is likely why the web ui doesn't work. nginx: [emerg] PEM_read_bio_X509_AUX("/etc/ssl/certs/unraid_bundle.pem") failed (SSL: error:0906D06C:PEM routines:PEM_read_bio:no start line:Expecting: TRUSTED CERTIFICATE) How can I get back to 6.3.5 or fix this issue?? Thanks, Sean.

I don't disagree. I run my own open source projects, and I tell people the same thing... ie, it's just easier to pick and choose what you are willing to support. I just threw it out there because someone as asking me about supporting it in my SageTV container, but this is a kernel things, so I passed it along here

The hauppauge site does list links for linux drivers for HDPRV2. Not sure when that happened. http://www.hauppauge.com/site/support/linux.html#tabs-3 Not sure how well this can be incorporated with the unRAID kernel, but, drivers do exist (apparently).

I don't know if unRAID has a GUI cron (or if there is a cron plugin, etc), but docker is fully command line driven. So, if you can find a way to create a CRON, you can probably use 'docker restart' command and restart it. https://docs.docker.com/engine/reference/commandline/restart/

To add to this... is the web ui using 'docker kill' vs 'docker stop'... If so, I think the "STOP" in the WebUI should be using 'docker stop' to allow the container to gracefully shut down. Could the unRAID admins clarify the process here? thx. I found this post on the difference http://superuser.com/questions/756999/whats-the-difference-between-docker-stop-and-docker-kill And as CraziFuzzy suggested, I think the WebUI should have a "STOP" that sends 'docker stop' and a "FORCE STOP" that sends 'docker kill'.