Recycle Bin (vfs recycle) for SMB Shares


dlandon

Recommended Posts

Hello @dlandon

here are a couple annotated screenshots...I am troubleshooting thor right now as i cannot mount anything from 6.7.0rc2 onto 6.6.6

 

Freya has only one share not for system use thats a share named 4K

Thor has a few shares but the one i mount on Thor is Freya_Media (maps to /mnt/user/4K on Freya)

Freya has a mount of THOR_Media (mapped to /mnt/user/Media on Thor)

 

freya withThor mounted.png

freya without thor mounted.png

Link to comment
2 hours ago, Can0nfan said:

Hello @dlandon

here are a couple annotated screenshots...I am troubleshooting thor right now as i cannot mount anything from 6.7.0rc2 onto 6.6.6

 

Freya has only one share not for system use thats a share named 4K

Thor has a few shares but the one i mount on Thor is Freya_Media (maps to /mnt/user/4K on Freya)

Freya has a mount of THOR_Media (mapped to /mnt/user/Media on Thor)

 

freya withThor mounted.png

freya without thor mounted.png

I'm sorry, but this whole scheme is extremely confusing and screen shots with totals on the recycle bin tell me nothing about where the recycle bin files are located.  Let me share some things that may be helpful.

 

Let's look at your 4K share.  The original source of the 4K share (where it is mounted - Freya) will be the source of the recycle bin.  That share should be excluded from the recycle bin.  Right now it is not based on your screen shots.  Add 4K as an excluded share.  If it is a UD device it will be excluded by setting 'Enable on Unassigned Devices?' set to 'No'.  Now mount the share remotely through UD on Thor and Freya_Media.  The recycle bin on that share on Thor and Freya_Media will not apply on those two servers.  The 'Enable on Unassigned Devices?' set to 'Yes' does not apply to remote shares, only UD devices like disk drives.  i.e. the source mount of the share.

 

The best way to see the share recycle bin shares in on the shares tab.  You can see where the files are located.

Link to comment
3 minutes ago, dlandon said:

I'm sorry, but this whole scheme is extremely confusing and screen shots with totals on the recycle bin tell me nothing about where the recycle bin files are located.  Let me share some things that may be helpful.

 

Let's look at your 4K share.  The original source of the 4K share (where it is mounted - Freya) will be the source of the recycle bin.  That share should be excluded from the recycle bin.  Right now it is not based on your screen shots.  Add 4K as an excluded share.  If it is a UD device it will be excluded by setting 'Enable on Unassigned Devices?' set to 'No'.  Now mount the share remotely through UD on Thor and Freya_Media.  The recycle bin on that share on Thor and Freya_Media will not apply on those two servers.  The 'Enable on Unassigned Devices?' set to 'Yes' does not apply to remote shares, only UD devices like disk drives.  i.e. the source mount of the share.

 

The best way to see the share recycle bin shares in on the shares tab.  You can see where the files are located.

I am little confused. I do want the recycle bin for the 4K share on Freya and the Media share on Thor

the main thing im seeing is if i mount a Thor share on Freya i see that the main Recycle bin sees the totals of both recycle bins (the one on Media for Thor and the 4K one on Freya)

i found did the upgrade back to Thor for rc2 to be able to mount "remote" SMB shares let me grab some new screenshots and post

Link to comment

Ok this might make it easier to understand

Freya has the red banner and Thor has the Blue one to tell them apart

I have the main tab, shares tab and recycle bin settings for the two im mostly concered with (Sif is Green but not listed)
I see that the users tab in recycle bin shows only the bin for the server its being viewed on so my question is with the mounts i have on the main page is there a way to exclude Thor on Freya and Sif, Exclude Freya on Thor etc?

