IanMcLeish

Before setting up my 1st unraid, I watched a lot of YouTube videos, mostly SpaceInvader One. I came to unraid around 6.10 or 11. At the time there was a lot of buzz about zfs. I set up all my array drives as zfs, which I now realise may not have been the best idea. My array drives are split across 2 sabrent usb drive cages, again I know not a best case scenario! I had the hardware before I ever knew about Unraid- that's my excuse.... One of the cages has caused issues a couple of times, with drive 8 going offline a few times. I have that drive replaced with a similar drive in a different slot- the old drive 8 precleared no problem, so not sure if it was the drive or the slot. So my array has 13 8TB drives, 2 for parity. Some drives have a significant list of zfs errors, which obviously cannot be "repaired" as there is no redundancy for zfs as they are array drives and not a pool. I did run a scrub on one drive, but the errors are still there. To be clear everything is working well as far as I can tell. My unraid is mainly used for movie and TV "cord cutting". I have been considering swapping to xfs for my array drives, which is seems I should have started with? I was thinking stop the array, start it with one drive missing, reformat that drive as xfs and then add it back to the array. I understand that will take considerable time to rebuild all 11 drives and would be a very bad idea with only one parity drive. My question I guess is, should I bother? I know zfs wasn't the best choice, but was it a bad enough choice to put the array through 11 data rebuilds?? Thanks for your thoughts.

What settings do you have set for the minimum free space requirements in the shares? Maybe you could increase that to force use of the new disk??

Hi, after upgrading to 7.3.1 I have this banner at the top of my screen. "VM Settings: A reboot is required to apply changes" I have rebooted a few times since I first saw this- had to change a drive out, and now and it comes back as soon as I go near the VM page, even though I have not made any single change to any VM nor any settings. Actually there are no VM.s running. Google AI suggests toggling VMs on and off, and changing setting and changing them back. I didn't want to mess with settings I didnt change, but toggling things and changing back doesn't sort it. I am doing a rebuild on a drive, so no rebooting for a day or two. Has anyone else encountered this? It is not a big deal, but the banner is annoying, especially as I don't know why the system thinks it needs to be there, having changed not a single thing?

Thanks Trurl, I am attaching diagnostics. I have looked through my syslog share and I cannot find the relevant file- I rebooted not long after I started this thread- a powerbutton reboot as the UI was non responsive. So the latest log starts on 5th March, just after or during the reboot. Nothing last modified near that time shows the relevant date. I suspect what Stalled the rebuild was me messing with shares- I have tried to rename shares in the GUI- everyone says it can be done, but it doesn't work for me, or at least not easily. I have managed to rename 2, but their old names now show in my list of shares as well. I think they are zfs datasets, JorgeB said they were, but I have no idea how he knows that, and deleting them with an instruction he gave me didn't do anything. The reason I was trying to rename them is because of complaints about invalid characters in the name since 7.2.3 I think. I wish I had been advised about invalid names when I was naming them, but they seemed to be valid then. I think I started on 6.8 or 6.9, so I am relatively new to this. unraidnas-diagnostics-20260307-2340.zip

Trurl and JorgeB, I do have a syslog server running, so I likely do have the info, but I would not know what logs to share? It does seem my unraid crashes when trying to rename shares, even if (and I presume they should be?) Docker and VMs are not running. I tried to rename shares before with no joy - getting complaints about invalid or illegal characters, and I gave up trying to fix them, but trying again breaks things a lot. I tried renaming shares on the flash drive, that broke everything! Renaming in the GUI /shares fails every time. Even shares I have deleted "come back", but JorgeB reckoned they were zfs datasets rather than folders. How to tell them apart?? I can post logs if you let me know what to send - there are about 10, though obviously only a couple from the last few days. Will I post them here? Are they "anonymisied" ? Does that matter?

