SD Card is not mounted, import fails: one of root causes found

Hi all,

I just want to share fix for a bug that was annoying me for a long time.

This will probably affect you only if you have a smartphone with locale settings with number delimiter set to comma “,” instead of dot “.”.
I’m using my My Passport Wireless Pro usually only for SD card backups while traveling.
I’ve noticed that sometimes my WD My Passport Wireless Pro stops recognizing SD cards and not being able to do an SD card backup.
Finally I’ve decided to troubleshoot this issue prior to my next journey.
Luckily this device is linux-based box with SSH access.
I found that device is detecting SD card without issues, but later it’s fails at mount step with next error:
ufsd: failed to mount “mmcblk0p1”. bad option “bias=”
I’ve checked mount script and found that it’s caused by invalid value stored in /etc/timezone_offset file.
I have an android phone with Russian locale settings, with comma being used number delimiter by default.
WD My Passport Wireless Pro updates /etc/timezone_offset each time you’re accessing it through mobile app or web interface.
After you’re logging in using web interface everything works fine and /etc/timezone_offset is populated with “3” value and mount procedure works well, SD card import is started, but when I start mobile app and connect to device, /etc/timezone_offset if populated with “3,00” value, which is not correctly processed inside FW, since FW expect number delimiter to be a dot “.”, instead of comma “,”.

As a big picture it was seen that after you’re logging to device using web interface, SD card import starts working, but when you’re logging in to device using mobile app, SD card import stops working.
To make device to work again, simplest was is to login using web interface again, but I have a patch for REST api inside My Passport Wireless Pro.

How to patch you device to work correctly (you need to know how to use SSH and vi):

  1. login using SSH to your My Passport Wireless Pro
  2. open /var/www/rest-api/api/System/src/System/DateTime/Model/Configuration.php file using vi
  3. apply next patch around line 105:
    $output = $retVal = null;
    - $cmdString = "echo " . $changes['time_zone_offset'] . " > /etc/timezone_offset";
    + $timezone_offset = $changes['time_zone_offset'];
    + $timezone_offset = preg_replace('/,/', '.', $timezone_offset);
    + $cmdString = "echo " . $timezone_offset . " > /etc/timezone_offset";
    exec_runtime("sudo bash -c '($cmdString)'", $output, $retVal, false);

This patch will replace all commas to dots in REST api that changes timezone_offset each time you’re logging into your device using either web interface or mobile app.

Hope this will help someone to solve their issues too and hope WD will integrate this patch into new FW update.

Here is a patched version of Configuration.php: http://ge.tt/9Qj4QEr2

Regards,
Dmitry

1 Like

Hi Dimitry,

good catch! I’ve found the same the issue and in the hurry before leaving for vacations I’ve fixed the scripts using /etc/timezone_offset but I didn’t manage to find the who was writing it :wink:

1 Like

Yeah, nasty bug.
I’ve did not check this community forum, so I’ve been debugging this issue by myself.
Originally I thought that not that many countries are using comma as a decimal separator, but later checked wikipedia and found that there are a lot of countries that use comma instead of dot.
Hope this will last issue with WD MPWP and finally I’ll be able to use if without trouble.
In last firmware they’ve also removed “move” functionality, leaving only “copy”, so I needed to hack also that staff to enable “move” functionality again.
Such good HW with such buggy FW and application, shame on WD QA.

good hw, buggy fw, but at least it’s easy to hack and to customize :wink:
I’ve created a custom image with your fix:

1 Like
$ ssh mypassport
root@mypassport.local's password: 
[root@MyPassport ~]# ls
[root@MyPassport ~]# cat /etc/timezone_offset 
2

after having opened the MyClous app on my phone:

[root@MyPassport ~]# cat /etc/timezone_offset 
2.00
[root@MyPassport ~]# cat /etc/version
1.04.17-fix-tz1

:slight_smile:

1 Like

Hi,
i’ve run into the same bug (Android in France with german settings…) and your fix saved my day! Great work.
For instance i only applied the solution provided by ggrandou, i did not attack via vi (not too accustomed with this editor :wink: ) .
I will give the custom update a try when i’ll return from my vacation at Madagascar :sunglasses:.

Thanks again :grin:
Wilhelm

Shouldn’t this be a problem WD fixes for us. I’m no technician and "hacking’ into the software of MyPassport is something I don’t understand.

Hello.
I think this is exactly the problem i have. But this is far to technical for me. And i think it’s definitely WD part to fix that.
I’m from switzerland, iPad macbook air and MPW ssd are started there. I traveled to French Polynesia (-12h) after that to New Zealand. Since then nothing works anymore. In each country i use a local sim for my mobile.

Now i can nowhere safe my videos and photos.
I already contacted the support an i hope to get soon a solution.

Lukas

I’ve actually went to the trouble of creating a user account here for the sole purpose of voicing my outrage over this situation. The issue has been identified, traced down and worked around by dlebed and ggrandou three months ago (as I write this) and there’s not even as much as an acknowledgment from WD’s side? Seriously, WD?! You’ve been handed down the root cause for the serious issue that shouldn’t have passed your QA in the first place and yet you let countless other users suffer from not being able to use your product’s basic functionality for how long, again?

I’m leaving for a vacation in two days and got myself a MPWP for backing up my photos and videos, in a belief that WD of all people should know a thing or two about data storage. But it’s thanks to the fine people like dlebed and ggrandou - your paying customers and sheer luck of me stumbling upon this thread for saving me a major aggravation during what I hope to be a relaxing vacation, without so much as an “oh yeah, thank you guys for spotting that” on your part. That’s beyond reprehensible.

While I’m with the guys here that the REST API should verify and sanitize any input it receives from the client apps and this very well mandates a device firmware’s update, the bug, in the meantime, could also be worked around by a simple WD MyCloud app update so it would rewrite the data it sends to the drive with proper “dot” separators.

I’m located in Poland (comma as the decimal separator) and currently, after I access the drive with an app on my iPhone, timezone_offset file gets the value of “1.0000”. After accessing with an app on my Android tablet, it gets overwritten with “1,0”.

Way to instill confidence in a data storage company. Unbelievable…

1 Like

Have a nice holiday!

I’ve made the initial fix two days before mine, and I’ve spent my four weeks trip in Australia with my WD Passport without any issue :slight_smile: all my camera sdcards were daily and safely backup’ed on the disk.

1 Like

Just switched my MPW on to check if there’s a new firmware by any chance and, needless to say, nothing. What an incredibly tone-deaf and arrogant company WD is. I’ve recently got a new NAS and although I was using WD Red HDDs before, I didn’t think twice before getting Seagate. WD is as good as dead to me - you’ve got to have some standards.

Please ensure that you are on the latest Android My Cloud Mobile App.

The SD import issue was fixed in My Cloud mobile App version 4.4.11 released on 2/26/2019.
From the release notes,

• Fixed SD card import issue with specific time zone and locale

For best practice when using the SD card import feature we recommend using the latest version of My Cloud mobile App.