i have tried with:
partial share name
'full sharename' (as Unraid see it where its mounted to /mnt/disks/

freya main.png

thor main.png

freya shares.png

thor shares.png

freya recycle bin.png

thor recycle bin.png

Link to comment

 

10 minutes ago, Can0nfan said:

I am little confused. I do want the recycle bin for the 4K share on Freya and the Media share on Thor

You mentioned earlier that disabling the recycle bin didn't work as if you wanted it off.

 

11 minutes ago, Can0nfan said:

the main thing im seeing is if i mount a Thor share on Freya i see that the main Recycle bin sees the totals of both recycle bins (the one on Media for Thor and the 4K one on Freya)

That's correct.  The recycle bin is the total of all .Recyle.Bin folders on all shares.  When a recycle bin is enabled, it applies to deleting files at the original source mount (Freda) .  It has nothing to do with seeing the files already in the .Recycle.Bin folders.  Any other server that remote mounts the share will also see the files in the .Recycle.Bin folder.

 

Look at the 'Shares' tab of the recycle bin and you'll see the totals in the recycle bins of the individual shares.

Link to comment
1 minute ago, Can0nfan said:

maybe the recyle bin could have an option to exclude anything mounted to /mnt/disks/ (not to be confused with local array disks being stored on /mnt/disk#

That's the way it currently works.  Only physical devices are mounted at /mnt/disks/ and "Enable on Unassigned Devices?" enables/disables the recycle bin on the devices mounted at /mnt/disks/.  Remote shares are only configured for either SMB or NFS sharing and not locally mounted.

 

The share included or excluded from the recycle bin only applies to the original mount point because that is where the deleting of files is controlled.  It has nothing to do with remote mounted shares on a different server seeing the .Recycle.Bin files.

 

I'm not sure I see the point in all this.  What difference does it make if the share .Recycle.Bin files are shown in the remote recycle bin or not?

Link to comment

i guess my point is flexibility to exclude remotely mounted disks....UD assigns all mounted volumes to /mnt/disks not /mnt/disk<#>

an option to exclude that could simplify the interface and only show what on the the servers local recycle bin

i see the main icon at the top one does indeed kind of currently work as a one click solution where all is removed even on remotely mounted servers, where the shares tab below is more finely grained control of only deleting off the current server you are in the interface for.

i could adapt but i was initially confused when i deleted a 3MB file on one server and a 168MB on another why the first server is showing 172MB in the recycling bin??...then saw same amount on other server when i emptied on one both servers were cleared.  it makes for an easy ooopsie if you mean to check the recycle bin on one server but are ready to empty the other and the main empty button will empty all recycle bins if the remote shares are mounted 

Edited by Can0nfan
Link to comment
5 hours ago, Can0nfan said:

it makes for an easy ooopsie if you mean to check the recycle bin on one server but are ready to empty the other and the main empty button will empty all recycle bins if the remote shares are mounted 

I did find where the recycle bin was mis-handling UD devices when they were not enabled in the recycle bin.  For example if the "Enable on Unassigned Devices?" is set to 'No' and the shares have files in the .Recycle.Bin folder and the recycle bin was emptied, those files would be deleted.

 

When the "Enable on Unassigned Devices?" is set to 'No', the recycle bin will be disabled for that share and any files on those shares in the .Recycle.Bin folder will be left alone.  This applies to all UD devices and remote mounts.

 

This might be closer to what you are expecting of how the recycle bin should operate.

Link to comment
On 1/30/2019 at 11:26 AM, dlandon said:

I did find where the recycle bin was mis-handling UD devices when they were not enabled in the recycle bin.  For example if the "Enable on Unassigned Devices?" is set to 'No' and the shares have files in the .Recycle.Bin folder and the recycle bin was emptied, those files would be deleted.

 

When the "Enable on Unassigned Devices?" is set to 'No', the recycle bin will be disabled for that share and any files on those shares in the .Recycle.Bin folder will be left alone.  This applies to all UD devices and remote mounts.

 

This might be closer to what you are expecting of how the recycle bin should operate.

I do have that setting on No on all three servers as you can see in the screenshots (Green is Sif, Red is Freya, Blue is Thor). I do expect that if Enable on UD is set to no that the recycle bin only shows files stored on the server you are actively viewing, I also expect if i exclude a share name mounted by UD that it would also exclude looking at the recycle bin files in that share (mounted locally or remotely) just by its wording.

Screen Shot 2019-01-31 at 12.29.26 PM.png

Screen Shot 2019-01-31 at 12.29.36 PM.png

Screen Shot 2019-01-31 at 12.29.50 PM.png

Link to comment
8 hours ago, Can0nfan said:

I do expect that if Enable on UD is set to no that the recycle bin only shows files stored on the server you are actively viewing,

Yes.  UD device shares either locally mounted or remote mounted will not show.

 

8 hours ago, Can0nfan said:

I also expect if i exclude a share name mounted by UD that it would also exclude looking at the recycle bin files in that share (mounted locally or remotely) just by its wording.

No.  Excluding a share only excludes it on the local server.  Remote mounted shares are cannot be excluded because they are mounted on another server.

 

When shares are enabled on the recycle bin, the share is defined with the vfs_recycle that moves files to the .Recycle.Bin folder when they are deleted from the share.  This puts files in the recycle bin.  When a share is excluded from the recycle bin, no files are moved to the recycle bin when deleted.  The contents of the .Recycle.Bin folder on the share will still show in the recycle bin if there are files in that folder, even though no further files will be moved there.

 

To summarize:

- When the recycle bin is enabled on a share, it has to be a local device share and files will be moved to the .Recycle.Bin folder when deleted from the share.

- The recycle bin size and browsing shows devices with files in the share .Recycle.Bin folder, whether or not the recycle bin is enabled for that share.

- Remote mounted devices will show in the recycle bin size and browsing when their .Recycle.Bin folder has content.  The only way to turn this off is to not enable UD devices in the recycle bin.

- Only local device shares can be excluded from the recycle bin.

Link to comment
On 1/31/2019 at 11:08 PM, dlandon said:

- Remote mounted devices will show in the recycle bin size and browsing when their .Recycle.Bin folder has content.  The only way to turn this off is to not enable UD devices in the recycle bin.

No longer true.  I'm releasing a new version that will not show any remote mounted shares and the local recycle bin will not remove any files from the remote share recycle bins.  Only the local server will be able to manage the shares originating on that server.

 

Changes:

- The 'Shares' tab has been re-organized and you can click the table headers and sort the entries - for example the trash can sizes and share names.

- You can stop the recycle bin and still manage files in the .Recycle.Bin folders.

- Added additional help text.

- Only local mounted shares will be included in the recycle bin size calculations and file browsing.

- Empty and purge now only work with the shares that have the recycle bin enabled.  All other shares with .Recycle.Bin folders are left alone.

  • Like 1
Link to comment
On 2/2/2019 at 11:49 AM, dlandon said:

No longer true.  I'm releasing a new version that will not show any remote mounted shares and the local recycle bin will not remove any files from the remote share recycle bins.  Only the local server will be able to manage the shares originating on that server.

 

Changes:

- The 'Shares' tab has been re-organized and you can click the table headers and sort the entries - for example the trash can sizes and share names.

- You can stop the recycle bin and still manage files in the .Recycle.Bin folders.

- Added additional help text.

- Only local mounted shares will be included in the recycle bin size calculations and file browsing.

- Empty and purge now only work with the shares that have the recycle bin enabled.  All other shares with .Recycle.Bin folders are left alone.

Thanks for the update, works great but might have found a bug...

 

 

I had appdata, system and flash excluded with the commands 'appdata', 'system', 'flash'

the shares tab still shows it all and the main empty all trash button still clears all despite  the exclusion 

Screen Shot 2019-02-03 at 11.20.04 PM.png

Screen Shot 2019-02-03 at 11.20.17 PM.png

Link to comment
5 hours ago, Can0nfan said:

Thanks for the update, works great but might have found a bug...

 

 

I had appdata, system and flash excluded with the commands 'appdata', 'system', 'flash'

the shares tab still shows it all and the main empty all trash button still clears all despite  the exclusion 

Screen Shot 2019-02-03 at 11.20.04 PM.png

Screen Shot 2019-02-03 at 11.20.17 PM.png

Don't use quotes.  Should be appdata,system,flash not 'appdata','system','flash'.

  • Like 1
Link to comment

Aaaaargh !

 

Version 2019.02.03b has just erroneously deleted an entire share instead of a file.  Completely.  From all member disks in the array.

 

 

The details of what happened, while I try to stop myself panicking too hard ...

 

I have a an Unraid XFS array setup of 5 HDDs consisting of 2x parity and 3x data disks , plus a BTRFS cache of 2x mirrored SSDs.

The share in question was set to include all disks and use cache, with directories set to split as required - it contained ~2.5TB of data.

 

On a client Linux PC (via SMB) I deleted a file from within the share ... so far so normal.  It was pretty large (20GB or so) so I went to Unraid WebUI to empty it from Recycle Bin to regain the space on the SSD cache.

There was a notification in WebUI that an update was available to the Recycle Bin plugin, so I updated that (from 2019.01.31b to 2019.02.03b)

I then opened Recycle Bin plugin and emptied the 20GB file - I didn't do anything unusual, same procedure as I've done many times before.

 

However ... instead of just deleting /SHARENAME/.Recycle.Bin/SHARENAME/20GBfilename.foo it looks like the plugin traversed up the filesystem tree and deleted /SHARENAME completely.

 

I've confirmed it's really gone and not just a clientside SMB read error or something by logging on locally to the Unraid server and looking at the combined array filesystem in /media/user/

The share's split dirs spread across /media/disk1/, /media/disk2/, /media/disk3/, /media/cache/ are all gone.

 

Can't find much in logs, just the regular notification of the start of an empty trash operation:

Feb 4 11:42:17 SERVERNAME ool www[31973]: /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin 'share' '/mnt/user/SHARENAME'

followed by lots of errors when client PCs try to access the now nonexistent share data:

Feb  4 11:44:50 SERVERNAME rpc.mountd[5416]: refused mount request from 192.168.1.2 for /SHARENAME (/): not exported

 

Before I shut down the Unraid server and start trying any recovery operations with a grab-bag of XFS filesystem tools from a LiveCD is there any other info or logs I can give to help with diagnosis ?

 

 

Edited by kurai
typo
Link to comment
2 hours ago, kurai said:

Aaaaargh !

 

Version 2019.02.03b has just erroneously deleted an entire share instead of a file.  Completely.  From all member disks in the array.

 

 

The details of what happened, while I try to stop myself panicking too hard ...

 

I have a an Unraid XFS array setup of 5 HDDs consisting of 2x parity and 3x data disks , plus a BTRFS cache of 2x mirrored SSDs.

The share in question was set to include all disks and use cache, with directories set to split as required - it contained ~2.5TB of data.

 

On a client Linux PC (via SMB) I deleted a file from within the share ... so far so normal.  It was pretty large (20GB or so) so I went to Unraid WebUI to empty it from Recycle Bin to regain the space on the SSD cache.

There was a notification in WebUI that an update was available to the Recycle Bin plugin, so I updated that (from 2019.01.31b to 2019.02.03b)

I then opened Recycle Bin plugin and emptied the 20GB file - I didn't do anything unusual, same procedure as I've done many times before.

 

However ... instead of just deleting /SHARENAME/.Recycle.Bin/SHARENAME/20GBfilename.foo it looks like the plugin traversed up the filesystem tree and deleted /SHARENAME completely.

 

I've confirmed it's really gone and not just a clientside SMB read error or something by logging on locally to the Unraid server and looking at the combined array filesystem in /media/user/

The share's split dirs spread across /media/disk1/, /media/disk2/, /media/disk3/, /media/cache/ are all gone.

 

Can't find much in logs, just the regular notification of the start of an empty trash operation:


Feb 4 11:42:17 SERVERNAME ool www[31973]: /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin 'share' '/mnt/user/SHARENAME'

followed by lots of errors when client PCs try to access the now nonexistent share data:


Feb  4 11:44:50 SERVERNAME rpc.mountd[5416]: refused mount request from 192.168.1.2 for /SHARENAME (/): not exported

 

Before I shut down the Unraid server and start trying any recovery operations with a grab-bag of XFS filesystem tools from a LiveCD is there any other info or logs I can give to help with diagnosis ?

 

 

So you deleted the share recycle bin from the 'Shares' tab?  What was the name of the share?

Link to comment
17 minutes ago, dlandon said:

So you deleted the share recycle bin from the 'Shares' tab?  What was the name of the share?

No.

I went to Settings tab, User Utilities section, clicked Recycle Bin, which took me to http://FQDNservername.com/Settings/RecycleBin

 

In the Shares / SMB Share section there was the expected SMB Share name "SHARENAME" with a Trash size of ~20GB (the size of filename.foo deleted from SMB connected PC)

I then clicked the "Empty All Trash" button.  All normal so far.

 

As I said, however ... instead of emptying the trash and deleting only the 20GB file the whole SHARENAME share it was contained in got rm'ed.

 

 

Correction: It was the simple "Empty" button from the Shares section I clicked, not the "Empty All Trash" button from the top Recycle Bin section - if that makes a difference.

 

Edited by kurai
correction
Link to comment
20 minutes ago, dlandon said:

Feb 4 11:42:17 SERVERNAME ool www[31973]: /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin 'share' '/mnt/user/SHARENAME'

This is a share empty trash.  I'm trying to reproduce your issue here, but can't find it yet.

 

Post your diagnostics so I can review the log.

Link to comment
9 minutes ago, kurai said:

No.

I went to Settings tab, User Utilities section, clicked Recycle Bin, which took me to http://FQDNservername.com/Settings/RecycleBin

 

In the Shares / SMB Share section there was the expected SMB Share name "SHARENAME" with a Trash size of ~20GB (the size of filename.foo deleted from SMB connected PC)

I then clicked the "Empty All Trash" button.  All normal so far.

 

As I said, however ... instead of emptying the trash and deleting only the 20GB file the whole SHARENAME share it was contained in got rm'ed.

 

The log entry should look like this:

Feb 4 11:01:32 BackupServer ool www[23953]: /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin 'share' '/mnt/RecycleBin/User Shares/SHARENAME/'

There is no reference at all in the recycle bin shares to /mnt/user/.  I changed all references in the recycle bin to a set of links directly to the recycle bins that I create at /mnt/RecycleBin.  This is what you browse in the recycle bin UI.

 

Once you get the SHARENAME working again, delete a file, then go to the 'Shares' tab and click on the Browse icon.  Look at the URL when you are browsing and it should look like this:

https://backupserver/Settings/RecycleBin/Browse?dir=/mnt/RecycleBin/User%20Shares/SHARENMAME

This is the path to the .Recycle.Bin folder on SHARENAME.  It should not show /mnt/user/SHARENAME.  Let me know if it does.

Link to comment

The log entry for the original deletion event was definitely  '/mnt/user/SHARENAME' not '/mnt/RecycleBin/User Shares/SHARENAME/'

Just looked at it again at source in case something happened in copy/paste to browser.

 

I haven't done anything to get the original SHARENAME working again yet since I want to minimise array disk write activity until I can reboot from a USB LiveCD and assess some recovery/undelete options.

 

I do, however have another deleted file from a different share, /OTHERSHARE/test.txt that I created and deleted from the SMB client PC to make sure it wasn't a networking/SMB issue when I first realised SHARENAME had been nuked.

This does appear as:

http://FQDNservername.com/Settings/RecycleBin/Browse?dir=/mnt/RecycleBin/User%20Shares/OTHERSHARE

I haven't attempted any trash emptying on that yet because I really *really* don't want to potentially lose OTHERSHARE too.

 

 

 

I will post the diagnostics zip shortly - I'm just sanitising the syslog.txt a bit right now since there are some quite sensitive document names mentioned there.

 

Edited by kurai
clarification
Link to comment
17 minutes ago, kurai said:

The log entry for the original deletion event was definitely  '/mnt/user/SHARENAME' not '/mnt/RecycleBin/User Shares/SHARENAME/'

Just looked at it again at source in case something happened in copy/paste to browser.

 

I haven't done anything to get the original SHARENAME working again yet since I want to minimise array disk write activity until I can reboot from a USB LiveCD and assess some recovery/undelete options.

 

I do, however have another deleted file from a different share, /OTHERSHARE/test.txt that I created and deleted from the SMB client PC to make sure it wasn't a networking/SMB issue when I first realised SHARENAME had been nuked.

This does appear as:


http://FQDNservername.com/Settings/RecycleBin/Browse?dir=/mnt/RecycleBin/User%20Shares/OTHERSHARE

I haven't attempted any trash emptying on that yet because I really *really* don't want to potentially lose OTHERSHARE too.

 

 

 

I will post the diagnostics zip shortly - I'm just sanitising the syslog.txt a bit right now since there are some quite sensitive document names mentioned there.

 

I have no idea how you ended up with the /mnt/user/SHARENAME reference to delete the share trash, but I am now going to confirm that there is in fact a .Recycle.Bin folder on the share before adding it to the recycle bin browse.  This might help prevent this in the future.

Link to comment
26 minutes ago, kurai said:

The log entry for the original deletion event was definitely  '/mnt/user/SHARENAME' not '/mnt/RecycleBin/User Shares/SHARENAME/'

Just looked at it again at source in case something happened in copy/paste to browser.

 

I haven't done anything to get the original SHARENAME working again yet since I want to minimise array disk write activity until I can reboot from a USB LiveCD and assess some recovery/undelete options.

 

I do, however have another deleted file from a different share, /OTHERSHARE/test.txt that I created and deleted from the SMB client PC to make sure it wasn't a networking/SMB issue when I first realised SHARENAME had been nuked.

This does appear as:


http://FQDNservername.com/Settings/RecycleBin/Browse?dir=/mnt/RecycleBin/User%20Shares/OTHERSHARE

I haven't attempted any trash emptying on that yet because I really *really* don't want to potentially lose OTHERSHARE too.

 

 

 

I will post the diagnostics zip shortly - I'm just sanitising the syslog.txt a bit right now since there are some quite sensitive document names mentioned there.

 

Go to the Recycle Bin and click on the trash can and browse the trash.  Click on the User Shares.  All you should see are the shares with .Recycle.Bin contents.  If you see any reference to /mnt/user/ let me know.

Link to comment

I have developed a theory for how this happened.  Let me describe how the old and new methods of emptying the share work.

 

There are two pieces used to remove the contents of the .Recycle.Bin folder.  The UI passes the share recycle bin reference to a script that does the actual removal.

 

Old way:

When the Share empty button was pressed the UI passed the share path to the script that removed the .Recycle.Bin contents.  The script appended the '.Recycle.Bin' to the passed in path to the share.  In your case the UI would pass in /mnt/user/SHARENAME and the script would append the .Recycle.Bin folder to the share path to make /mnt/user/SHARENAME/.Recycle.Bin which is the proper folder to the recycle bin contents.

 

New way:

A symlink is created for each share with recycle bin contents at /mnt/RecycleBin.  This was originally created to make the Unraid file browser work.  For several reasons, I decided that it would be better for this to be used for the UI for browsing and share empty functions.  So now the UI passes in the symlink to the share recycle bin directly to the script and the script just removes the recycle bin contents from the share symlink path directly because it already references the share .Recycle.Bin.  The passed share recycle bin path is then /mnt/RecycleBin/SHARENAME which is the correct path to the .Recycle.Bin folder.

 

Your sequence of operations as best as I can tell is:

- Browse to the recycle bin UI to look at SHARENAME recycle bin contents and remove a deleted file.

- Decided to check for an update first and see if there is an update.

- Update the recycle bin plugin.

- Go back to the recycle bin UI and empty the share recycle bin.  The old UI is cached?

 

I am not an expert at how browsers cache web pages, but I think that the recycle bin UI was not refreshed to the new plugin version.  The script would have been updated, but the UI web page may not have been.  So you have the old method of the UI and the new method of the script.  The old method UI would then pass /mnt/user/SHARENAME to the script but the .Recycle.Bin would not be appended as in the old way of doing things and the /mnt/user/SHARENAME contents would be removed because the script expected it was a symlink to the /mnt/user/SHARENAME/.Recycle.Bin folder.

 

I know this is a stretch, but I could see how it could happen.  What I've done in the latest version is to block removal of the share recycle bin contents if the path is not /mnt/RecycleBin/SHARENAME passed in to the script and log an error.

Edited by dlandon
Link to comment

That... sounds horribly plausible. 

 

I *did* have two Chrome tabs open to different pages of the Unraid webUI. 

When I initially opened WebUI page, Main tab, I had the updates available notification from Fix Common Problems appear and I opened the Plugins page into a new tab and did the updates. 

 

I was also doing stuff in other unrelated tabs, and it's entirely possible that when I went back to Unraid a few minutes later I used the original, unrefreshed, tab and went to Empty Trash from there (I have your plugin in main menu bar via Add Custom Tab) instead of the 2nd tab that the updating procedure was done in. 

 

I'm not sure if the diag logs will be able to confirm that one way or another, but I'll post them anyway ... eventually. 

They are saved to the boot thumbdrive and the server is currently shutdown while I am wrestling with XFS undelete/recovery tools, which are proving to be massively time consuming and erratic :/

 

Link to comment
2 hours ago, kurai said:

That... sounds horribly plausible. 

 

I *did* have two Chrome tabs open to different pages of the Unraid webUI. 

When I initially opened WebUI page, Main tab, I had the updates available notification from Fix Common Problems appear and I opened the Plugins page into a new tab and did the updates. 

 

I was also doing stuff in other unrelated tabs, and it's entirely possible that when I went back to Unraid a few minutes later I used the original, unrefreshed, tab and went to Empty Trash from there (I have your plugin in main menu bar via Add Custom Tab) instead of the 2nd tab that the updating procedure was done in. 

 

I'm not sure if the diag logs will be able to confirm that one way or another, but I'll post them anyway ... eventually. 

They are saved to the boot thumbdrive and the server is currently shutdown while I am wrestling with XFS undelete/recovery tools, which are proving to be massively time consuming and erratic :/

 

Based on what you are saying, I think the scenario I described is what happened to you.  The diagnostics probably won't have any value.

 

I'd also recommend you make backups of your data so you can recover from a situation like this.

Link to comment
  • dlandon changed the title to Recycle Bin (vfs recycle) for SMB Shares

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.