To avoid problems like ransomware, I would like to see an option on Global Share Settings to Lock the entire array Read-Only, until the Spin-Up all disks button is manually pressed and until such time as the disks spin-down at which time the entire array reverts to Read-Only again.

 

In other words, the array can only be Write Enabled by doing a manual spin-up, after it spins down again it's Read-Only.  Auo spin-up's keep it Read-Only.

To avoid problems like ransomware, I would like to see an option on Global Share Settings to Lock the entire array Read-Only, until the Spin-Up all disks button is manually pressed and until such time as the disks spin-down at which time the entire array reverts to Read-Only again.

 

In other words, the array can only be Write Enabled by doing a manual spin-up, after it spins down again it's Read-Only.  Auo spin-up's keep it Read-Only.

I can see where you are coming from, but why tie it to spinup.    It would be much easier (and simpler for the user) just to make it a global setting that is either on or off.

Because I write to my array once or twice a day only, the rest of the time I only read from it.

 

Ransomware would spin it up Read-Only, if I want to write to the array, I need it spun-up anyway, so it makes sense to include it on the spin up button.

 

Because I write to my array once or twice a day only, the rest of the time I only read from it.

 

Ransomware would spin it up Read-Only, if I want to write to the array, I need it spun-up anyway, so it makes sense to include it on the spin up button.

Since you have to take manual action anyway, a separate button seems a much cleaner solution.  Also if it is a separate button, you do not need to spin up the drives to change the access, and conversely one can still spin up the drives without changing the access.  I think trying to combine such a function with the spin up/down buttons would just lead to confusion for most users.

I would appreciate the convenience of a button to block all write to shares.

 

However, I don't think it's that secure.

During the window that you deactivate it to copy, ALL your open shares are still subjected to ransomware risk.

 

A better way in my opinion is to have a single public share to hole files in transition and copy / move them to the share using mc + console.

And you can actually mount the public share as a folder on your PC for convenience -> it's just like another local folder.

I find this arrangement to be more secured because at all time, all established data is protected.

 

The transition data on the public share is certainly always exposed. That's a worth trade-off in my opinion -> it's a simple question of losing 20GB vs losing 20TB.

 

Because I write to my array once or twice a day only, the rest of the time I only read from it.

 

Ransomware would spin it up Read-Only, if I want to write to the array, I need it spun-up anyway, so it makes sense to include it on the spin up button.

Since you have to take manual action anyway, a separate button seems a much cleaner solution.  Also if it is a separate button, you do not need to spin up the drives to change the access, and conversely one can still spin up the drives without changing the access.  I think trying to combine such a function with the spin up/down buttons would just lead to confusion for most users.

 

Two spin-up buttons if the file system is locked, one for Spin-Up R/O and one for Spin-Up R/W.  Reverting to R/O after spin-down.

 

I don't like the mc solution as it's too fiddly and too many extra steps.

Two spin-up buttons if the file system is locked, one for Spin-Up R/O and one for Spin-Up R/W.  Reverting to R/O after spin-down.

 

I don't like the mc solution as it's too fiddly and too many extra steps.

You can always use the Krusader docker instead. 

 

You can always use the Krusader docker instead. 

 

It seems to be, a huge number of requests for assistance are around docker, I don't really want to start learning that either.

 

I think my brain is already full.

 

I'm a firm believer in the KISS methodolgy.

I would appreciate the convenience of a button to block all write to shares.

 

However, I don't think it's that secure.

During the window that you deactivate it to copy, ALL your open shares are still subjected to ransomware risk.

 

A better way in my opinion is to have a single public share to hole files in transition and copy / move them to the share using mc + console.

And you can actually mount the public share as a folder on your PC for convenience -> it's just like another local folder.

I find this arrangement to be more secured because at all time, all established data is protected.

 

The transition data on the public share is certainly always exposed. That's a worth trade-off in my opinion -> it's a simple question of losing 20GB vs losing 20TB.

 

IMO an ideal set up to me would transparent to the user. I was thinking of how this could be accomplished with good SAMBA settings and mover... SAMBA settings are Read and Write, that all writes (including modification of existing files (which is the hard part) are cached to the cache drive, then Mover runs with a first pass that uses the --existing option and --compare-dest=DIR option to move any files that match an existing file in the compare directory into a "holding directory" then run Rsync like normal for new files.

 

Then have a setting in the webgui that invokes a move from the holding directory to the normal directory if the user approves.

 

Yes this basically forces users that frequently open and modify files to click a button like every time they want to move a file they modified to the array. For people who mostly store media files that once saved are not supposed to change this isn't as big a deal...

 

Just a thought, the really hard part to me is how do you handle forcing all writes over SMB including writes to existing files to go to a different directory?

Another option would be the ability to turn on previous versions so you could keep a set time to recover to a point-in-time on a file. A lot of ransomware uses mappings on systems to propogate, but when they start rewriting to start crawling then either SMB lockdowns or cron jobs to move files to a read only section of the file system would be an option. I'd really like to see previous versions enabled with the new features of btrfs even if it is newer than XFS.

I had ransomware on a laptop which blows but it could have jumped to UnRAID if I was connected so I am liking this Feature Request for more protection.

How I currently handle this:

Main server contains write shares.

Documents -  write many times (multiple  write mappings)

Media -  write once (single write mapping,  rest read only)

 

Backup server has no write shares,  read only with no export.

Shares passed to VM (will eventually move to an unassigned devices mount)

Documents rysnc all and send to crashplan for timestamp recoveries

Media rsync new files only

 

 

I'd also like to see a global Force Read Only control which would override individual share settings.  The obvious place for this would be with  the Global Share Settings  controls.  However, for the sake of keeping life simple for the majority of users I would prefer that this control was not tied to the spin-up function or anything else.   

 

For me the main reason for supporting this request would be for taking backups.  I prefer to backup when there is no possibility of files being open for writing or being modified.  I also prefer everything to be read-only if I later need to compare the backup with files on the server.  It would be much easier to manage this via a single override control than by using the settings for each of a large number of shares.  

 

 

 

Edited May 20, 20179 yr by S80_UK