je82

Looks like this wasn't it after all, this issue is so strange, it seems i can't even properly test it because when i do the permissions for folderd don't change, then a few weeks of auto running scripts suddenly the folders have changed permissions again, i have no idea what is causing this but its driving me insane because when it happens my backups can't run because folders are not writable. An example of it happening now is: I browse (with explorer UNC Path) \\Backup\Other Backup\ and it works fine. I decide to create a folder here because i want to add some st

Thanks for the info, yeah this was a great find i am happy that you guys made this thread. Something tells me many who use xfs encryption only find out about this very big flaw once it is too late, i am very happy to have found this before shit potentially hit the fan so to speak. Cheers, have a nice day!

I understand the risks, but to minimize the risks with encryption what are the steps to take? I guess the best way for me to answer my own questions it to actualy just remove one my array drives and try to mount it, the problem is the software costs nearly 700$, a big price to pay for a test, i will see if the trial version can give me the answer of if the team behind the software can give me a short test period just to make sure i have a solution in case a real disaster was to happen. From what i've learned through reading the forums is: 1. Backup your luks xfs en

Reading more on the subject it appears if your luks xfs header is corrupted you are screwed, there are therefor a good idea to backup your xfs headers as an extra security:

Thank you, i am doing a little bit of research if disaster was to strike and to backup these headers seem essential if you do xfs encryption as if the header is broken all your data is lost on that disk because you cannot mount it even with the correct password (as i understand?) A question to an expert like yourself, is it nessecary to run the header backup as a "cronjob" do have "fresh" header backups or is this only needed to run once as the header never changes?

This software seem to support luks xfs encrypted volumes: https://www.ufsexplorer.com/ufs-explorer-professional-recovery.php Does anyone have any experience in mounting a luks xfs encrypted unraid volume using this software or any software like it, is it straight forward just enter the key and it will work or does unraid apply more "strangeness" to the encryption header making an unraid luks xfs encrypted volume different from a regular one done in in something like ubuntu?

I'm not 100% certain i can find a definitive answer to this question. But part of unraids safety is that if parity fails and unraid array won't work for whatever reason, you can always just mount the single disks and access precious data that way. This appears to be pretty straight forward if you don't encrypt your filesystem, but what if you do? I can't find a straight forward way how to mount a luks xfs encrypted unraid volume in windows and move the data, is it possible? What software is required?

Awesome, thanks for all your hard work, love the unraid community!

Ah yes, i understand, thank you!

But will that work? Won't it be capped at 12tb if i already have one parity running at 12tb?

I'm growing out of my 24bay array, i only have 24tb left (!!) and no more slots for harddrives. I am now looking to start replacing drives to gain more storage, because i don't have any more space in my rack. Currently i have 2x12tb as parity, what is the most safe way to install bigger parity drives into this array? Do i have to change both of them at the same time then hope that array doesn't crash while the parity rebuilds or is there a better way?

Hey guys, should i use this docker rather then the more up to date one here: Is there any particular reasons you are running a shinobi that has not been updated in 6 months? The repo looks unactive or am i wrong here?

Hello, I've been testing this docker and i've ran into some issue where when i delete files in the shinobi interface the files on unraid just gets renamed to .fuse files until i shut down the shinobi docker completely these files will not disappear. It's like the docker container is locking the files as "in use" even though they shouldn't be. My configuration is as follows: Cache only share called "CCTV Files" Stored Video Location = /mnt/user/CCTV Files I added 3 variables to make the file permissions work properly with unraid PUID 99 PGID 100

Suddenly my docker containers all became completely unresponsive, also conencting via ssh and doing something basic like "htop" would not work. Connecting via ssh worked fine but once issued command htop there was nothing there, just darkness, like it couldn't render the text? I hit ctrl + c a few times to exit htop and try to browse /mnt/user0/ and it works just fine. Parts of the web gui would not load, the docker part was completely unresponsive, the array part was fully responsive, the dashboard took 2 minutes to load and once it came up it showed no indications of high memory

Can i access this information via unraid or is that via bios only?