39 minutes ago, TechDevil84 said:

Thank you gacpac and dlandon for your detailed explanations and I hope that other users can also benefit from it.
Now I understand better how the docker "Recycle Bin" works.

yeah i stumbled upon that couple days ago and did couple tests before even posting here lol. Although, it would be a nice feature in the future if it's worth developing. 

 

4 hours ago, gacpac said:

yeah i stumbled upon that couple days ago and did couple tests before even posting here lol. Although, it would be a nice feature in the future if it's worth developing. 

It's not a develoment issue.  Samba shares are configured by Unraid and the recycle bin plugin depends on Unraid to set up and manage the shares.

On 7/9/2020 at 7:41 PM, gacpac said:

yeah i stumbled upon that couple days ago and did couple tests before even posting here lol. Although, it would be a nice feature in the future if it's worth developing. 

 

You can have workaround for this by making share in gui where you collect just shortcuts of those shares you want to use and recycle bin will work on them by that route.

You can have workaround for this by making share in gui where you collect just shortcuts of those shares you want to use and recycle bin will work on them by that route.

How do I do that [emoji4]?

Sent from my Pixel 2 XL using Tapatalk

4 hours ago, gacpac said:

How do I do that ?

Sent from my Pixel 2 XL using Tapatalk
 

What is your client OS?

What is your client OS?

Windows 10 and unraid 6.8.3?

Sent from my Pixel 2 XL using Tapatalk

1 hour ago, gacpac said:

Windows 10 and unraid 6.8.3?

Sent from my Pixel 2 XL using Tapatalk
 

Just make new share in unraid and connect to it on your pc. Open it and add new shortcuts to your shares \\server\share

31 minutes ago, twiikker said:

Just make new share in unraid and connect to it on your pc. Open it and add new shortcuts to your shares \\server\share

Ohh I get what you are saying. That's pretty clever now that I think about it, might use it with some people at my company. 

GREAT IDEA!!

 

I have been testing a bit and it seems that setting the .Recycle.Bin folder owner/group to root and permissions to 0700 blocks smb users from deleting/accessing it. This works great for me but I'm thinking unraid or even the plugin might change it at some point. Will unraid/the plugin respect the permissions I set for .Recycle.Bin?

5 hours ago, danielocdh said:

I have been testing a bit and it seems that setting the .Recycle.Bin folder owner/group to root and permissions to 0700 blocks smb users from deleting/accessing it. This works great for me but I'm thinking unraid or even the plugin might change it at some point. Will unraid/the plugin respect the permissions I set for .Recycle.Bin?

The owner/group permissions for the .Recycle.Bin folder are the share user permissions.  If a user has access to the share, they have acces to the .Recycle.Bin.  You shouldn't change the .Recycle.Bin owner/group and permissions.

 

What is it you are trying to accomplish?

10 hours ago, dlandon said:

The owner/group permissions for the .Recycle.Bin folder are the share user permissions.  If a user has access to the share, they have acces to the .Recycle.Bin.  You shouldn't change the .Recycle.Bin owner/group and permissions.

 

What is it you are trying to accomplish?

