After 5.30 update, I can not mount a drive (an encrypted JBOD). EX4100

My Cloud OS 5 My Cloud EX
, ,
1

After the update, I was tremendously relieved that I was able to get back in my RAID volume after entering the encryption password. THAT is back to normal.

However, a JBOD, also encrypted, is not showing me the option to ‘mount’ unlike the RAID volume which did.

I decided to take that drive out and mount it in a computer with Linux Mint. After unlocking the LUKS partition with the same password I would in the NAS, everything was there. I did a filesystem check and everything checks out. SMART is not showing any errors.

Anyone know why my EX4100 now refuses to mount the drive? Did the OS update screw up a configuration somewhere that’s not visible in the UI?

Even when accessing the NAS via SSH, the /shares/Volume_2 folder is there but says ‘No Such File or directory’ when I try to CD into it.

1 Like
2

Hi @Copernicus

Have you checked our knowledge base articles?
(Support for Western Digital Hard Drives | Western Digital)

Try this one.

Have you opened a Support Case?
If not, contact Western Digital Technical Support for assistance.
[Contact Us | Western Digital]

3

There are lots of reports on this forum regarding the latest firmware update. The “cure” seems to be a rollback of the OS to the previous version.

4

It looks like the OS update on your WD My Cloud EX4100 changed how it handles JBOD volumes, especially encrypted ones. Your RAID volume mounted fine after entering the encryption password, but the JBOD drive isn’t giving you the option to mount it. Since you were able to unlock and access the LUKS-encrypted JBOD drive on Linux Mint without any problems, the encryption and filesystem are fine. The issue seems to be with how the NAS is handling the mount process.

The first step is to check whether the NAS recognizes the drive. You can do this by running lsblk -f or fdisk -l over SSH. If the drive is listed but not mounted, try mounting it manually with mount /dev/sdXn /mnt/. Checking system logs with dmesg | tail -50 or journalctl -xe might show what’s going wrong. Also, verify that the LUKS header is intact using cryptsetup luksDump /dev/sdXn to rule out encryption issues.

If the NAS isn’t unlocking the JBOD volume automatically, you can try unlocking and mounting it manually with cryptsetup luksOpen /dev/sdXn my_jbod followed by mount /dev/mapper/my_jbod /mnt/. It’s also worth checking /etc/fstab and /etc/mtab to see if the update removed the mounting configuration. Running systemctl list-units --failed can help identify any failed storage-related services.

If nothing works, try shutting down the NAS, removing and reinserting the JBOD drive, and rebooting. If the drive still won’t mount, backing up your data and doing a factory reset might be the last resort. Since the RAID volume mounted fine but the JBOD didn’t, this looks like a software issue rather than a hardware failure. If you find any specific errors in the logs, they might point to a fix.

5

The OS update may have messed up the mount configuration for your JBOD volume. Since you can unlock it on Linux Mint, the LUKS encryption isn’t the issue. Try these steps via SSH on your EX4100:

  1. Check if the drive is detected:

    lsblk
fdisk -l

  2. Verify if the LUKS partition is unlocked:

    cryptsetup status <your_volume>

  3. Manually attempt to mount it:

    mount /dev/mapper/<your_volume> /mnt

  4. Check logs for errors:

    dmesg | tail -50
journalctl -xe

If the NAS update changed mount points or permissions, you might need to manually adjust fstab or re-import the volume in the UI.

6

Hi, thanks for the reply.

My EX4100 runs on BusyBox when SSH’ed in. It looks like these commands are not available:

lsblk
fdisk
journalctl

As for verifying if unlocking LUKS works, yes. I can manually mount the drive and all the data is there.

For fstab, I don’t think this NAS OS operates the same way to mount encrypted volumes. fstab doesn’t even list the RAID volume that is working normally, let alone the JBOD that is not. Here’s the output:

root@WDMyCloudEX4100 ~ # cat /etc/fstab
proc /proc proc defaults 0 0
/dev/ram0 / ext2 defaults 1 1
sysfs /sys sysfs defaults 0 0
mdev /dev tmpfs defaults 0 0

