Leaderboard

There seem to be a significant number of cases recently in the forums where someone has formatted a disk flagged as ‘unmountable’ when in fact the correct action would have been to run a file system check/repair. If one does not have backups in place this could lead to data loss that is avoidable if the correct recovery action had been taken. A simple change would be to change the warning message given when format is selected to suggest that a file system check/repair might be a more appropriate action if the disk had previously mounted OK. This would at least give visibility to new users that formatting is not the only way to clear the 'unmountable' status. A more comprehensive change would be if UnRAID could track if a disk with a given serial in a given disk position was previously successfully mounted. In such a case file system corruption become the most likely problem so the staus could be changed on such a mount failure to suggest that the first course of action should be to run a file system check (and thus a possible repair) rather than simply to format the disk. I would think this could cut down siginificantly on cases where the format was not the appropriate action.

To upgrade: If you are running any 6.4 or later release, click 'Check for Updates' on the Tools/Update OS page. If you are running a pre-6.4 release, click 'Check for Updates' on the Plugins page. If the above doesn't work, navigate to Plugins/Install Plugin, select/copy/paste this plugin URL and click Install: https://s3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer.plg Refer also to @ljm42 excellent 6.4 Update Notes which are helpful especially if you are upgrading from a pre-6.4 release. BIOS: Especially if using Virtual Machines, we highly recommend keeping your motherboard bios up-to-date. Bugs: If you discover a bug or other issue new to this release, please open a Stable Releases Bug Report. This will likely be the last of the Unraid 6.6 series since the linux kernel, 4.18.20 was recently marked EOL (no more updates). We had a devil of a time deciding whether to simply update to the 4.19 kernel now, but we're about to start Unraid 6.7 public -rc, which uses 4.19 kernel. If 6.7 stretches out too far we may need to produce a 6.6.7 for security updates of if something apocalyptic comes up. Version 6.6.6 2018-12-01 Base distro: openssl: version 1.1.1a (CVE-2018-0734 CVE-2018-5407) openssl-solibs: version 1.1.1a (CVE-2018-0734 CVE-2018-5407) samba: version 4.8.7 (CVE-2018-14629 CVE-2018-16841 CVE-2018-16851 CVE-2018-16853) Linux kernel: version 4.18.20 OOT Intel 10gbps network driver: ixgbe: version 5.5.2 Management: bug fix: error reported by 'btrfs filesystem show' prevented proper btrs cache pool analysis update smartmontools drivedb and hwdata/{pci.ids,usb.ids,oui.txt,manuf.txt} webgui: Black and White theme: make select arrow consistent for all browsers webgui: All themes: create consistent select arrow for all browsers using pure css webgui: Fixed: flash share warning is given when SMB is disabled webgui: Added customizable header background color webgui: All themes: css corrections webgui: Revert FAT32 filename collisions webgui: Dashboard: add disk utilization, cpu load & memory usage coloring webgui: Syslinux Configuration: rename Basic/Advanced view to Raw/Menu webgui: Fixed: parity schedule not taking zero values (e.g. Sunday=0) webgui: Prevent Adblocker from hiding share list webgui: Fixed missing font-awesome class in VM CPU popup window webgui: Improved PCIe ACS override help text webgui: Improved VFIO allow unsafe interrupts help text webgui: Apply syslinux changes to all menus except safe mode webgui: add per DIMM information toggle webgui: Fixed PHP warnings in Vars.page webgui: Docker: narrow CPU pinning list to fit lower resolutions webgui: Added confirmation checkbox when missing disk in array webgui: Disable cache slots selection when cache disks are re-arranged webgui: Added confirmation checkbox when missing cache disk webgui: Remove unused information in array view

I did have a backup of that folder plus done the backup within the app itself. Done what you've said and... it worked Thank you so much, never knew how to delete that template. Lesson learned, again thank you very much for your help !!!!

I did not mean to delete the radarr config folder. You said you have a backup, good thing because you'll need it! I meant to delete the radarr template. so in the docker page, delete the radarr container, add new container, select the radarr template and click on the red round X. That will delete the template. hopefully, that is where the drive definition is saved.

I dont care how long it takes, its only running one time a day... and its not many DVDR files anyway thesedays... THANK YOU SO MUCH, ill try that! Until now seems to work fine, ill report back!

