eggman9713

Just a thing I noted when installing this update. When I was ready to update I clicked on the Update Now link in the banner on the main page rather than going to Tools > Update OS. That bypassed the required acknowledgement of the release notes that you had implemented recently. Probably should fix that.

Update on this. A little over a week ago I got an email that the support rep agreed that the drive should have a 5 year warranty and they were going to look into it with their supervisor. I haven’t gotten another response since then and will likely try to follow up in the next couple of days.

Just a little experience I thought I'd share. I just bought a brand new Toshiba N300 Pro 4TB drive from Amazon (Sold and shipped by Amazon, not a third-party seller). And it showed up with zero hours on the SMART, and was in retail packaging like a new drive should be. I haven't bought a Toshiba drive in many years, and just felt like going with a new manufacturer to add some diversity to my drives. I do this to hedge against bad batches of drives by the same manufacturer. The N300 Pro is advertised with a 5-year warranty on the Amazon listing, the box, and Toshiba's website. I always check the serial numbers of my new and newly-acquired used drives and register for the warranty coverage if the manufacturer allows that. Some don't have a registration process and expect you to just contact them if you have an issue in the warranty period. This is the case with Toshiba. But buried on their websites is a tool to check the serial number. It's only showing a 3 year warranty when it should be 5. Now the N300 normal version is a 3-year warranted drive. But this is an N300 Pro, according to its label and its box. But the actual model number that comes back from the serial number lookup doesn't match what's on the drive or on the box either. Interestingly it also indicates that this drive was sold to an OEM and the warranty is through the OEM. This drive came direct from Amazon so that doesn't seem right either. I have an email into Toshiba customer support to clarify the situation, and I'll let you know what comes of it. TL;DR: Always check your drive serial numbers with the manufacturer to make sure they have the warranty period you expect on them, and register them if the manufacturer allows.

Unraid 6.12.3 has been released in the stable branch and I updated from 6.12.3-rc3 to 6.12.3 stable and still haven't had the problem since before I installed the rc3. See the Announcement post for it.

I just installed 6.12.3-rc3, and I forgot to stop the array before the reboot, and sure enough it got stuck. But I was able to open a web terminal and use umount /var/lib/docker and it stopped the array and rebooted normally. After reboot I also stopped the array, and it didn't get stuck. Rebooted, and that was normal. Stopped the array again, and it stopped and started again normally. So far, the issue seems to be fixed. I'll try stopping and rebooting a couple of times in the next few days. I normally don't reboot my server for weeks at a time, nor stop the array that often. If 6.12.3 still isn't a stable release in the next week I'll provide an update.

I just had my array get stuck while stopping today. The Docker image remained mounted, but Docker had already stopped. Unmounting the /dev/loop2 device from the command line per ljm42's instructions allowed the array to finish stopping as normal, and it started back up clean (I didn't shut down or reboot the server).

The parity check on my last unclean shutdown finished with zero errors, as it always seems to whenever I have an unclean shutdown. That lends some credence in my mind to the thought that everything is stopping but just something is holding up the disks unmounting. I did some testing this evening with the following results. 1. Stop array while watching the log. Everything shuts down as normal and the array stops quickly. 2. Reboot the server while the array is stopped. System comes back up, autostarts the array (I forgot to turn that off for testing), and it came up clean. 3. Stop array again while watching the log. Everything stops normally. 4. Start the array. Normal. 5. Reboot the server while the array is running. Watching the log. Everything shuts down properly, the system reboots normal and clean. 6. Now, I shut down the server while the array is running, rather than rebooting it, because that is when it last happened to me last night. System shuts down normally, and when I power it back on, it comes up clean. So now it seems to be behaving itself on my server. But I do have the logs from the last time it happened showing the behavior. I'll try to do some more testing in the next couple of days.

I have also noticed this behavior after upgrading to 6.12. I am currently on 6.12.2. I shut down my server to remove an unused cleared drive, and it came back up as unclean. I am waiting for the parity check to finish, and am going to extend my shutdown times for disks (90 to 120 seconds), VMs (60 to 90 seconds), and Docker (60 to 90 seconds) to see if that fixes it, but according to my syslog.txt file which I have posted a snippet of below it appears it is my /mnt/cache_nvme device that keeps being busy and fails to unmount. Docker and libvirt appear to shut down gracefully, the array disks appear to unmount properly, as well as my ZFS disk pool that I created as an experiment to test 6.12's new ZFS functionality. It tries to unmount cache_nvme like this repeatedly after everything else has stopped, until the log file ends before it powers off. (Kveer is my server name) Jul 5 22:32:59 Kveer emhttpd: shcmd (1269849): umount /mnt/cache_nvme Jul 5 22:32:59 Kveer root: umount: /mnt/cache_nvme: target is busy. Jul 5 22:32:59 Kveer emhttpd: shcmd (1269849): exit status: 32 Jul 5 22:32:59 Kveer emhttpd: Retry unmounting disk share(s)... Jul 5 22:33:04 Kveer emhttpd: Unmounting disks... Jul 5 22:33:04 Kveer emhttpd: shcmd (1269850): umount /mnt/cache_nvme Jul 5 22:33:04 Kveer root: umount: /mnt/cache_nvme: target is busy. Jul 5 22:33:04 Kveer emhttpd: shcmd (1269850): exit status: 32 Jul 5 22:33:04 Kveer emhttpd: Retry unmounting disk share(s)... Jul 5 22:33:09 Kveer emhttpd: Unmounting disks... Jul 5 22:33:09 Kveer emhttpd: shcmd (1269851): umount /mnt/cache_nvme Jul 5 22:33:09 Kveer root: umount: /mnt/cache_nvme: target is busy. Jul 5 22:33:09 Kveer emhttpd: shcmd (1269851): exit status: 32 Jul 5 22:33:09 Kveer emhttpd: Retry unmounting disk share(s)... In my case, the cache_nvme device is an M.2 nvme drive in my server that is btrfs mirrored to another one and those two drives are set up a cache pool. I have my system share there as well as my syslog folder, domains, appdata, and nextcloud docker storage share. Basically, anything that I want to be fast and accessible and doesn't need to be on the array. Interestingly, I purposely don't have disk shares enabled or used at all. In the Global Share Settings, I have Enable Disk Shares set to "No". Maybe that's just an overlap in terminology? The parity check should finish in the morning and after I get home from work tomorrow night I'll try to investigate further.

I was having this same issue recently until I just noticed today that it seems to be fine. I don't think I've changed anything recently on my server that would affect this. I'm accessing my server using Firefox 88.0.1, and unfortunately I don't know what version of Firefox I had the last time I noticed the web terminal was hard to read.