gundamguy

Lately that's the process I've been using, basically if I want to write to my shares I toggle them to Read-Write, and then write then toggle them back. Working fine so far. Just a bit tedious, a nice "one click" button would be cool.

I can confirm that it does. If you have a cache pool those directories are treated as protected. That said, I'm mixed on cache pools (running one myself) because it's not well documented, and people have had trouble recovering data / stability issues.

You could create a bash script and execute it at regular intervals via cron. So what you would want to do is look for guidance on writing a bash script using rsync (doesn't have to be rsync could be another program to make the copy including cp) then you would create a .cron file which unRAID would add to your crontab on reboot. Of course this assume a semi-moderate level of Linux skills, so if you don't have those skills let us know and we might brainstorm other approaches.

I agree, after reading itimpi's comment I agree New Drive Configuration seems better.

Well they sure do have a good looking design. Haven't had the time to really dive into it yet, but I hope they can teach me some new Linux skillz.

Bigger Parity Drive to give upgrade room: Yes this is a great idea. It'll save you a lot of time in the future. The rest of the questions are a bit ahead of me, since I don't really mess with VM's still. Hope someone else can come in and answer your questions.

That's a road we really don't want to go back down! Long ago, the comparable function used to be called 'Restore', and caused so much confusion and trouble! It really is a brand new configuration, not a restored configuration. A parity drive is valid for a particular configuration of drives, and depends on each drive, whether it's present or not. To remove a drive, you have to start over, or find a way to remove the bits of that drive exactly like you were adding the drive to the array. People used to have issues with their array, see that 'Restore' button, and think that was gong to restore their array to operation, when what it would do is destroy their configuration and invalidate their parity! Nowadays you can start over with a new config, but also have the option to accept the current parity drive as already valid. That's not something you (KeithLM) want to do though, as you do need a fresh parity build. This all makes sense. Suggestion though, modify the wording from "New Configuration" to "New Parity Configuration" because that makes it more clear that this changes the parity not the rest of the settings the user might have customized.

Thanks a lot for your quick reply! Hopefully someone else (*cough* @jonp *cough*) knows what's going on with the AFP protocol. It works really bad. Even Samba works much better! Isn't AFP depreciated in general though? Apple shifted to supporting SMB2 in Maverick.

Question: I am trying to improve my wife's web development processes and am wondering if you have the same issues if say your plan was to use virtual machines (using a OS that is easy to update and was designed to be forward facing) instead of Dockers?

Based on what the OP said in the OP and the OP's split level, unRAID is doing what it was told to do. Keeping all folders under Movies and all folders under TV on the same disk. If that's not what you want then you need to adjust your split level. i am not sure that is the case. With the given structure a Movie folder or a TV Series folder is contained to a single disk, but new Movies or TV Series folders should be able to go to another disk. I'm pretty sure it's the case that unRAID is doing that. What I think we need to know is moved the data, because it could have created the folder structure before filing in the movies or TV shows.

Based on what the OP said in the OP and the OP's split level, unRAID is doing what it was told to do. Keeping all folders under Movies and all folders under TV on the same disk.

Not 100% sure and not sure how every ransomware will behave (since this could change) however I would think it would encrypt the files and you would have the choice of deleting them. What they are hoping is that they hit files that you don't want to delete or lose I don't think it formats the whole disk.

Well I'm not 100% sure the behavior you described is what I would have expected. I don't have another answer however. You might want to consider the "The parity swap procedure" I've not done this personally so you might want more feedback on if this is the right path to go down and if anyone has any insight or gotcha's to avoid. Edit: fixed URL

This is an old report on a version of unRAID that I hope you aren't running, it also only contained a snippet from the log file. I don't think an solution was found. What would be helpful is if you could post your diagnostic file so that we can look at more of the logs and see what is going on.

Again you should take everything I'm about to say with a Grain of Salt because this is all from reading on the internet, not from personal or first hand experience. The issue as I see it is that the way you actually repair a BTRFS filesystem is with mount recovery or mount recovery,ro or in rare cases btrfs-zero-log, btrfs restore is only to recover data from a filesystem that won't mount, it won't repair that filesystem. And the line of last resort is btrfs check --repair ... which as you noted is destructive. I'm not saying BTRFS is great or anything. I'm just wondering if anyone has tried the recovery mount option or btrfs-zero-log option when they had issues, or did they go straight to btrfs check --repair?

I don't know that this is possible. Do they sell Z-Wave boosters or could you get a second Z-Wave USB and install it as a repeater?

Magic to make it work... no, but you could try having your friend use the replacement key process to migrate over the key... keep in mind that this will blacklist the unused USB2. But if I understand correctly that shouldn't be a real issue.

You might want to report this as a bug or defect. It sounds like an issue that is going to need Lime-Tech to look into / fix.

Also all of your config for your shares (split levels, includes and excludes, etc) will be lost, the shares themselves will be automatically recreated with default settings. Obviously all the system settings you've changed like notifications and spin down delay / scheduler will need to be reset as well.

The crux of the issue here is that when there is BTRFS corruption or file system issues of one sort or another, it seems the only way forward is to recover the data to another device, and reformat. This is NOT what should be happening with a filesystem IMHO. Most other file systems allow you to fix the issue in place, one way or another, and allow you to continue using it after the tools have given the FS a clean bill of health. Are there any BTRFS tools that will consistently repair most filesystem issues of a single volume to a reusable state? When I had my issue, all I could do was get it mounted read only and copy my files. Nothing I tried would allow me to mount the drive normally and continue to use it. I don't disagree. Having never had an issue forcing me to use any of these tools I can't really speak to how effective they are. I do think an important thing to understand about BTRFS is that it's not like XFS or Rieserfs there isn't one single tool to run to repair the filesystem because btrfs is designed to be more self healing. Often what I see fixing BTRFS mount issues is the recovery mount option or the btrfs-zero-log tool. That said I do want to understand what your process was exactly. Did you try mounting the file system with the recovery option? Additional thought, mount recovery and mount -o recovery,ro might be throwing people off because that just seems like you are mounting the fautly file system not actually fixing it... but it's my understanding that doing the recovery mount will often fix the problems that prevented a clean mount and the btrfs partition will mount properly the next time. If that doesn't work it might be an issue that btrfs-zero-log can fix... and if that doesn't work, time to try restore or btrfs -check to a least copy the data. IMO everyone is looking for a checkfs tool to fix btrfs because years and years of using checkfs tools have people thinking that's what you have to do.... But BTRFS is different... Again I'm not an expert on any of this, all of this is based on my internet sleuthing and I have personally not had to try any of these things and can't vouch for them. If I sound accusatory or condescending that's not my goal, and I apologize... All I really want is a better understanding of what people tried that didn't work, to see if the process we are telling people to attempt is bad.

I've seen his and Tom's comments on BTRFS, and found them completely plausible. I trust them, and I really want to lean that way, but user experience here in the field is not near as rosy. And now that I have just learned how useless scrub is for single drives, it makes it really hard to recommend. There's a btrfs check --repair command, but it has a terrible reputation, may cause more harm than good. I can't recommend it at all, except for last ditch file recovery (NOT for repair). For single drives, reformatting is the only repair available! Based on my research there are a lot of BTRFS file system tools, none of which are very well documented. In Order of Recommended Trial: Attempt to mount the faulty file system 1) mount -o recovery,ro {Attempts to mount the filesystem in recover read only mode} 1.5) mount -o degraded {Only for btrfs RAID5/RAID6 configurations} 2) btrfs-zero-log {can help mount a filesystem if the last blocks btrfs wrote before a crash were corrupted or out of order due to bad hardware or other bugs.} Attempt to recover data from a file system that won't mount normally or with the steps above 1) btrfs restore {"a non-destructive method for attempting to recover data from an unmountable filesystem, does not attempt to repair the filesystem just extract data} 2) btrfs check --repair {Can only run on an unmounted filesystem, destructive will attempt to repair filesystem} Scrub is something completely different and is only checking the metadata vs the metadata. It does not repair or fix anything. I feel like a lot of the reasons people are having problems with repairing btrfs issues is because they go right to btrfs check... and or think scrub is the same thing as btrfs check.

