Having kids, I'm always worried that I'll leave my mapped shares open and they'll be there to mistakenly delete files from unRAID. I think it would be helpful that whenever a deletion is done that a password is needed to approve the deletion. The deletion prompt would come up whether it was for 1 file or several at one time. I don't know if there is another way to do this already through Windows, but it seems it wouldn't be too difficult to implement on unRAID. Please share thoughts on this or an alternate method.

Just deletes?  How about overwrites?  How about renames?

 

The answers don't really matter.  There is no way (at least none that I am remotely aware of) that provide a password protection on file access.

 

You can use security to limit access to read-only for certain userids.  But if a user has write permissions, they will be able to delete files.  By providing your kids with read-only access, and then requiring a login under a different userid for write access, you can prevent the accidental deletions you are concerned about.

Just deletes?  How about overwrites?  How about renames?

 

The answers don't really matter.  There is no way (at least none that I am remotely aware of) that provide a password protection on file access.

 

You can use security to limit access to read-only for certain userids.  But if a user has write permissions, they will be able to delete files.  By providing your kids with read-only access, and then requiring a login under a different userid for write access, you can prevent the accidental deletions you are concerned about.

I agree, the best way is to have a different user-id to play the files vs. manage/create them.  Or, you can export the disk shares as hidden, but read/write.  Then you can get to them if you know they are there to create, add, delete, modify as \\tower\disk1, \\disk2, etc. (They di not show up in the network neighborhood)

 

The kids can see and interact with the visible \\tower\Movies, \\tower\Music, etc that are read-only.

 

Complicating things is that unix permissions on files and directories are very different than Windows permissions... Samba tries to map the one set of permissions to the other set, and does a fair job, but some things are just not possible. 

 

In Linux/unix you need "write" permission on a directory to either create a new file in it, or to delete a file in it.  You do not need any special permissions on the file itself since you are not changing the file contents, you are just changing the directory entry that points to the "information node" (inode) that points to the file contents.  In Unix/Linux, there is no separate "delete" permission for a file.  If you can delete it, you can rename it (again, you are not changing the file, but the directory entry that points to the inode.)

 

In the same way, if you do NOT have permission to write to the directory you can still truncate the data in a file in that directory if you have write permission to the file.  You can even replace its contents with anything you like.  Think of it as two sets of permissions... one for the file contents, the other for the directory entries pointing to the contents.  (In a old-fashioned library it would be equivalent to permission to read or write a book, vs permission to read or write to the card-catalog that lets you quickly find the book.)  Now... SAMBA tries to map these to windows equivalents... it is not that easy...

 

Joe L.

Well, I guess I'll just have to be sure I lock them out of that system or create different accounts. Thanks for the responses. It was really just one of those thoughts I've had for a while and new it wasn't possible in windows but wasn't sure about Linux with my lack of knowledge. Thanks again.