Dermot Paikkos wrote: > One of the other things I was hoping to do was deny users from renaming > the folder or the other classic mistake, accidently drag and drop a > folder into another folder. Create, move, rename and delete are determined by the permissions on the containing directory. It isn't possible to set different restrictions for different files or subdirectories within a given directory, nor allow creation but forbid deletion. The only exception is that if the directory has the sticky bit set (chmod +t), users cannot move, rename or delete a file or subdirectory which they do not own. If the user owns the directory, they can clear this flag, but that may not be an issue if you're simply trying to prevent accidents rather than deliberate acts. However, it may prove problematic if there are plausible scenarios in which files owned by another user can end up in the directory, as you can end up with files which can only be removed by root. > I can't think of a set of UNIX permission or smb.conf directives that is > going to allow make a directory readonly but allow a group to create > files within the directory. Creating files within a directory directly contradicts the notion of "read only". You can get slightly more flexibility if you use POSIX ACLs rather than the historical ugo/rwx permission model. You're still limited to read/write/execute permission, but you can assign permissions to multiple named users and to multiple named groups. Also, Samba has a variety of configuration options which allow the Unix permission model to be bypassed. E.g. the "dos filemode" option allows any user with write permission on a file or directory to change the permissions and/or owner. -- Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-admin" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