Prevent smb users from deleting .Recycle.Bin while allowing the plugin to still work(I assume I'll have to keep testing but seems to work so far).

 

I was wondering/looking for confirmation about the plugin or unraid changing the permissions I set manually. I did some more testing with unraid changing the share security setting, export setting and users with access and it seems my manually set permissions weren't changed

Hi, 

 

I'm having an issue where files are not getting removed on schedule. Maybe I'm not impatient who knows. Has someone encountered an issue similar to this? I deleted the file on the July 13 and today is July 24

 

So I have an unassigned device that has some files with extremely long file names, long enough that path + filename can exceed the 255 character limit that most windows programs can deal with. I use a workaround where i create virtual shares(?) in smb-extra.conf that point to subdirectories several layers deep with a single character label. Example:

 

[Q]
  path = /mnt/disks/Extra/Sync/Queue/Incoming/
  browseable = yes
  public = yes
  writeable = yes

In this case, "Extra" is the unassigned device, and "Q" is the resulting share that points to the path above. Doing this keeps path + filename under 255 characters, solving my issue.

 

What I just discovered however is that if I delete a file while browsing the "Q" share, it does not end up in the recycle bin. But if i delete a file in the same folder while using the full path starting at "Extra", it does get put into the recycle bin.

 

Is there a way for me to config this so that it recycles the files when I am browsing via this shortened virtual share?

Edited August 7, 20205 yr by smashingtool
username...

On 8/7/2020 at 8:14 AM, smashingtool said:

So I have an unassigned device that has some files with extremely long file names, long enough that path + filename can exceed the 255 character limit that most windows programs can deal with. I use a workaround where i create virtual shares(?) in smb-extra.conf that point to subdirectories several layers deep with a single character label. Example:

 

[Q]
  path = /mnt/disks/Extra/Sync/Queue/Incoming/
  browseable = yes
  public = yes
  writeable = yes

In this case, "Extra" is the unassigned device, and "Q" is the resulting share that points to the path above. Doing this keeps path + filename under 255 characters, solving my issue.

 

What I just discovered however is that if I delete a file while browsing the "Q" share, it does not end up in the recycle bin. But if i delete a file in the same folder while using the full path starting at "Extra", it does get put into the recycle bin.

 

Is there a way for me to config this so that it recycles the files when I am browsing via this shortened virtual share?

I'm having a very similar problem.

 

I used the tip from the spaceinvader video for setting up what he calls a "root share" - greatly reducing the time to transfer files between shares.

 

This involves modifying the SMB settings to include the following:

[rootshare]
path = /mnt/user
comment =
browseable = yes
valid users = username
write list = username
vfs objects =

 

However, when I delete files from anywhere within the "root share", they don't end up in the recycle bin.   Deletes via the regular share works fine - everything ends up in the recycle bin.

 

There is a line in the recycle bin help for setting parameters:

Quote

%P' User share full path, eg /mnt/user/Storage, /mnt/disk1, /mnt/disks/unassigned_device, /flash

 

Would setting this parameter fix the issue?

Edited August 20, 20205 yr by yyc321

No. That is a replacement variable used by Samba itself. It is not meant for you to set.

I think there may be a bug in the remove function (vfs_recycle_remove) in the script file /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin.

 

The 'find' command is used to list all files and directories that have been in the recycle bin longer than the configured number of days (by checking the 'last accessed time' which is set when an item is moved to the recycle bin). Each resulting file and directory is then passed to 'rm -rf' to permanently delete it. The trouble is that when a file is deleted from a directory that already exists in the recycle bin from a previous deletion from that directory, the directory does not have its 'last access time' updated. This means that the 'find' command can list a directory that has been in the recycle bin longer than the configured number of days even if it contains a file that has not been there for as long. The 'rm' command with the '-r' switch then removes such directories, including any contents that have not been in the recycle bin long enough. It seems to me that since the 'find' command is recursing into directories then the 'rm' need not do this as well. However, just removing the '-r' switch will leave empty directories behind, but replacing it with '-d' (to allow 'rm' to remove empty directories) seems to work.

 

Perhaps the author could let me know if they agree with my analysis or if I've got something wrong.

 

I was prompted to investigate this because I'm getting files being removed from my recycle bins before they have been in there long enough.

 

Note that I'm also not currently getting a log of the files that are being deleted even though I have enabled that option and have seen them in the past, possibly with an earlier version of Recycle Bin. The script file doesn't seem to have a version within it, but unRAID shows the plugin as a whole as up-to-date at version 

2020.07.08c.

First off, thank you for this great plugin! I'd like to suggest a feature. Not sure if this would be possible to do, but figure it would be worth throwing it out there.

 

On Carbon Copy Cloner (CCC) for Mac, it has a feature called Safety Net. Basically, the backups that program does are differential and then it throws all the deleted/removed files into a SafetyNet folder, similar to this Recycle Bin plugin. On CCC you can set the max size of the SafetyNet. Once it reaches the max size, it will automatically delete the oldest files that were copied to the SafetyNet until it has enough room for the new files.

 

It would be great if Recycle Bin could delete old files like that. Clearing the Recycle Bin on a schedule is nice, but from my understanding that would just get rid of everything. It would be nice to have the option to always keep files in the Recycle Bin while only deleting what's necessary to make space for newly deleted files.

On 9/9/2020 at 8:20 AM, -Q- said:

I think there may be a bug in the remove function (vfs_recycle_remove) in the script file /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin.

 

The 'find' command is used to list all files and directories that have been in the recycle bin longer than the configured number of days (by checking the 'last accessed time' which is set when an item is moved to the recycle bin). Each resulting file and directory is then passed to 'rm -rf' to permanently delete it. The trouble is that when a file is deleted from a directory that already exists in the recycle bin from a previous deletion from that directory, the directory does not have its 'last access time' updated. This means that the 'find' command can list a directory that has been in the recycle bin longer than the configured number of days even if it contains a file that has not been there for as long. The 'rm' command with the '-r' switch then removes such directories, including any contents that have not been in the recycle bin long enough. It seems to me that since the 'find' command is recursing into directories then the 'rm' need not do this as well. However, just removing the '-r' switch will leave empty directories behind, but replacing it with '-d' (to allow 'rm' to remove empty directories) seems to work.

 

Perhaps the author could let me know if they agree with my analysis or if I've got something wrong.

 

I was prompted to investigate this because I'm getting files being removed from my recycle bins before they have been in there long enough.

 

Note that I'm also not currently getting a log of the files that are being deleted even though I have enabled that option and have seen them in the past, possibly with an earlier version of Recycle Bin. The script file doesn't seem to have a version within it, but unRAID shows the plugin as a whole as up-to-date at version 

2020.07.08c.

I'm looking into the -d parameter.  As for the log, click on the clear log and see If that helps.  The log may be too large because a lot of samba stuff gets logged. 

I do like the recycle plugin but i got 1 thing where it does not get into the recycle bin. Might be a setting.

 

But here it is.

 

my work station OS is ubuntu and if i remove a file there from a share it gets nicely put in the Bin and i can see it retrieve it etc.

 

Now i have on unraid a ubuntu VM. In that ubuntu VM i have made a  " Unraid Mount tag: " and i added that in the VM so the VM sees that directory as 1 of its own directory so i have direct access on that share inside the VM.

https://wiki.qemu.org/Documentation/9psetup

 

 

Now if i remove a file in the VM on that share its just gone.

Is this a setting i can set or anything?

 

 

Edited September 11, 20205 yr by KoNeko
spellings

1 hour ago, KoNeko said:

Now if i remove a file in the VM on that share its just gone.

Is this a setting i can set or anything?

Recycle Bin relies on a feature of SMB, so unless you delete a file with network SMB protocol, Recycle Bin doesn't know about it.

3 hours ago, trurl said:

Recycle Bin relies on a feature of SMB, so unless you delete a file with network SMB protocol, Recycle Bin doesn't know about it.

Exactly - so rather than pass the share into the VM via QEMU, just log in to the VM and map to the share from there exactly as if it was a physical machine elsewhere on the network. Also, as others have mentioned, I've found that if you just create a file and then immediately delete it, the recycle bin doesn't catch it. I'm not sure how long it has to be there, but I think someone said about 20 minutes earlier in this thread.

On 9/10/2020 at 6:14 PM, dlandon said:

I'm looking into the -d parameter.  As for the log, click on the clear log and see If that helps.  The log may be too large because a lot of samba stuff gets logged. 

 

I've just noticed that you've released a new version of the plugin with the addition of the -d switch as I mentioned above, so thanks for your effort here.

 

However, you've left in place the -r switch, which means the addition of the -d switch has no effect. Perhaps you could explain if you intended this or if it is perhaps a typo?

 

By the way, my logging problem went away while I was investigating it - to start with there were no samba audit messages being logged and then they started again after stopping and starting the array I think. So I'll keep an eye on it and see if anything gives itself away later.

7 hours ago, -Q- said:

However, you've left in place the -r switch, which means the addition of the -d switch has no effect. Perhaps you could explain if you intended this or if it is perhaps a typo?

I did this on purpose.  I don't think the -d switch does anything for the recycle bin, but I see no harm in it.

 

I don't see any documentation that says that the -d switch has no effect with the -r switch on.

11 hours ago, dlandon said:

I did this on purpose.  I don't think the -d switch does anything for the recycle bin, but I see no harm in it.

 

I don't see any documentation that says that the -d switch has no effect with the -r switch on.

Sorry to labour my point then, but there's still quite a bad bug in the plugin.

 

Using rm with only -r will remove any directory passed to it whether it is empty or not. Using rm with only -d will only remove a directory passed to it if it is empty. So using both together means -r will just remove all directories and -d will never get the chance to check whether any are empty or not. It's not like -d will stop -r removing a directory if it's not empty.

 

I confirmed this by entering the following in the unRAID terminal window:

root@Tower:~# mkdir test
root@Tower:~# ls > test/a.txt
root@Tower:~# rm test
rm: cannot remove 'test': Is a directory
root@Tower:~# rm -d test
rm: cannot remove 'test': Directory not empty
root@Tower:~# rm -rd test
root@Tower:~# 

See how the final command which uses -rd just removes the directory even though it still contains a.txt.

 

Aside from how -d and -r work together though, the actual bug is caused by using -r.

 

I guess the key point to realise is that if there is a directory in the Recycle Bin, it can be there for one of two reasons: 1) it's a directory that got deleted; 2) it's a directory that got created in the bin just to hold something else that got deleted in order to preserve the path to the deleted item(s). The first case implies it can be deleted once it expires because its content will age with it, but the second case means it has to stay around until its purpose of holding other files and directories is complete, which just happens to be nicely indicated when it becomes empty. So all that's needed is to use -d without -r.

 

Note that these 'extra old' directories won't get removed during the same run that they become empty due to the order that the 'find' command returns items i.e. parent directories before contents. But they will get removed on the run following the one when they become empty. For a tree 5 levels deep though, it will take 5 runs to remove (or thereabouts depending on what you count as the first level). I think it's good enough to just leave this slight bug in place, but you could pipe the output of 'find' into 'tac' to reverse it and then into 'xargs' to run the 'rm' command since you wouldn't then be able to use the '-exec' switch of 'find'. Like I said though, only needed if you're a perfectionist!

Maybe I'm missing something, but I don't see what rm has to do with this plugin. Recycle Bin only works with files deleted over the network with SMB.