This is user adjustable for all disks and for each disk. For cache: Main - Cache Devices - Cache - Cache Settings - Warning (or Critical) Disk Utilization Threshold. Similarly for each disk. The default for all disks is at Settings - Disk Settings - Warning (or Critical) Disk Utilization Threshold.

Given the totality of the situation, I think the best method is the path of least resistance, that being using the network to transfer the data using windows native tools. In your situation, assuming the ONLY data we are talking about is the existing windows stuff, that is, nothing currently on the array, I would, in this order, 1. Temporarily unassign the parity drive(s). This enables the highest write speed possible, and since the data is still on the windows box, the risk of a drive loss losing data is extremely low. 2. Checksum the entire drive contents in windows. Several different tools available to do that. 3. Set up shares on unraid to reflect what you need. 4. Copy (not move) data across the network to unraid. I wouldn't bother with third party apps, just use built in windows copy. 5. Checksum the data on unraid. Compare checksums to ensure an accurate copy. 6. Move windows drives into unraid array. DO NOT FORMAT THEM, just assign them as data drives, and reassign the parity drive(s) to build parity. 7. Once parity is built successfully and checked, then you can format the old windows drives. Until they are formatted, they will retain the NTFS data but won't be readable in the array. If something goes wrong they can be recovered using testdisk. This procedure is admittedly slow, but very safe. How much time is safety worth to you? Do you have backups of this data elsewhere? unraid is not a substitute for backups, and it seems you have plenty of space. Maybe it would be better to leave the windows drives intact and store them for backup.

The ones with the higher capacity probably have files on the cache drive (notice they have an orange triangle icon) , so the cache drive size is being included in the size calculated.

Issue does not exist for me and hasn’t since they incorporated the fix in a previous version.

Maybe your postman has it out for you.

Figured it out thanks to a buddy at work, I missed a setting in the BIOS. IOMMU said it was enabled, but there was a setting missing. Under Advanced, AMD PBS, there's a setting to enable PCI across both dies. IOMMU group 33: [10de:1b81] 41:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1070] (rev a1) [10de:10f0] 41:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1) IOMMU group 34: [10de:1b81] 42:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1070] (rev a1) [10de:10f0] 42:00.1 Audio device: NVIDIA Corporation GP104 High Definition Audio Controller (rev a1) Thanks for the input everyone.

That one shows problems in different attributes, like reported uncorrect and runtime bad block, in my mind further confirming nothing to do with being shucked, probably just bad luck, or you might have some issues on your server, like bad power, that can damage drives.

Wow! Amazing write up! Thank you. 👍 That was way more than I expected, and I understood quite a bit at the first attempt. I shall definitely read a few times and have a think whether to tackle something similar. Right now, it's academic (no Kindle available) but I am sure I could solve that pretty quicky. The threads that you linked to are also very valuable as an insight into how this kind of approach can evolve. Thanks again.

It was prophetic.

It could have been a real "Beast" doing this 6.6.6 upgrade, but "Mark" my words...it went very well so far... 😈

Since you... "had a devil of a time deciding whether to simply update to the 4.19 kernel now..." 6.6.6 was the version number that came to mind? 🤣😎 As an FYI, I was able to upgrade both of my servers without the need for any holy water, crosses, chanting or other types of rituals.

Any packages found on flash in directory called 'extra' will be installed. Any plugins found in 'config/plugins/*' will be installed. The 'config/smb-extra.conf' file can be used to add extra Samba (SMB shares).

Normally just that you disconnect from the old machine and connect to the new system and make sure the new system allows boot from USB. But consider using a USB 2.0 port. Not sure why you consider this step if you are going to reuse the disks - then you can just move the disks to the new system and unRAID will look for the serial numbers on the disks based on the configuration stored on the USB flash drive. If you plan to use new disks then create a new array with the new disks. Then consider either using a 30-day evaluation license to allow you to run two unRAID concurrently and transfer the data over the network. Or mount the old drives using the unassigned devices plugin and copy the data to the new array disks. Each parity must be at least as large as any data disk. But the two parity drives do not need to have the same size. And you decide how fast drives to use.

Try this From a windows command prompt (run as administrator) mklink /d "c:\WhateverFolderYouWantItCalled" "\\unRaidServer\unRaidShareName" Your share will wind up being mounted within that folder on an existing windows drive Should be close enough to what you need.