I bought hardware before I ever found out about Unraid, so my set up is not recommended. I had an issue where 2 drives in a hard drive cage, connected over usb were disabled. I removed the drives in the main page, started the array, stopped it and readded them, prompting obviously a data rebuild on the two drives. I do have 2 parity drives fortunately. The rebuild failed multiple times, no idea why, though I have been having issues with attempting to rename shares. As my system has run flawlessly for months until I upgraded to 7.2.4 I downgraded to 7.2.3, hoping that might be the solution. But the rebuild was still failing and those drive being disabled again. I checked the usb drive in windows - scan disk showed no issues. I changed the usb cable to a new one. Both the old and new one looked the same in a usb cable checker I have, but this checks what the cable is able to do, not that it is working properly. I restarted the Unraid and using Dynamix Safe mode plugin, I disabled all plugins. VMS were disabled and for the most part docker were as well, but after a number of hours I did enable plugins - Emby only, due to friends and family complaints. The data rebuild was started yesterday at about 9am and was reaching completion this evening, but the progress stalled at 95.5% It has been there for the last 3 hours. There is no disk activity anymore - emby is now not being used by anyone, so no reads or writes. The log shows that ; Mar 5 21:46:14 UnraidNAS kernel: md: sync done. time=132208sec Mar 5 21:46:14 UnraidNAS kernel: md: recovery thread: exit status: 0 Which I Googled to mean that the reconstruct had completed with no errors, but the main page and dashboard still say 95.5%, meaning I am stuck - I would rather not "cancel" the rebuild, I cannot stop the array as there is a Parity Operation running, I did try to pause the rebuild, but that did nothing. The only thing I can think to do is shut the thing server down by the power button and hope that it does not demand a rebuild on restart, though it would obviously want to do a parity check. Would anyone have any suggestions? Have I misunderstood the 2 log entires that I think indicate successful completion? I'm running a diagnostics right now - it is taking a loooooong time on the shares, but I will post it when (if?) it completes, and also a screenshot of the log and the apparent progress of the rebuild. Sorry the screen grab is so blurred, not sure why. Nope, diagnostics are stuck at my Paperless folder, which I recently tried to rename to paperless, but as changing the name to the same isn't allowed, even if there is a change in case, I tried to rename it to paperless1, then hoping to rename it to paperless. I read on this forum that this would work, but apparently not for me☹️ The whole thing has gone unresponsive now. I tried to ssh restart the GUI, no success. I guess a hard power button has become the only option - I tried to look at the Paperless/paperless/paperless1 name by trying to browse the flash drive and everything crashed. I tried a few browsers, no success. Although all suggestions are now moot, cos I have run out of options, I am still going to post this.

I don't have a blue wrench on mine??

Running 7.2 and this just recurred for me for the second time. The solution still works though.

I tried to rename another folder from the shares tab. The ui is now not loading and anything I can see is not updating - the only screen that isn't loading, should I say trying to load at this time is the dashboard, and it has frozen. Is there any other way to try to rename shares other than in the shares tab, cos that seems to brick my server every time? I don't know if the parity check is still running or not, but all drives still seem active, I cannot load terminal - blank page. It is 7.05pm, but the time says 16.58 on the unraid main page. I can't believe I am the only person with this issue! Edit- I had to do another command line shutdown, which was once again unsafe. I love computers and I used to love troubleshooting them (Win 95 and Alta Vista), but like cars, as they became more complicated, and I get older, I just wish they would work. Why is unraid complaining about the names of these shares when they never, ever did before - I wouldn't have called them that had I been warned before, but like Frank said, soes it matter??

Sorry JorgeB, I was hesitant to re-run these commands as last time all I saw was the unraid wait icon and nothing happened. Against my better judgement, and a fter a reboot I did run them and there was no output, but no wait icon either- the "ghost shares" have gone! Thanks for your help. I will try to rename the other folders when the parity check has completed. Am I correct in thinking that you knew those "folders" were datasets because the had a 2 instead of a 1 after them? Just so I know in future? Thanks for your help.

JorgeB, thanks for all the suggestions. I did try those commands at lunchtime, but nothing changed, but although the gui seemed responsive, once again buttons were not doing what they were supposed to - after an unclean shutdown, I was running a parity check. Although the parity check seemed to be running- equal reads from all array drives (all dockers and vms were off) the parity check seemed to stop at 7.1% all afternoon. I tried to pause, no effect. I tried to cancel, no effect. Although the gui was not giving a 500 server error, it wasn't doing what I thought is should do. Had to hit the blue poweroff button eventually. I shall leave this issue until I have a parity check successfully completed. WHther it is connected I don't know but the unraid api had to be restarted as well. I didn't make those data sets, but I guess they are doing no harm for the moment, so I'll sit tight where I am and ignore them, cos I seem to be causing more harm than good with my attempts at deleting the "shares" or datasets, and I have had a couple of unclean shutdowns from problems since 7.2, so I reckon a successful parity check is number 1 on the list. I will try again and report back, but it seems share renames do not work for me at this moment. Thanks again!

