OS5 broke remote backups on EX2 Ultra

My Cloud OS 5 Personal & Network Attached Storage My Cloud EX Series
1

I have two EX2 Ultras, on OS3 one used to run a sync job with the other. Both NASs are on the same LAN and it all used to work no problem.

Since upgrading both boxes to OS5 and installing the Remote Backup app, I can’t get any backup jobs to run. I’m confident that my passwords are correct as I can successfully create the jobs and when I intentionally enter incorrect passwords, I can’t browse the remote shares to create the jobs.

In all cases, even with newly created shares and newly created backup jobs, the jobs fail to run. As I said, both NASs are on the same LAN and the same setup used to work fine under OS3.

I’ve contacted WD support but just got the stock response and on telling them that I’d already tried everything in the knowledgbase, I haven’t heard back since. I tried the escalate button but I’m not convinced that it really does anything.

I’ve looked through the device logs but the error messages in there aren’t any more meaningful than the generic fail message in the notification centre. It looks like others are having remote backup issues with OS5 too. Has anyone resolved or at least found a way to get more detailed logs that might point to the reason remote backups are failing?

2

Remote Backup doesn’t work anymore. I tried every single possibility. Nothing.
And no answer from WD.
Their customer satisfaction index should dramatically drops with this OS5.
It is a disaster.

2 Likes
3

Same here. Didn’t change anything. Port forwarding set.
Destination NAS just isn’t listening on port 873.

4

@electronicsuk @pym Thanks for posting the issue with Remote Backup job failure.
If you’re interested, here are some steps to help troubleshoot the issue assuming the Remote Backup Job starts the rsync process and the rsync fails and captures logging.

NOTE: We’re aware of the double directory path issue created on the destination and working on a fix in a future Remote Backup app release.

TROUBLESHOOTING REMOTE BACKUPS:

  1. Enable SSH and Log into the My Cloud

  2. Start a Remote Backup job

  3. Run the ‘ps -ef | grep sync’ command to get the backup job information

root@MyCloudPR2100 ~ # ps -ef |grep sync
386 root 9388 S rsyncmd -b -r PR2100
453 root 40748 S /usr/sbin/rsync --job-name=PR2100 -aHq8 -e /usr/bin/sshpass -p XXXXXX ssh -ax -o StrictHostKeyChecking=no -o HostKeyAlgorithms=+ssh-dss -c aes128-ctr -l sshd --delete --timeout=600 --exclude .AppleDouble --exclude .AppleDB --exclude .DS_Store --exclude .bin --exclude .AppleDesktop --exclude Network Trash Folder --exclude .!@#$recycle --exclude lost+found --exclude Nas_Prog --exclude Ajaxpf --exclude .systemfile --exclude P2P --exclude aMule --exclude .!@$mmc --exclude .wdmc /mnt/HD/HD_a2/Public sshd@192.168.0.20:/mnt/HD/HD_a2/Backups/WNAP26440012_MyCloudPR2100/PR2100/Public/ --dump-size --dry-run
454 root 2580 S /usr/bin/sshpass -p zzzzzzzzzzzz ssh -ax -o StrictHostKeyChecking=no -o HostKeyAlgorithms=+ssh-dss -c aes128-ctr -l sshd -l sshd 192.168.0.20 rsync --server -nlHogDtpre.iLsfxC --timeout=600 --delete . /mnt/HD/HD_a2/Backups/WNAP26440012_MyCloudPR2100/PR2100/Public/
455 root 8984 S ssh -ax -o StrictHostKeyChecking=no -o HostKeyAlgorithms=+ssh-dss -c aes128-ctr -l sshd -l sshd 192.168.0.20 rsync --server -nlHogDtpre.iLsfxC --timeout=600 --delete . /mnt/HD/HD_a2/Backups/WNAP26440012_MyCloudPR2100/PR2100/Public/
1114 root 4704 S grep sync

  1. Stop the Remote Backup Job or let it fail

  2. Replace the VARIABLES in the command listed below with the information from your backup jobs output

