Files show as 0 KB

[nickn]

I am  using UnRAID version 6.3.5.

Today, I was working on listing files on my server via SSH.  Root is the only currently configured SSH account (which is bad, I know) so I logged in as root.

I executed commands just to produce a list of files, like this:

find . -type f -iname "*.iso" -printf "%f\n" | sort | tee isos.txt

I also performed other server maintenance actions such as:

• Changed root password and password for user 'nick'
• Stopped the array, rebooted, and restarted the array

 

My problem is that every ISO file in a share that I have, is now 0 kb.  All 200+ files.  I have backups of only about half of these files.

Is there anything I can do to recover them?  I know that it is likely a command I inadvertently entered that caused this, but I looked back through my SSH history and didn't find any "mv" or "rm" commands.

 

If you need any log information, let me know. Thanks!

 

 

Edited January 2, 2018 by nickn

[saarg]

I don't know what happened with your iso files, but you should never change the password using ssh. Always use the webui to handle users and passwords or else they are lost on reboot. Unraid is loaded into ram at boot.

Both in ssh and webui, root is the only user that can log in.

[remotevisitor]

Unfortunately I know of no way to recover files which have been made zero length other than from backups.

 

Is it possible that in the past you have ‘tidied’ up your share which involved coping/moving files between a user share and a disk share (either over the network or on the Unraid system itself)?

 

Files being made zero size is a symptom of copying/moving files between user and disk shares if the destination is effectively the same location as the source and is why you should never copy files between user and disk shares (unless you really understand when it is safe to do so) and is why disk shares are now disabled by default to help avoid this problem when copying/moving files across the network (and the help text for enabling disk shares has a warning about potential data loss if you do enable them).

 

Of course it is possible that something else caused the files to be made zero in size.

[SSD]

3 hours ago, remotevisitor said:

Unfortunately I know of no way to recover files which have been made zero length other than from backups.

 

Is it possible that in the past you have ‘tidied’ up your share which involved coping/moving files between a user share and a disk share (either over the network or on the Unraid system itself)?

 

Files being made zero size is a symptom of copying/moving files between user and disk shares if the destination is effectively the same location as the source and is why you should never copy files between user and disk shares (unless you really understand when it is safe to do so) and is why disk shares are now disabled by default to help avoid this problem when copying/moving files across the network (and the help text for enabling disk shares has a warning about potential data loss if you do enable them).

 

Of course it is possible that something else caused the files to be made zero in size.

 

I concur. I documented this "bug" a long time ago and LT had done what it can to protect users, but it is a nasty issue.

 

If you removed a disk from a user share and then tried to copy the files from that disk back into the user share, thinking this would reallocate the files to other disks, this is exactly what will happen. 

[nickn]

Hello,

To answer some of your questions:

1. I didn't try to change the password over SSH; I only did it in the WebUI
2. I have never moved files between a disk share and a user share.  I do not have disk shares enabled, but when working in SSH I did go into a couple disk shares and do an "ls" command. Then I went out of the disk share and into /mnt/user/movies.iso and issued the find command.

I'm perplexed as to how the "find and sort" commands could have caused this, but because I rebooted the server I don't have a complete listing of the variants of the find commands I attempted.

 

I understand that UnRaid's parity system can restore files on one failed disk.  Right now my array consists of a 6 TB parity disk and two 3 TB data disks.  Would it be possible to 'pretend' that one of the data disks was bad, and have UnRaid restore some of the files onto one of the disks?  I realize I'd have to backup all of my data before doing this.  I'm just wondering because it last ran a parity check a few weeks ago.  Or, is this not possible as the parity is updated in real-time?

[JorgeB]

19 minutes ago, nickn said:

Or, is this not possible as the parity is updated in real-time?

^this

[nickn]

Is it normal for there to be both a 'user' and 'user0' folder in the /mnt directory?

[JorgeB]

8 minutes ago, nickn said:

Is it normal for there to be both a 'user' and 'user0' folder in the /mnt directory?

Yes, /mnt/user includes the cache drive, /mnt/user0 excludes it.

[SSD]

You could run a non correcting parity check. If there are parity errors, it could mean that the disk was updated outside of parity protection. In such a case, a rebuild could restore the disk. (Assuming only one disk held these files)

 

But I consider it EXTREMELY unlikely the disk was updated outside of parity. More likely one of your errant find command did something funky. Although unlikely from your description, it's most likely theory.

 

Not to get hopes up, but there are undelete options. You might get some limited success if disk has not been updated. My experience with XFS had been poor (I lost a couple files and tried to recover them as a test case, but had no luck), but you can Google and try.  I have no experience with BTRFS. With RFS I'd give better than 50-50 chance of some level of recovery. Problem might be identifying what is recovered and determining if the files are correct and complete.

 

Sorry this happened.