root@UnraidNAS:~# ls -l /mnt/cache2_ssd total 806338 drwxrwxrwx 2 nobody users 2 Nov 4 09:50 Amandas\ Stuff/ drwxrwxrwx 2 nobody users 2 Nov 4 08:42 Dad\ Photos/ drwxrwxrwx 2 nobody users 6 Nov 5 04:40 syslog/ -rwxrwxrwx 1 root root 824975436 Mar 3 2025 unraidnas-v7.0.0-flash-backup-20250303-0906.zip* root@UnraidNAS:~# ls -l /mnt/user0 total 133 drwxrwxrwx 1 nobody users 2 Aug 13 15:08 AmandasStuff/ drwxrwxrwx 1 nobody users 4 Jan 31 2025 Backups/ drwxrwxrwx 1 nobody users 3 Apr 30 2025 Dad-Photos/ drwxrwxrwx 1 nobody users 3 Aug 6 20:22 Documents/ drwxrwxrwx 1 nobody users 18 Jul 13 08:24 Downloads/ drwxrwxrwx 1 nobody users 2 May 12 15:15 Downloads\ from\ PC/ drwxrwxrwx 1 nobody users 6 Jul 20 08:55 Drone\ Videos/ drwxrwxrwx 1 nobody users 3 May 8 17:51 Drone\ Videos\ -\ Remote\ Controllers/ drwxrwxrwx 1 nobody users 4 Feb 25 2025 Dropbox_Download/ drwxrwxrwx+ 1 nobody users 3 Feb 25 2025 Hard\ Drive\ Images/ drwxrwxrwx 1 nobody users 112 Feb 25 2025 Home\ Videos/ drwxrwxrwx 1 nobody users 3 Aug 9 11:10 Immich_Photos/ drwxrwxrwx 1 nobody users 4 Sep 9 17:13 Paperless/ drwxrwxrwx 1 nobody users 4 Feb 25 2025 Raspberry\ Pi/ drwxrwxrwx 1 nobody users 5 Oct 29 20:42 UrBackups/ drwxrwxrwx 1 nobody users 17 Aug 17 12:18 dash-cam/ drwxrwxrwx 1 nobody users 6 Aug 11 03:17 data/ drwxrwxrwx 1 nobody users 17 Nov 1 17:29 isos/ drwxrwxrwx 1 nobody users 4 Apr 30 2025 photos/ drwxrwxrwx 1 nobody users 3 Jul 13 2024 roms/ drwxrwxrwx 1 nobody users 7 Nov 5 08:36 syslog/ root@UnraidNAS:~# The 2 files on the ssd cache wont delete. Unraid sees the shares as empty but doesn't delete them. Is this the information you wanted?

I tried to delete the folders, or directories in the cache_2 drive, nothing happened. Tried again to delete the unwanted empty shares. Nope. (At least things are still working GUI wise) I did click the clean up button and it seemed to run, but it didn't remove the 2 duff shares pointing only to the cache_2 drive. ANd the button is now disabled with no change. I'll enclose the full diagnostics, but I think I should just wait and see if a newer version of Unraid fixes this issue? Everything is working, I just have unwanted unnessesary shares. Not a huge deal! unraidnas-diagnostics-20251104-1814.zip

Frank1940 - I just started to change the share names because Unraid 7.2 was warning about illegal characters. I tried to delete the duplicated shares and after some messing they did go, until I rebooted and they all came back. I have 2 shares with their correct names showing as well as their incorrect names showing, both only pointing to cache_2 for some reason. Those shares exist on the cache 2 drive and they are both empty. I looked in the flash drive config/shares folder and only the two correct names are listed in there, but unanonymised diagnostics show both as being in the shares folder.? Should I delete the unreal shares off of that cache drive and see what happens? I have no idea how they were gone and then arrived back after a reboot! shares.zip

It isn't crashing now, but the apply button seems to not do anything- no unraid wait icon, nothing. I'll try a reboot again and try again. Folks are using emby atm though. I though I saw Squid say that the shares could be renamed in boot/config/shares somewhere on this forum, but it is difficult to know what works for one version and not for another. I did try that, but fortunately I backed up the folder before I did, cos it didn't work for me. I HAVE somehow managed to rename 2 shares, both ended up getting duplicated and the wrong name wouldn't delete. I tried to delete the folders off the cache drive- the duplicated were only stored on Cache_2 and I tried to delete them. Shares were empty, but they would not delete. I did try to a few times, but then I went back to the shares and they did delete. So I do have 2 done, but those were shares I was willing to lose, not so much some of the others.