je82

would love to see this as well, even though it might be a complex implementation i think it would be worth moving towards.

I had been transfering files to disk 15 via smb but i checked so the files were written and the disk was not reading/writing before i pressed shutdown AI tells me this that sounds plausible? as ive never seen it happen before, could potentially a timed smb connection cause shutdown event to end not gracefully? i cannot see any issues with the server now and ive been using it for years, this just happened once so it threw me off.

for now i installed tips & tweaks to have the shutdown bash/ssh on shutdown, i think that might have caused it but i still don't understand why it would shutdown before the 200 seconds has passed if it couldn't do a graceful shutdown

I shutdown one of my NAS (7.1.4) servers, it simply shutdown without any issue with much spare time in the "graceful shutdown" timer, yet when i boot the NAS again it wants to scan parity? I have attached the syslog:

I hve some issues with recycle bin again, not sure if it started when i upgraded to 7.1.4 but for whatever reason recycle bin will not pickup files inside /mnt/user/Temp/.Recycle.Bin , it does however pickup all the files from other shares such as /mnt/user/Media/.Recycle.Bin /mnt/user/Applications/.Recycle.Bin when i delete a file inside /mnt/user/Temp it is successfully logged (Oct 29 12:30:42 MOVED_TO => /mnt/user/Temp/.Recycle.Bin/fdsfdsfdsfsfdsf.txt) but the bin itself wil not be displayed in the row above shere you can see the size of each bin for each share that has contents in their bins, i can see the other bins just fine. Checking the permissions for the bin, all seems fine: Ive reinstalled the plugin, restarted the plugin, tweaked settings, ive verified the share setting for the Temp share, nothing seem to help, the plugin will not display the contents of the bin for the Temp share even though the bin has multiple files and the plugin itself is also logging the deletions that are being made to the bin itself. Worth noting the recycle bin is showing "Recycle Bin total size 0B" even though right below in the share section we see 3 different shares with 65gb, 392gb and 13.8gb as well This was not a problem previously, i am unsure when it started but pretty sure it started when i updated to 7.1.4 Your ideas are welcome. EDIT: I found the issue, the data contained in /mnt/user/Temp/.Recycle.Bin was so large the script that builds the stats for recycle bin timed out which was why temp never showed up in the list, i went in and manually deleted some stuff and there were over a million files and 24tb of data in there, yeah ive been doing some cleaning, now it works fine again.

asked AI: TLDR: old unraid > LUKS1, new(er) unraid > LUKS2

Hmm this has me a little bit concerned, my oldest NAS which was created in 2019 using XFS Encrypted, whenever i backup the luksheader on this machine, the header is only 1028kb (1mb) , while all the headers backed up on NAS3 which was created 2 years ago, they are 16384kb (16MB) what is causing this massive difference in size? Disk size on old nas i 12tb, new nas 18tb, but going from 1028kb > 16384kb seems unreasonable? Can i trust these headers? Why is it outputting so small headers on the older nas? (older nas is using 7.1.4 but array was created using unraid 6x something i believe, whatever was modern in 2019.)

does this mean that my old luksheaders i backed up in older versions of unraid are wrong? or did the names of the devices change at some point as unraid has gotten updated? (just asking so i know if i have to go back and backup the headers in my other unraid boxes) according to my own documentation which is years old i used the /dev/ path previously when doing the luksheader backups.

Using 7.1.4 version of unraid, i cannot backup my xfs luksheaders? I've documented the commands ive used in the past to backup my luksheaders but they dont seem to work the same anymore? lsblk output: What am i doing wrong?

I see, thanks for letting me know, glad i asked!

Interesting, so you can have mixed filesystems in the same array? I never knew that. The main reason i would like to use ZFS is mainly bitrot protection, performance on the array is not crucial but considering its not the greatest for me as i am using dual parity with xfs encrypted maybe it would be a problem if its really really slow? So what usecase is mainly targeted for ZFS? I though most people used it for their main arrays?

So the official way of using ZFS is to have 1 pool per drive? do you have parity then? i definitely do not want the ZFS filesystem spread out over more drives, i like to keep the filesystem (jbod) so in case if extreme failure i can always just mount the single drives and extract the data.

Hi, I am looking to make the move to ZFS encrypted, what are the best ways of going about this? Considering unraid does not support multi arrays yet i guess the only way to do this is to setup an array on a temporary licensed unraid server and then move the data over the network? Or is there any better solution that i didn't think of?

oh wow! here i am relying on AI and i guess it had not been updated with this new information, when was this added? great stuff!

Came across another thing that would be a real quality of life improvement to unraid. Integrate something like https://github.com/doron1/unraid-newenckey to unraid to make an easy and convenient way for the end user to change their encryption keys to unlock array, right now its very finicky to do this manually and process to change this depends on what filesystem you are using, a universal way that makes it easy for user to change the pass-phrase to change encryption key no matter which filesystem they have encrypted would be a real improvement.