Jump to content

kurai

Members
  • Posts

    19
  • Joined

  • Last visited

Posts posted by kurai

  1. I'm leaning towards the process/functionality being one of those "works for some people but not others" things at this stage.

     

    I banged my head against a series of brick walls for an unreasonable amount of time trying all the many and varied approaches I found during the research phase.

     

    At the moment I've given up and left it alone, checking back on the few worthwhile information sources now and again to see if anything has substantially improved.

  2. Hi Djoss.

    Thanks for keeping on with the client updates.

     

    An issue this time though ... the Tools->History menu opens the activity log in a window 100% of the size of the browser viewport, and has no modal window controls.  i.e. No way to go back to the main app interface 'window', and because of the canvas style implementation there's no browser back/history/right-click functionality to exit out of it either.

    Necessitates a restart of the container to get back to normal.

    (All the other top menu bar entries and other modal window elements still work as expected).

     

  3. 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 :/

     

  4. 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.

     

  5. 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.

     

  6. 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 ?

     

     

×
×
  • Create New...