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.
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).
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:
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.
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 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.
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
Thank you for all the help and hope to be happy long more years