Several partitions are suddenly ZFS?! - or system SSD broken???

My setup can be seen in my signature. I use my data disks in that way that dev/sdb contains our stuff and dev/sdc is used as a backup drive (rsyncing sdb to sdc every night - this was a suggestion by ryecoaaron when I had problems keeping a RAID1 alive [KLICK]).

Anyway, a few days ago I recieved an email that the rsyncing was interrupted (I don't remember the message error; unfortunately I've deleted it), moreover I couldn't reach my backup drive any more. An OMV reboot was stopped with a message something like "fsck was interrupted with error code 8", it's log was this:

Log of fsck -C -R -A -a 
Wed Aug 17 19:54:45 2016
fsck from util-linux 2.20.1
BackUp: recovering journal
Files: clean, 94453/244195328 files, 216367788/976754646 blocks
fsck.ext4: No such file or directory while trying to re-open BackUp
Signal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x61
fsck.ext4[0x427a50]
/lib/x86_64-linux-gnu/libc.so.6(+0x321a0)[0x7f1865a6e1a0]
/lib/x86_64-linux-gnu/libext2fs.so.2(ext2fs_mmp_stop+0x1c)[0x7f186662595c]
fsck.ext4(fatal_error+0x42)[0x41e7c2]
fsck.ext4(e2fsck_run_ext3_journal+0x2d3)[0x41dd03]
fsck.ext4(main+0x71e)[0x40a5ee]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f1865a5aead]
fsck.ext4[0x40c81d]
fsck died with exit status 8
Wed Aug 17 19:54:55 2016
----------------

I started a live Lubuntu and checked what I thought might be wrong (SMART, badblocks etc.) with no recognizable result.
But accidentally I discovered that several partitions in my system are now formatted as ZFS?! I know for sure that at least sdc/sdc1 was an ext4 and I'm very sure that sda(x) were the usual debian system formats.

lubuntu@lubuntu:~$ sudo lsblk -fl
NAME  FSTYPE     LABEL UUID                                 MOUNTPOINT
sda   zfs_member                                            
sda1  ext4             019f74d5-7276-4831-a666-dc07db60c6e0 
sda2  zfs_member                                            
sda5  zfs_member                                            
sdb   ext4       Files 010a3652-d1b4-45dd-af3a-882509cf45d9 
sdc   zfs_member                                            
sdc1  zfs_member                                            
sdd                                                         
sdd1  vfat             6791-E0D9                            /cdrom
loop0 ext3             e0798e84-6c41-4e89-ac59-b2d5e79f1261 
loop1 squashfs                                              /rofs
zram0                                                       [SWAP]
zram1                                                       [SWAP]
lubuntu@lubuntu:~$

