June 14, 201214 yr I am suggesting adding the ability to set/mount array drives as RO. When a drive i full and organized... in essence finalized you could make it Read Only. This adds a whole level of data integrity that is immune to user frak up. I would see this feature being of interest to media collectors (i.e. the kind of users unRAID has bags of) where they organize their media collection and then keep it.
June 14, 201214 yr That is a suggestion well worth considering. However, I can foresee a little issue to be aware of .... R/O status would have to be checked and writes directed to another drive rather than generating an error. Perhaps the best way would be to consider the R/O drives to be 100% full.
June 14, 201214 yr Author I wouldn't have thought it would be that hard as fuse has alot of logic in it already and unRAID deals with including/excluding disks already as well. It wouldn't be no work but theres a chance it wouldn't be super complicated Only Tom will know for sure.
June 14, 201214 yr I wouldn't have thought it would be that hard as fuse has alot of logic in it already and unRAID deals with including/excluding disks already as well. Yes, I wonder whether it could link into the include/exclude logic. A R/O disk would have to be included for read, but excluded for write. Hmmm .... I suspect that treating a R/O disk as 100% full might be simpler to implement.
June 15, 201214 yr This is a great idea, one I would use if available. Setting a drive to R/O and setting it to 100% full are not the same thing. While both imply that you can not add files, only R/O disallows deleting and modifying files, not even modifying time stamps. I totally prefer R/O, would make it easier to provide a safe Guest experience, so I don't have to worry about others deleting videos they have watched. It also provides additional security, in that if a viral infection did succeed in gaining access to your network, there is nothing it could do to backups (or any type of files) on this drive.
June 15, 201214 yr This won't work for user shares, but can't you add onto the samba config to change a disk mount to RO?
June 15, 201214 yr Author I suppose there are a few ways this could be done but my preference would be the "safest" namely at the OS mount level. There is almost no chance this could go wrong. Ultimate implementation, if any, would come from Toms expertise in knowing the implications.
June 15, 201214 yr I suppose there are a few ways this could be done but my preference would be the "safest" namely at the OS mount level. There is almost no chance this could go wrong. Ultimate implementation, if any, would come from Toms expertise in knowing the implications. Errr ... I thought that this R/O was to apply to user shares. What if there is more than one user share on a disk - one to be R/O and the others to be R/W?
June 15, 201214 yr Author I was only considering a locked of disk ie.. complete and set in stone I estimate 75% of my unRAID data could be made RO in this way, most of it being collection data which never changes
June 15, 201214 yr Okay, that makes it a little simpler. However, unRAID will still have to make sure that it doesn't try to write to the R/O drive (drive/space allocation algorithm, inadvertent delete etc.), else it will generate an error and, perhaps, red-ball the drive.
June 15, 201214 yr Author Yeah there are definitely some fuse/application gotchas that would need taken into account. But that not withstanding there is something nice about a collector being able to say "this drive is complete lock it".
June 15, 201214 yr I definitely +1 this, being able to RO a drive would be a great feature for unraid.
June 15, 201214 yr I definitely +1 this, being able to RO a drive would be a great feature for unraid. Unless you are thinking of something drastically different, you can already specify read-only on the SAMBA shares. Granted, that does not make it read-only when logged in as root, but it does eliminate accidental deletions by family members.
June 15, 201214 yr I already have it set up that way, most of the drives I have R/W access to while others are RO, and the photo share is R/W by me and my wife. This does stop my son from accidentally deleting something. But as described above, locking a drive at the OS level when it is "complete" would be a nice feature to have as well.
June 15, 201214 yr I already have it set up that way, most of the drives I have R/W access to while others are RO, and the photo share is R/W by me and my wife. This does stop my son from accidentally deleting something. But as described above, locking a drive at the OS level when it is "complete" would be a nice feature to have as well. you could always try mount -o remount,ro /mnt/disk1 and see how unRAID reacts. One thing for sure, it will not be writable. It should not be much different than when the reiserfs makes a file-system read-only when it detects corruption. (in other words, the odds are good it will not cause a meltdown of your disks) When you need write access, you can restore it with mount -o remount,rw /mnt/disk1 As always, you are on your own with this... it is a likely for you to shoot yourself in the foot as anything. Joe L (Why do I sometimes feel like I'm letting a teenager play indoors with matches and dynamite?)
June 15, 201214 yr I'm a demolitions expert, and I don't even need the matches or dynamite, Anyway, I'm not the only one that thought this was a good idea, there were others before me! I like my server right now too much to go playing to see how it would react. I'll leave that for those with dedicated test servers, Last thing I feel like doing is having unraid freak out and redball a drive because I was curious, plus none of my disks are completely full right now so I don't need the feature yet
June 16, 201214 yr Author Doing a RO remount is going to have unpredictable results unless you also set all shares that access that access the drive or drives to RO as well. (which is limiting at best) Hence the feature request and not just trivially remounting DIY style
Archived
This topic is now archived and is closed to further replies.