WDTV Live corrupts NAS hard disk

Hi There,

I`m trying use WDTV Live with NAS Zyxel NSA210 with 1,5 TB disk. When I connect through LAN to NAS server

everything works, I can watch movies, … but when I turn off WDTV I can see that NAS stops working. When I check

hard disk, its corrupted, I can't write or read from it. I have to conect disk to PC and I have to use some soft to repair xfs file system.  I try use Eject button but it doesnt works. Now I don`t know how to use WDTV without corrupting disk.

I have NAS as backup disk and I don`t want lose all my data.

Is there a way to safely turn off  WDTV?

Thanks

If the disks in a NAS are getting corrupted, it’s a problem with the NAS, not the client.

There’s simply no way an SMB client can corrupt an entire file system in such a way as you describe.

Im not sure if its problem only with the NAS. Im using that NAS as torrent client, I was conected to the NAS with 4 notebooks and 2 PCs, I transfered over 4 TB datas to and from NAS without any problems. I have problem only with WDTV. Last time I was conected direct through LAN. I wanted try conect through media server but I didnt catch it. Now its second day when Im trying to repair my NAS disk. I have broken superblock on xfs file system. 

I dont know, maybe its my fault, but everything what I did was turn on WDTV, watch the movie from NAS and turn off WDTV. 

I can guarantee you that it was NOT the WDTV that corrupted the superblock.   That would be, in a word, impossible.  Your NAS has a severe bug.

Well, sound impossible but i got the same Issue now, however only Filebased Corruption, but it is 100% the WD TV LIVE HUB that has corrupted these Files, the FIledate changed and it was exactly the Time where i granted Write Access to the Hub for testing the MediaLibrary Get Meta Content Function.

The strange Thing is, the Files are same Size but Date changed and also MD5 is different, i i inspect the Files with Hiew i can see that tiny Blocks of 16 Bytes vanished(are nullified!) all over the File, else everything is there.

And because it happend exactly where the Hub had Write Access and not after i removed the Write Access again because the MediaLibrary does not work for my anyway, it was 100% caused by the Hub. Also i copied over 500GB to that NAS in meantime and no Corruption occured and all other Files that where never opened by the Hub while Write Access are not corrupted.

I currently don’t understand how it happens, but its certainly a Thing to be inspected, and i will never again give the HUB any Writeaccess for sure, too dangerous as long this Issue is not 100% cleared, and because WD is very slow in fixing Bugs, well better never again give Writeaccess then!

Ya know, I think you’re either the unluckiest person around, or you’re just plain making stuff up!   :smileyvery-happy:   

For one thing, you do NOT have the same issue.    The OP said that his drive’s SUPERBLOCK got corrupted by the NAS Client.   That is impossible.   Samba doesn’t do BLOCK LEVEL access to files.   NFS doesn’t even do that.  These protocols are FILE-LEVEL protocols.   They do not have access to BLOCK-LEVEL data.

File corruption IS possible, but quite unlikely the Hub is responsible.    I don’t care how often you say it’s 100% the Hub.  Nothing you’ve indicated proves anything.   You’re succombing to a logical fallacy known as “Post Hoc Ergo Propter Hoc.”

I won’t say it’s impossible, but I can say that I have ALWAYS given my Live Hub Read / Write access to the NAS, and not a single issue with file corruption.

Your own statement even tends to indicate it was NOT the Hub:

 the FIledate changed and it was exactly the Time where i granted Write Access to the Hub

Unless you told the Hub to access a file at the SAME SECOND you changed the priviledges, then the NAS did something all on its own.   You’re suggesting that the Hub is just sitting there watching a file and waiting to gain write-access to it, and the instant it gains access, it wrote something.    That’s not how the Hub works.

From the sound of it, you’re saying that it’s almost 100% reproducible problem.

I would love to see real evidence:   A Wireshark capture of this event occurring.

While I may lose out on some indexing features, I setup my WDTV to connect to my NAS via a READ-ONLY share. Problem solved :wink:

For one thing, you do NOT have the same issue.    The OP said that his drive’s SUPERBLOCK got corrupted by >>the NAS Client.   That is impossible.   Samba doesn’t do BLOCK LEVEL access to files.   NFS doesn’t even do >>that. These protocols are FILE-LEVEL protocols.   They do not have access to BLOCK-LEVEL data.

 

Allready said its only Filebased, however Corruption is Corruption and should not happen!

 

File corruption IS possible, but quite unlikely the Hub is responsible.    I don’t care how often you say it’s 100% >>the Hub.  Nothing you’ve indicated proves anything.   You’re succombing to a logical fallacy known as “Post Hoc >>Ergo Propter Hoc.”

 

I won’t say it’s impossible, but I can say that I have ALWAYS given my Live Hub Read / Write access to the NAS, >>and not a single issue with file corruption.

 

Unless you told the Hub to access a file at the SAME SECOND you changed the priviledges, then the NAS did >>something all on its own.   You’re suggesting that the Hub is just sitting there watching a file and waiting to gain >>write-access to it, and the instant it gains access, it wrote something.    That’s not how the Hub works.

 

From the sound of it, you’re saying that it’s almost 100% reproducible problem.

 

I would love to see real evidence:   A Wireshark capture of this event occurring.

 

Well, i given Write-Access for the Medialibrary GetContent Function, the Filedates of ALL Corrupted Files changed too exactly the Period where the Medialibrary was scanning or i got Content for exactly these Files, no other Files was corrupted. And i never written sokthing about “at the same second” it was while…

So yes it was 100% to do with the Hub somehow, also the Corruption is the same for all these Files, little 16 Bytes Block nullified across the Files (.AVI Files).

And well, i’m also a certified Forensic Investigator and i think i have a good Logic for such Things, but i certainly not have running a seperate Nethub(Everything is on Switches) and Wireshark running all the Time to record what the WD TV LIVE HUB makes only to have a Capture of this special Event occuring, i never expected the HUB is going to write on these Files and corrupts them either.

Also i think its not my Job to make a detailed and certified Testreport about it, else then WD has to pay me for doing it.

For now the Solution is simple, i never again give the Hub Writeaccess, and thats all!