[I don't know why these codes are formatted differently?!]

I am very irritated at the moment: What went wrong and what can I do now with my OMV???

No, I never did anything with ZFS (far too exotic for my knowledge ) - especially sdb and sdc were formatted as ext4. That's why I am so perplexed now.

With OMV-Extras, Samba, MiniDLNA and rsync no special plugins where installed either, the system was built like 2 years ago and except regular updates nothing was changed then.

I'm going to provide the output ofblkid as soon as I'm home.

OK, don't ask me why or how but this time my OMV started without any issue - it didn't the last 3 times

Moreover I have access again to my files drive as well as to my backup drive...

Here is the blkid:

/dev/sda1: UUID="019f74d5-7276-4831-a666-dc07db60c6e0" TYPE="ext4" 
/dev/sda5: UUID="aab3e05c-7910-46f9-9a0a-b4cfe72b4ee2" TYPE="swap" 
/dev/sdb: LABEL="Files" UUID="010a3652-d1b4-45dd-af3a-882509cf45d9" TYPE="ext4" 
/dev/sdc1: LABEL="BackUp" UUID="cb265027-49b9-413f-a22d-969981092942" TYPE="ext4"

Looks pretty OK to me

I'm absolutely not sure but I do think sdc's UUID has changed - is this possible?!?

Sorry I didn't mentioned that (was a little nervous and freaked out the last days): Yes, I ran fsck on every drive with Lubuntu but didn't boot into OMV afterwards.

root@OMV:/media# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=019f74d5-7276-4831-a666-dc07db60c6e0 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=aab3e05c-7910-46f9-9a0a-b4cfe72b4ee2 none            swap    sw              0       0
/dev/sdb1       /media/usb0     auto    rw,user,noauto  0       0
tmpfs           /tmp            tmpfs   defaults        0       0
# >>> [openmediavault]
UUID=cb265027-49b9-413f-a22d-969981092942 /media/cb265027-49b9-413f-a22d-969981092942 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
UUID=010a3652-d1b4-45dd-af3a-882509cf45d9 /media/010a3652-d1b4-45dd-af3a-882509cf45d9 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
# <<< [openmediavault]
root@OMV:/media#

Hmmmm, doing a ls -l in /media shows a CD-drive - but there isn't one in my OMV?!

root@OMV:/media# ls -l
insgesamt 16
drwxr-xr-x 5 root root 4096 Mai 10  2015 010a3652-d1b4-45dd-af3a-882509cf45d9
drwxr-xr-x 5 root root 4096 Jul  7  2015 cb265027-49b9-413f-a22d-969981092942
drwxr-xr-x 2 root root 4096 Mär 12  2015 cdrom
lrwxrwxrwx 1 root root    4 Mär 12  2015 usb -> usb0
drwxr-xr-x 2 root root 4096 Mär 12  2015 usb0

Zitat von ryecoaaron

Everything looks fine. UUIDs match.

The cdrom directory is just a directory. It isn't telling you that there is a cdrom drive in the machine. If it bothers you that much, delete it.

Ok, the best news in the last days
Thank you VERY much for your assistance - I really appreciate this!

CDRom: Yeah, now that you mention it I see it too that it's a directory

But I still somehow wonder what has happended to my OMV that the fsck error 8 showed up and why Lubuntu showed me ZFS...???

Marked as "Solved" - seems to be working again

So my original problem obviously was solved but today, after 24h without any problems, my OMV suddenly went offline (while deleting a lot of GB) and couldn't be reached anymore. After attaching a screen I discovered the error messages shown in the picture.
After searching the web I discovered some (old) Linux threads where they were talking about dying disks.

Does anybody know these errors and do they mean my system SSD is dying (maybe 2 or 3 years old)?

No, I didn't install the flashmemory plugin since I thought this was only useful for USB-sticks.

What would the dmesg-command be? Sorry for this question, I tried to find out myself but couldn't find a useful combination :-/
(Amongst others I searched the dmesg manpage).

Hmm, I don't think we have heavy writing... My wife and me use our OMV mainly for storing our family fotos, some films/tv shows, my ripped cd's (though I just discovered Spotify using RuneAudio on a Pi ) and some files/data backups. So most of the time our OMV doesn't do anything...
On the other side who knows what computers do all day long...

Ok, I'm gonna be away a few days but will definitely give a feedback to my problems. Again: Thank you so far!

Ok, back again. Life can be distracting sometimes... :-/

I keep getting strange results when testing my HDDs. Live-*buntus keep telling me that one HDD is formatted as ZFS (-> sdc.png). Though testing its SMART values don't show any abnormalities (in my opinion).
When starting my OMV installation it keeps unmounting after several seconds or even completly disappearing under "File Systems".

I think I will return it to WD (I hope they will accept it :-/) and with a new drive everything will be OK.

Ok, I recieved a new (well, a refurbished) drive today and are hoping that my problems are solved now

Another question: I obviously missed to mark the returned drive as removed from my system which now shows it as "N/V". Is there a way to clear that?

OK, solved it myself: Deleting the used folders once existed on that drive made it deletable.