PASSWORD: your remote NAS SSH password
JOBNAME: the name of your Remote Backup Job (PR2100)
PATH_TO_SOURCE_SHARE: absolute path to the share from the sync job output (/mnt/HD/HD_a2/Public)
DEST_IP_ADDRESS: the IP Address of the remote NAS (192.168.0.20)
PATH_TO_DESTINATION_SHARE: the absolute path to the destination share (/mnt/HD/HD_a2/Backups/WNAP26440012_MyCloudPR2100/PR2100/Public/)

SSHPASS=‘SSH_PASSWORD’ /usr/sbin/rsync --job-name=‘JOBNAME’ -vvvvaHq8 -e ‘/usr/bin/sshpass -e ssh -ax -o StrictHostKeyChecking=no -o HostKeyAlgorithms=+ssh-dss -c aes128-ctr -l sshd’ --delete --timeout=600 --exclude ‘.AppleDouble’ --exclude ‘.AppleDB’ --exclude ‘.DS_Store’ --exclude ‘.bin’ --exclude ‘.AppleDesktop’ --exclude ‘Network Trash Folder’ --exclude ‘.!@#$recycle’ --exclude ‘lost+found’ --exclude ‘Nas_Prog’ --exclude ‘Ajaxpf’ --exclude ‘.systemfile’ --exclude ‘P2P’ --exclude ‘aMule’ --exclude ‘.!@$mmc’ --exclude ‘.wdmc’ ‘PATH_TO_SOURCE_SHARE’ ‘sshd@DEST_IP_ADDRESS:PATH_TO_DESTINATION_SHARE’ --log-file=/shares/Public/backup.log &

  1. Copy and run the command on the My Cloud using SSH using your job details

EXAMPLE COMMAND:
SSHPASS=‘YOUR_SSH_PASSWORD’ /usr/sbin/rsync --job-name=‘PR2100’ -vvvvaHq8 -e ‘/usr/bin/sshpass -e ssh -ax -o StrictHostKeyChecking=no -o HostKeyAlgorithms=+ssh-dss -c aes128-ctr -l sshd’ --delete --timeout=600 --exclude ‘.AppleDouble’ --exclude ‘.AppleDB’ --exclude ‘.DS_Store’ --exclude ‘.bin’ --exclude ‘.AppleDesktop’ --exclude ‘Network Trash Folder’ --exclude ‘.!@#$recycle’ --exclude ‘lost+found’ --exclude ‘Nas_Prog’ --exclude ‘Ajaxpf’ --exclude ‘.systemfile’ --exclude ‘P2P’ --exclude ‘aMule’ --exclude ‘.!@$mmc’ --exclude ‘.wdmc’ ‘/mnt/HD/HD_a2/Public’ ‘sshd@192.168.0.20:/mnt/HD/HD_a2/Backups’ --log-file=/shares/Public/backup.log &

  1. Use the ‘cat’ and or ‘tail’ command to see the output

    cat /shares/Public/backup.log
    tail /shares/Public/backup.log

1 Like
5

Thanks @SBrown, this is the first proper help I’ve had from anyone at WD so far. You have, indirectly, solved my problem.

ps -ef | grep sync wasn’t producing a lot of output for me, but I still managed to get enough details to run the full rsync job from the command line easily enough. When I ran the job, I got this output:

-sh: can't open XXXXXX no such file
root@NAS-Wesleyan HD_a2 # -sh: ’: not found

Now, XXXXXX were the first 6 characters of my password (redacted for obvious reasons). The next character along in the password was a dollar sign followed by another special character. I figured that the password was probably being interpreted as a command, so I changed it to something with no special characters. I ran the job again from inside the OS5 Remote Backups app and guess what, it ran first time!

It didn’t occur to me that during the OS3 to OS5 upgrade, I’d changed my password to something more secure. This problem may also have existed under OS3, too. It’s also a bit disappointing to learn that passwords are probably being sent plain text over an unencrypted SSH session.