This is an odd one.

 

I have a bunch of shares set up on my unRAID server.  One of them I use to keep track of anything related to projects and maintenance I'd do around the house.  Random things like car oil changes, getting the septic pumped, replacing parts on lawn equipment, etc. 

 

Today I went into that share to look something up relating to a basement remodel.  All of the files were there.  But they were all listed at 0KB size.  Any .txt file opens, but has nothing inside it.  None of the pictures, .doc files, or .xlsx files open.  

 

Quite concerning.  I went into all the other shares and spot checked and didn't find this issue anywhere else.

 

Any idea what this issue could be, and am I SOL or are there potential ways to remedy this?

 

 

unraid-diagnostics-20190211-0849.zip

Here are the settings for the share with the issue:

 

Have you moved those files around the server?

 

0Kb files are a typical result of copying from a disk share to a user share or vice versa.

Certainly not on purpose.  I had an issue last week where my docker files crapped out and I had to rebuild from my appdata backup. 

 

Other than that, I made no material changes to anything related to that share.

Here are the search results for one of the files:

 

 

I looked in all three locations.  All 3 locations show 0 kb file size.  Am I screwed?

3 minutes ago, Living Legend said:

All 3 locations show 0 kb file size.

That's expected since it always the same file, just found in different paths.

19 minutes ago, johnnie.black said:

That's expected since it always the same file, just found in different paths.

 

Yeah, that's what I assumed.

 

 I assume that there's no basic resolution to this type of issue? 

21 minutes ago, Living Legend said:

I assume that there's no basic resolution to this type of issue? 

Restore from backup? If there's no backup you can try a file recovery utility, like UFS explorer, success will depend greatly on if there were any writes to the same disk after this happened

Out of curiosity, to attempt to prevent in the future, what can cause something like this?  Is this a file corruption issue or potential disk failure issue?  If the former, I understand that an actual backup would be the only way to resolve. 

 

But if the latter, shouldn't I have had some sort of drive failure notification so that I could attempt to rebuild before I hit the point of no return?

9 hours ago, Living Legend said:

I had an issue last week where my docker files crapped out

I know this is not what you are posting about, but it looks like you are filling your docker image. You have it set to 50G but the only thing that will do is make it take longer to fill. If you have your apps configured correctly it is unlikely you would ever need even 20G.

6 hours ago, Living Legend said:

Out of curiosity, to attempt to prevent in the future, what can cause something like this?  Is this a file corruption issue or potential disk failure issue?  If the former, I understand that an actual backup would be the only way to resolve. 

 

But if the latter, shouldn't I have had some sort of drive failure notification so that I could attempt to rebuild before I hit the point of no return?

This is a known issue that can happen if a User tries to copy a file between a Disk Share and a User Share not realising they can be two different views of the same file.   This can result in the system trying to copy the file to itself which results in the truncation to 0 size.  

 

You will see this behaviour often referred to as the “User Share bug”.   It is architectural problem with the way that Linux handles FUSE file systems that is used to implement User Shares and is not amenable to change.    It is also one of the reasons why Disk Shares are disabled by default when using User Shares as the problem can only occur if you use both a User Share and a Disk Share in the same copy command and unknowingly end up attempting to copy the file to itself.  In addition some people do not realise that ‘cache’ is also a Disk Share as well as any one of the form ‘diskX’.

5 hours ago, itimpi said:

This is a known issue that can happen if a User tries to copy a file between a Disk Share and a User Share not realising they can be two different views of the same file.   This can result in the system trying to copy the file to itself which results in the truncation to 0 size.  

 

You will see this behaviour often referred to as the “User Share bug”.   It is architectural problem with the way that Linux handles FUSE file systems that is used to implement User Shares and is not amenable to change.    It is also one of the reasons why Disk Shares are disabled by default when using User Shares as the problem can only occur if you use both a User Share and a Disk Share in the same copy command and unknowingly end up attempting to copy the file to itself.  In addition some people do not realise that ‘cache’ is also a Disk Share as well as any one of the form ‘diskX’.

 

Yes, I have made this mistake.  I could not figure out why some of my movies that initially downloaded to cache were not moving out of cache.  I'd try to move them manually and then poof, they'd disappear.

 

I wish I could attribute this loss of data to the user error mentioned above, but unfortunately that's not the case here.  If the error was on me it'd be easy to move on and learn from my mistake, but the problem is I haven't manually moved files into a disk share in probably over a year.  I only add or delete files at my user shares.  So I have absolutely no idea how this one random share that I haven't accessed in about a month has all the files names but no data.

 

To me this goes to show the importance of backing up important data outside of the array because every once in a while, even though unRAID is meant to protect your data in the event of drive failure, it may throw out some quirk and gobble up a few files.

Edited February 12, 20197 yr by Living Legend

11 hours ago, trurl said:

I know this is not what you are posting about, but it looks like you are filling your docker image. You have it set to 50G but the only thing that will do is make it take longer to fill. If you have your apps configured correctly it is unlikely you would ever need even 20G.

 

Yes, you're definitely right.  I have many many dockers and there has to be at least one or two that are storing some sort of file inside the container and making them grow.  Haven't found a simple way to solve his one yet.  This shows it should be around 20GB.  Not sure why zoneminder and HA get so big.  Homeassistant database gets large but that's on the array.  Zoneminder recordings have their own share.  DelugeVPN downloads to different folders within a share.  Always been perplexed by this one.

 

Edited February 12, 20197 yr by Living Legend

1 hour ago, Living Legend said:

This shows it should be around 20GB

Your diagnostics show 18G currently used. Does it eventually grow to fill your 50G?

Ah, I see.  

 

I have had the issue in the past where it continues to grow. which was why I ballooned it to 50G.  I cleared out a few old unused dockers and reset a few mappings to try and resolve the issues.  

 

It looks like I may have partially resolved the issue though since I"m currently sitting under 20G