[Samba] confirm deletion - possible?

[Peter Milesson]

On 2021-01-19 11:51, Stefan G. Weichinger via samba wrote:
> Am 19.01.21 um 11:38 schrieb Andrew Walker:
>>
>>
>> On Tue, Jan 19, 2021 at 4:23 AM Stefan G. Weichinger via samba 
>> <samba at lists.samba.org <mailto:samba at lists.samba.org>> wrote:
>>
>>
>>
>>     Is it possible and configurable to ask something "are you sure? 
>> y/n" if
>>     a user wants to delete a file/folder on a samba share?
>>
>> Speaking in broad terms, you're up to the mercy of the OS / 
>> application developer for the SMB client (or however you're accessing 
>> the SMB share) to do this.
>
> The client is a strange piece of software called "MS Windows 10" ;-)
>
>>     Is that possible by using Windows ACLs or ... ?
>>
>> Not really possible via ACLs (but I haven't had coffee yet). ACLs 
>> just define what a user can do with a file. They don't prompt for 
>> confirmation. For example, you can possibly set permissions in a way 
>> to create a write-only dropbox for files.
>
> In this case we think of only allowing 2 of the ~10 users to modify 
> the top folder structure via ACLs. So something like a group "power 
> users" that is allowed more ... and others are only allowed to modify 
> stuff below and inside these folders.
>
> I have to add that I run vfs "full_audit" there: these logs help to 
> see who messed up what and when.
>
>> Some thoughts:
>> vfs_recycle allows you to basically configure a hidden directory at 
>> the root of your share that acts as a recycle bin. If users delete a 
>> file, it gets moved there. One significant caveat is that if you have 
>> for some reason mounted a filesystem within your SMB share and delete 
>> a file from it, the deleted file will _not_ appear in the recycle 
>> bin. This one should probably be at the end of your list of "vfs 
>> objects" if you choose to use it.
>>
>> vfs_worm allows you to configure a "grace period" in which files in a 
>> share are writable. Once the time difference between the file's ctime 
>> and the current time exceeds the amount set as the share's grace 
>> period, the file becomes read-only. This is useful if you have a 
>> share that's rarely edited after initial upload. An example of this 
>> is a repository for digitized images of legal documents. Once they're 
>> uploaded, there's little reason for a user to be able to move around, 
>> edit, delete, etc.
>>
>> vfs_shadow_copy2 allows you to present filesystem snapshots as 
>> "previous versions" in windows. If the filesystem on which the share 
>> resides supports some lightweight snapshotting mechanism (like ZFS), 
>> then you can set a cronjob to snapshot the FS at periodic intervals 
>> and basically have "unbreaking things" become self-service for end 
>> users. Okay... that's probably too optimistic, but it will make 
>> recovery somewhat easier for the admin.
>
> Thanks for the information, I haven't checked the various vfs modules 
> lately and some of them might help here. Got to think about it.
>
Hi Stefan,

It's really strange that you don't get a confirmation dialog from 
Windows 10. I have got an ancient stand alone Samba server ver. 4.0.9, 
kernel 3.11.0, OS Slackware 14.0. It's really ancient stuff. I use it 
frequently from Windows 10 (20H2), and Windows always asks if I want to 
delete the file permanently. Mounting a share on the box from Linux, I 
will get the confirmation question if the OS is setup in that way 
(CentOS default). Other Linuxes just delete the files without further 
nagging. Total Commander in Android also asks politely. So it's a client 
thing.

As was suggested previously, using some kind of network recycle bin may 
be a good idea to protect files from disappearing permanently (also keep 
good backups, if the files may be valuable).

My five cents...

Best regards,

Peter