LED - RED (constant) and i can't see files anymore

40-second reset is System Factory Restore; it deletes Users. But not the user data.

In SSH, go to the user area, and see if the shares are still there, but not mounted or visible to the Dashboard for some reason. How many shares is the Dashboard showing?

cd /DataVolume/shares
ls 

I feared that your file system was trashed, when you reported the result of df -h; it seemed to only report rootfs, and none of the other partitions. It sounds like your power failure did a good job of destroying your file system.

If you don’t have a backup, your only hope now may be to remove the disk from the enclosure, and connect it to a Linux box to try to run file recovery. Search the forum for threads on file recovery. However, it may be that the System Factory Restore will have overwritten the remnants of the previous file system, and you may not have a lot of luck recovering. But I can’t think of anything else. If anyone else has ideas, please speak up…

I’m afraid backups are essential for any HDD; a HDD can fail at any time, and the data may not be recoverable by any means.

I realy lost everything :frowning:
Before i still had cd /DataVolume/share but now not anymore

And with df -h i get:

So i think i lost everything now :frowning:
If i lost everything, what do i have to do to use this system again and that it is working again normal?

HO Wait, i see now i still have my share:

But i can’t go in this:

And you can see that in my /DataVolume is NO Share. Only a Backup (empty) and Cache.

That df output still doesn’t look right.

/CacheVolume and /DataVolume should be /dev/sda4. Here’s what I get:

WDMyCloud:~# cd /
WDMyCloud:/# df -h
    Filesystem      Size  Used Avail Use% Mounted on
    rootfs          1.9G  629M  1.2G  35% /
    /dev/root       1.9G  629M  1.2G  35% /
    tmpfs            40M  9.4M   31M  24% /run
    tmpfs            40M   64K   40M   1% /run/lock
    tmpfs            10M     0   10M   0% /dev
    tmpfs           5.0M     0  5.0M   0% /run/shm
    tmpfs           100M  4.0M   96M   4% /tmp
    /dev/root       1.9G  629M  1.2G  35% /var/log.hdd
    ramlog-tmpfs     40M  8.7M   32M  22% /var/log
    /dev/sda4       3.6T  1.9T  1.7T  53% /DataVolume
    /dev/sda4       3.6T  1.9T  1.7T  53% /CacheVolume
    /dev/sda4       3.6T  1.9T  1.7T  53% /nfs/Public
    /dev/sda4       3.6T  1.9T  1.7T  53% /nfs/Media

There’s a thread that solved this somewhere, and it involved mounting sda4… can I find it…?

Hmm… maybe this one:

which used

mount /dev/sda4 /DataVolume
mount -bind /DataVolume/cache /CacheVolume

or this one:

which used

/etc/init.d/mountDataVolume.sh

or this:

which has a very similar df result to yours, including the /dev/root for /CacheVolume, and Fox_exe suggested:

mount -t ext4 /dev/sda4 /DataVolume

I’ll be honest with you: this is getting beyond my pay grade… Linux file system mounting stuff is just a bit beyond my experience, and you may be better off asking for assistance from more knowledgeable types. @Bennor, perhaps?

But I note that mounting /dev/sda4 as /DataVolume seemed to do the trick in two of the cases above, with different degrees of explicit control (i.e. Fox_exe enforced the ext4 file type, rather than letting it automatically decide; it will be ext4).

This is what i get when i use /etc/init.d/mountDataVolume.sh:
(all the other stuff is not working or i get not to let it work :frowning: )

What error messages do you get when you try the mount commands?

MountDataVolume is identifying file system errors as we suspect, and suggesting you run fsck. Get googling about how to use that command.

Also try fdisk -l to list the disk partitions, as suggested by Fox_exe in one of those linked threads.

I don’t have much more to suggest beyond what has been already suggested.

@iCloud, Here is what I (personally) would do in this instance. First I would try to reflash/reupdate the firmware using either the Dashboard (if it can be reached) or via SSH as explained/discussed in the following thread if the Dashboard cannot be reached:

https://community.wd.com/t/how-to-firmware-update-via-ssh/95476

Next, if the My Cloud unit is out of warrantee I would disassemble the My Cloud enclosure (perform an internet search for videos on how to remove the hard drive) to remove the hard drive, then attach that hard drive to a computer and boot that computer using a Linux boot disc or Live CD (Ubuntu is one popular Linux Live CD: http://www.ubuntu.com/download). From there one can use various Linux tools and command line commands to examine the hard drive and its contents. Further one could, if the data hasn’t been corrupted on user data partition (sda4), copy the data to another hard drive using the Linux Live CD.

Note that one should take care when using Linux to ensure they don’t trash their existing computer’s hard drive. Normally I disconnect or remove my computer’s existing hard drive(s) before working on the removed My Cloud hard drive.

If the My Cloud hard drive is corrupted and the data cannot be recovered (using various Linux data recovery tools/options) then I would attempt to “unbrick” the drive provided the drive itself is healthy (no bad sectors or SMART errors). One can search this subforum for various unbricking methods.

Or one could contact WD Support and send the My Cloud back to WD, pay them to recover the data (if possible) and repair/replace the My Cloud unit.

1 Like

I don’t know what i have done, but i see my files again :slight_smile:
But how do i get them now on my other harddisk?

I can see the directory and files in it.

I can’t login on dashboard and can’t see my personal files, i see: No Devices Available, Please notify the device’s owner (or Admin user).

You can see them where? From the Linux command line? If so, you should be able to connect a USB HDD to the USB port on the MyCloud, then find the USB drive in the MyCloud file system, and simply use cp -R <source> <destination>. It will take a while, but I imagine that isn’t your worry… I think USBs appear under /shares/<USB volume name> so you’ll have to have to copy each ‘real’ share to the USB in turn. Do some small copies first, to make sure you know that files will be copied to the right place.

I suspect that running repeated passes of MountDataVolume.sh has run enough passes of fsck to fix the errors, and it has now mounted… In which case, it might be safe to do another 40-second reset. But I think I’d be worried I might break the ‘working’ state I already have…

What happens if you do a ‘do nothing’ fsck?

fsck -N /dev/sda4

This should report problems it finds, but not make any corrections.

What does df -h report now?

Once you have your files safely copied to USB, I’d force a firmware upgrade, then a Quick Factory Restore

I get this to see. He He can’t find the USB, i think because it is not open.
So i try to do the 40 second reset and hoop it will work good.

Good luck…

I may have misunderstood the fsck manual: it looks like the -N option reports what particular command it will run (there are versions of fsck for each type of file system). In this case, since it is an ext4 file system, it will run fsck.ext4.

Rather than actually running it in ‘report only’ mode; looks like the -n option may do that; man fsck should confirm the options available on Debian.

So, how did you get on? Is your device working now?

It was a long weekend and it was taking the weekend to put it back to factory settings. But now it is working again and i have no problems. I can start it again and have put my documents back and all is working. But i’m still looking out, i don’t want to happen this again :slight_smile:

Thank you for all the help and hope to be happy long more years :slight_smile: