As my server grows, I'm becoming increasingly concerned with the fact that -I- am the biggest danger in this equation.  After all, it wouldn't take much to accidentally delete a gigantic amount of data...one worm...one virus...one act of carelessness.

 

Is there a relatively straightforward/elegant way to add a layer of protection between ME and my server- something that will still allow me to copy to/from but add some extra safeguards to existing data...to prevent any sort of mass deletion/alteration without at least asking me if I'm sure or maybe asking for some sort of password? 

 

Preferably, I'd like to be able to PLAY/READ anything from the server, but be prompted or restricted in some way when it comes to CREATING/CHANGING/DELETING.....  I use ATV2's/XBMC so passwording every action wouldn't fly.  Sabnzbd/Sickbeard run on my server....it's just the rest of my network that I want to protect my server from...

All depends hugely on your day to day usage. But the most obvious thing would be to export your shares (samba, nfs etc) as read only everywhere.

 

You could use a separate user for write actions forcing you to consciously switch / remap a drive as that user before you make updates. Tedious but..

 

You could also look at setting all your shares as read only except the cache drive share and use the cache share exclusively for writes. This wouldn't help much with updating existing data  but would likely work for new data. You can still write it in nicely, it would appear (with user shares) in the 'correct' location whilst denying you access to everything else not in the cache drive and at your chosen migration time would be moved securely off onto the data drives becoming 'read only'.

 

Your other answer is backups. At which point sweeping user error matters a *little* less and provides a nice safety net.

 

See if this thread helps (assuming you are using SAMBA anyway).

 

http://lime-technology.com/forum/index.php?topic=5446.0

well one sure way is to lock it up in a safe a throwaway the key :-D

 

but in all seriousness, since you are the ADMIN you just need  to be careful.

all I can think off is

#1. setup 2 new users on the server

      1.1 - THE ROOT (it is already there and setup, just add the password so no accidental access is possible )

                    use it for flash updates and other system maintenance which require full access.

 

      1.2 - Active(share)Admin (as in have basic root access, limited to shares edit only) so you can use that for copy files onto shares. give this user access to shares only.

 

        1.3  MediaUser read-only access to shares. use this for all of your consumption devices and to do a read-only mounts as shared drives and such. it does not even need password as it is a read-only but I would give it one just in-case.

 

and you are done.

 

you can even add one more admin user for deletion of stuff

this way you would use ActiveAdmin to add stuff and DeleteAdmin to remove stuff.

but this is major paranoia speaking, as in tinfoil heats and such  :-P

 

 

 

That's what backups are for 

(among other things)

 

BACKUPS ARE FOR WIMPS 

 

You could also look at setting all your shares as read only except the cache drive share and use the cache share exclusively for writes.

Since all my additions should be going to the cache drive, would that allow me the appearance of copying TO my shares while simultaneously preventing DIRECT access to the existing share data?  Or would the system prevent me from copying to "movies" entirely? (even though the copy was destined to be redirected to the cache drive)

 

Your other answer is backups. At which point sweeping user error matters a *little* less and provides a nice safety net.

 

I have a backup of my data, but bigger backup = less frequent backup + more work to restore, and I'm a big believer in  1oz. prevention > 1lb. cure.

 

 

but in all seriousness, since you are the ADMIN you just need  to be careful.

all I can think off is

#1. setup 2 new users on the server

 

I am careful, but bad things also happen to careful people.  This [does] sound like a logical solution.  Would this affect my sabnzbd/sickbeard processes living on the server?  I seem to recall something about their being run as user 'nobody'  (along with much headache in getting the combo running together well)

You may want to review this thread:  http://www.lime-technology.com/forum/?topic=5446.0

 

It shows how to enable a Recycle Bin for UnRAID ==> won't keep you from deleting something;  but will provide a way to restore it as long as you realize you did it before it cycles out of the Recycle Bin.

 

You could also look at setting all your shares as read only except the cache drive share and use the cache share exclusively for writes.

Since all my additions should be going to the cache drive, would that allow me the appearance of copying TO my shares while simultaneously preventing DIRECT access to the existing share data?  Or would the system prevent me from copying to "movies" entirely? (even though the copy was destined to be redirected to the cache drive)

 

My head hurts

 

I think the answer is yes. You can treat the cache share as it's own entitity. So long as data lands on it in the correct 'structure' unraid treats it no differently than if you copied a file to the cache via a user share. Which I think is what you're asking.

 

So set all your user shares / data shares to read only (or read only for your normal user) and only allow writes to the cache drive share.

 

I've not actually tested the above to see if it works either..it seems it should in principle but I could be talking nonsense. That happens a lot.

I don't think the cache share concept really fixes this, as you need to be able to update your actual shares to add new content.

 

Perhaps the safest thing is to have a "normal" account you use that is read/only -- and a separate account you can use that has write privileges ==> then you just have to be aware when you're using the 2nd account (to add or modify content) and be a bit more careful.    But if you also add a Recycle Bin that will provide an additional layer of protection => and if you also keep your backups fairly current that's yet-another layer.    Hopefully with 3 layers of protection you won't get yourself in trouble  8)

I don't think the cache share concept really fixes this, as you need to be able to update your actual shares to add new content.

 

Surely if you place data into /mnt/cache/Film/film.txt it will appear in your /mnt/user/Film user share? (this works, just tested)

 

Therefore clients access, read only, /mnt/user/Film as a user share. But you only ever write to the cache drive share in isolation. Data in there appears under the user share and then is moved onto the data disks proper - at which point clients can only access it read only. I'm less sure about this bit, but given you can set discrete permissions on the user share *and* on the cache disk share I don't see why it wouldn't work. Your window of 'disaster' from clients can only affect data on the cach drive which is, presumably, a tiny subsection of your data at any given time.

 

Only caveat is you need to reflect the structure of your user shares on disk on the cache share. But that's as normal.