Scrub can only fix errors on a mirrored cache pool, I believe that's not on the wiki, using a single device it will identify errors but it can't fix them. That's because Scrub isn't actually the same thing as check disk. There is a BTRFS check disk command "btrfsck." But before that you should try btrfs restore

I never know how concerned you should be about End-to-End errors, because they are so uncommon. Basically the firmware on your HardDrive likes to make sure things are working properly so it compares the checksum of the data written to the physical media with the checksum of the data in the HardDrives cache, if it doesn't match that's an End to End error. IMO I don't know that I would trust a disk that had an end to end error. Additional info... not sure if this will work, but you could try lsof | grep '/dev/sda1' where sda1 is the device number of drive6 to see what process is hanging disk6 then kill that process. You could also try a force unmount (but do this as a last resort because it won't sync the filesystem first.

You can increase the verbosity by passing xfs_repair it the -v option as well. I suggest you look over the man page, it might tell you more about what xfs_repair can and can't do. Also perhaps before running xfs_repair in destructive mode, run it with the -n (no modify) mode to get a sense of what xfs_repair would have fixed if it were allow to make modifications. (Then you can run it again without the -n flag to have it execute the modifications) Depending on your views of this... might be totally not required.

You shouldn't need to manually do that, as "cache only" basically does that. Looking good on the rest.