Linux dropfolder where users can't delete files

I am working on a file server project for school and I am using samba to share the folders. I have been playing around with the folder permissions but I can't seem to figure out how to make a drop only like folder. This is what I want to achieve:

  • Owner (server account): Full control (chmod number 7xx)
  • Group (users that sign in to the samba server) : Only place (drop) files,so this means don't open/edit/delete files in the folder (chmod number x?x)
  • others : no access (chmod number xx0)

I have tried a lot of different chmod settings but never achieved the wanted result. Is this even possible? I googled a lot but couldn't really find a concluding answer.

Maybe a way to set permissions on files whenever they are placed in the folder?

If you need more information about the samba configuration or anything else please ask!

Thank you for helping out!


Solution 1:

Try this procedure.

Create shared folder and give right permission:

  mkdir /pathYouWant/share
  chmod 770 /pathYouWant/share

This gives no access to other.

  chmod +t /pathYouWant/share

This mode, according to chmod manual page:

   The  restricted  deletion  flag  or  sticky  bit is a single bit, whose
   interpretation depends on the file type.  For directories, it  prevents
   unprivileged  users  from  removing or renaming a file in the directory
   unless they  own  the  file  or  the  directory

As told by Marty Fried files created in the share folder should have the right permissions and this can be achieved with samba share masks in smb.conf:

  create mask = 440
  directory mask = 550

Windows programs shouldn't try to remove read-only files unless delete readonly option is set to yes.

  delete readonly = no

Also if you want to hide all file in share folder:

  veto files = /*/
  delete veto files = no

According to samba manual these directive:

What happens if the user tries to delete a directory that contains vetoed files? This is where the delete veto files option comes in. If this Boolean option is set to yes, the user can delete both the regular files and the vetoed files in the directory, and the directory itself is removed. If the option is set to no, the user cannot delete the vetoed files, and consequently the directory is not deleted either. From the user's perspective, the directory appears empty, but cannot be removed.

After this configuration, the only problem left is that user can still delete his/her own files even if he/she do not see it (It is unclear to us why).

So we decide to follow the_Seppi suggestion to complete the task and Bram Driesen did a script that changes file ownership to the host pc.

He used incron to fire the script whenever a file is placed in the folder, following this as guide to set it up.

Solution 2:

Unfortunately, your problem is not solvable so easily. If a user has write permission in a directory, he can also delete files. Even if he wasn't able to delete them, he could still fill a file with zeros, which would be a deletion of data, but not of the filesystem node.


An idea which I once used:

You create a cronjob, which recusively removes the write permission of every file in a directory tree (like every file in /home/guest).

Note that you can't simply use chmod g-w -R /home/guest. This would take the write bit off the directories too, making it impossible to place new files there. So you'd need to iterate over every file and remove it's group write bit.

The interval of the cronjob execution is up to you - back then I set it to 10 minutes. I don't know your environment, so I can't give you a recommendation.

Unfortunately I don't have this script any more, so you'll have to do some bash scripting to get it to work. But seriously, I doubt that this is an efficient method.