"Export Recycle Bin" setting doesn't work for mapped drives, only UNC

[JayG30]

Hello,

I was testing enabling the Export Recycle Bin setting on an SMB share and found something interesting that I'm not sure if is working by design or perhaps a bug. I'm hoping some other members might be able to confirm. I suspect this is a limitation of the Samba vfs_recycle module.

I map an SMB share in Windows 10. A user accesses that share, create a file, and then deletes it. The hidden .recycle folder is NOT created and the deleted file is not moved to the recycling bin.

If they do the same thing but access the share via UNC path (\\[server]\[sharename]) then the .recycle folder IS created and the deleted file is moved to it.

I map network shares for users during login so this would be a problem.

Thanks

PS: Also, I have a share called "Home" which is where all users personal home folders are automatically generated (via AD). When you have 100's of users it isn't really feasible to have individual "shares" for everyone. There doesn't appear to be any way to get each user their own accessible .recycle folder since vfs_recycle generates it at the "root" of the "share". I don't think there is any solution to this but figured I'd ask just in case someone does now.

 

[anodos]

Hello,

I was testing enabling the Export Recycle Bin setting on an SMB share and found something interesting that I'm not sure if is working by design or perhaps a bug. I'm hoping some other members might be able to confirm. I suspect this is a limitation of the Samba vfs_recycle module.

I map an SMB share in Windows 10. A user accesses that share, create a file, and then deletes it. The hidden .recycle folder is NOT created and the deleted file is not moved to the recycling bin.

If they do the same thing but access the share via UNC path (\\[server]\[sharename]) then the .recycle folder IS created and the deleted file is moved to it.

I map network shares for users during login so this would be a problem.

Thanks

PS: Also, I have a share called "Home" which is where all users personal home folders are automatically generated (via AD). When you have 100's of users it isn't really feasible to have individual "shares" for everyone. There doesn't appear to be any way to get each user their own accessible .recycle folder since vfs_recycle generates it at the "root" of the "share". I don't think there is any solution to this but figured I'd ask just in case someone does now.

Wow. That's a fascinating problem. I'll look into it, I think there is an bug report related to vfs_recycle that I haven't been able to reproduce. Have you tried this with other OSes / samba servers? It might be worth posting to the samba mailing list.

 

[anodos]

Can you review contents of /var/log/samba4/log.smbd for entries such as "recycle: mkdir failed for %s with error: %s\n"? If nothing shows up, isolate the server, increase logging level to 'debug', reproduce the problem, then post log.smbd here.

 

[anodos]

Hello,

I was testing enabling the Export Recycle Bin setting on an SMB share and found something interesting that I'm not sure if is working by design or perhaps a bug. I'm hoping some other members might be able to confirm. I suspect this is a limitation of the Samba vfs_recycle module.

I map an SMB share in Windows 10. A user accesses that share, create a file, and then deletes it. The hidden .recycle folder is NOT created and the deleted file is not moved to the recycling bin.

If they do the same thing but access the share via UNC path (\\[server]\[sharename]) then the .recycle folder IS created and the deleted file is moved to it.

I map network shares for users during login so this would be a problem.

Thanks

PS: Also, I have a share called "Home" which is where all users personal home folders are automatically generated (via AD). When you have 100's of users it isn't really feasible to have individual "shares" for everyone. There doesn't appear to be any way to get each user their own accessible .recycle folder since vfs_recycle generates it at the "root" of the "share". I don't think there is any solution to this but figured I'd ask just in case someone does now.

I just tried this with FreeNAS 9.10.2-U4 and a Windows 10 client. The recycle bin is generated (1) when accessed via UNC path and (2) when accessed via mapped network drive.

Some possibilities regarding what is going on:

1. smb.conf changes aren't propagated to clients until a new session is established. Try restarting samba and seeing if the behavior persists.
2. I think I've seen this problem before with 'Unix' permissions on datasets. Are you using Unix permissions?

 

[JayG30]

Can you review contents of /var/log/samba4/log.smbd for entries such as "recycle: mkdir failed for %s with error: %s\n"? If nothing shows up, isolate the server, increase logging level to 'debug', reproduce the problem, then post log.smbd here.

Only thing I see in the log related to recycle are these lines;

[root@freenas] ~# grep recycle /var/log/samba4/log.smbd
[2017/06/08 15:13:14.441737, 1] ../source3/modules/vfs_recycle.c:297(recycle_create_dir)
recycle: mkdir failed for .recycle with error: File exists
[2017/06/08 15:18:40.244213, 1] ../source3/modules/vfs_recycle.c:297(recycle_create_dir)
recycle: mkdir failed for .recycle with error: File exists
[2017/06/08 15:18:49.599410, 1] ../source3/modules/vfs_recycle.c:297(recycle_create_dir)
recycle: mkdir failed for .recycle with error: File exists
[2017/06/08 16:26:55.814309, 1] ../source3/modules/vfs_recycle.c:297(recycle_create_dir)
recycle: mkdir failed for .recycle with error: File exists


 

[JayG30]

I just tried this with FreeNAS 9.10.2-U4 and a Windows 10 client. The recycle bin is generated (1) when accessed via UNC path and (2) when accessed via mapped network drive.

Some possibilities regarding what is going on:

1. smb.conf changes aren't propagated to clients until a new session is established. Try restarting samba and seeing if the behavior persists.
2. I think I've seen this problem before with 'Unix' permissions on datasets. Are you using Unix permissions?

No to the unix permissions on the dataset. Permission type is Windows and all permissions are handled through Windows. This is in an Active Directory environment.

Perhaps I should restart my desktop PC and see what happens when it remaps the drives.

 

[JayG30]

I think I figured out the issue. The mapped drive is actually to a parent folder that other shares reside in. I did this because it was to distracting for some users to need to have 10 mapped network drives.

If I map the share (which is a subfolder of that parent folder that is also a share) I get the recycle bin to work. What is strange though is why it isn't creating a .recycle in that parent folder instead when I do this.

Edit: I'm stupid. I don't have the setting on for THAT share, lol.