and here’s the mtab output:

root@WDMyCloudEX4100 ~ # cat /etc/mtab
/dev/root / ext4 rw,relatime,block_validity,delalloc,barrier,user_xattr,acl 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1040416k,nr_inodes=24066,mode=755 0 0
sysfs /sys sysfs rw,relatime 0 0
mdev /dev tmpfs rw,relatime 0 0
proc /proc proc rw,relatime 0 0
cgroup /sys/fs/cgroup cgroup rw,relatime,cpu,memory 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
ubi0:config /usr/local/config ubifs rw,relatime,ubi=0,vol=0 0 0
squash /usr/local/tmp ramfs rw,relatime 0 0
/dev/loop0 /usr/local/modules squashfs ro,relatime 0 0
tmpfs /mnt tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,nr_inodes=0 0 0
tmpfs /var/log tmpfs rw,nosuid,nodev,noexec,relatime,size=40960k,nr_inodes=0 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noexec,relatime,size=102400k,nr_inodes=20000 0 0
/dev/md0p1 /usr/local/upload ext4 rw,relatime,data=ordered 0 0
/dev/sdb4 /mnt/HD_b4 ext4 rw,nosuid,nodev,noexec,noatime,nodiratime,nobarrier,quota,usrquota,grpquota,data=ordered 0 0
/dev/sdc4 /mnt/HD_c4 ext4 rw,nosuid,nodev,noexec,noatime,nodiratime,nobarrier,quota,usrquota,grpquota,data=ordered 0 0
/dev/sda4 /mnt/HD_a4 ext4 rw,nosuid,nodev,noexec,noatime,nodiratime,nobarrier,quota,usrquota,grpquota,data=ordered 0 0
/dev/mapper/md1 /mnt/HD/HD_a2 ext4 rw,noatime,nodiratime,nobarrier,quota,usrquota,grpquota,resgid=990,stripe=32,data=ordered 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0

from mtab, /mnt/HD_c4 (of the JBOD) is mounted & accessible.

However, /mnt/HD/ directory does not have have the data partition mounted.

root@WDMyCloudEX4100 mnt # ls -la
drwxrwxrwt 8 root root 160 Feb 25 02:23 .
drwxr-xr-x 20 root root 1024 Feb 25 02:24 …
drwxr-xr-x 3 root root 60 Feb 25 02:23 HD
drwxr-xr-x 6 root root 4096 Feb 25 01:49 HD_a4
drwxr-xr-x 6 root root 4096 Feb 18 17:06 HD_b4
drwxr-xr-x 4 root root 4096 Feb 18 17:06 HD_c4
drwxr-xr-x 2 root root 40 Feb 25 02:23 USB
drwxr-xr-x 2 root root 40 Feb 25 02:23 isoMount
root@WDMyCloudEX4100 mnt # ls -la HD
drwxr-xr-x 3 root root 60 Feb 25 02:23 .
drwxrwxrwt 8 root root 160 Feb 25 02:23 …
drwxrwxrwx 15 root root 4096 Sep 4 2023 HD_a2

At the end of mtab, I noticed there’s no mapper for the JBOD, but not sure where to go from here. Should I try adding a line for /dev/mapper/md2 /mnt/HD/HD_c2 ext4 ?? I don’t want want to do something that might make the NAS upset

edit: I looked in the /dev/ directory and there is no md2, but there is an md0 which can possibly be the one for the JBOD. I am a little confused because I setup the RAID volume first long before setting up the JBOD to use to store media to work with Twonky Server.

edit 2: doing some reading, a JBOD is probably not using the RAID naming convention that starts with md, so the md0 that is in my /dev/ dir probably doesn’t mean anything.

edit 3: OK, I am at a standstill. I’m not in a rush to take the jbod back out and wipe it completely (after moving my media files from it), then re-inserting it into the NAS to start the new volume procedures. Maybe someone in the forum will know exactly what is going on after the 5.30 update – and I, myself, would love to know what it is too. I hate giving up easily.

1 Like