How to do a scheduled reboot of my WD MyCloud EX2 Ultra?

How to do a scheduled reboot of my WD MyCloud EX2 Ultra? I am a non technical person , please explain me step by step.

Your help is much appreciable

You will need some linux savvy, I’m afraid. There is not an “Easy” solution that I know of. Certainly not one that involves a GUI.

“best” way is to hijack the init script of an installed application on the mycloud (say plexx server, or the like), so that it sets a cron job that does it for you. (this is because the EX2 and EX2 ultra do not have persistent root file systems, so you cant set a cron job and leave it. You have to set the job every boot. :frowning: )

Alternatively, you can turn on SSH on the box, and then fire an RSH command at it at a scheduled time that tells it to reboot, using a computer on the same network.

These really aren’t that hard, you just have to know what you are doing. A little research into how to use cron, or rsh would point you in the right direction.

As for step by step… OK…

[method 1, hijack an application’s init script; set cron job]

Enable SSH on the mycloud
Using something like PuTTY (or native ssh, if you have a mac or linux), ssh into the box.
Navigate to the folder where your application you are hijacking is installed. (in this example, Transmission)

The file you would edit is “init.sh”
This file gets run when the box starts, and is what starts up the transmission daemon so the box can download torrent files for you. We want to make it ALSO append our cron job to the crontab.

So we edit it with vi.

vi init.sh

vi opens, and displays our file:

vi is a big cranky to use, but is the only native text editor baked into the mycloud units. To begin editing, first press the [a] key on the keyboard, then use the arrow keys to move around. Move to the bottom of the file, and add the needed section to inject a new entry into the crontab. Like this.

Press the [esc] key, then type [:wq] then press [enter] That will save the modified init.sh.

We are making use of the “append” feature of the echo command here. Normally, echo writes whatever you put in the single quotes to the console, but you can redirect that output into a text file with the > and >> operators. > overwrites the file, and >> appends to the bottom of the file.

Here is an explanation of all those * * * entries in the injected line:

 # * * * * *  command to execute
 # │ │ │ │ │
 # │ │ │ │ │
 # │ │ │ │ └───── day of week (0 - 6) (0 to 6 are Sunday to Saturday, or use names; 7 is Sunday, the same as 0)
 # │ │ │ └────────── month (1 - 12)
 # │ │ └─────────────── day of month (1 - 31)
 # │ └──────────────────── hour (0 - 23)
 # └───────────────────────── min (0 - 59)

After that, just reboot the box, and it should set the cron job right after it starts the transmission daemon on every boot. When the correct condition is encountered (In this case, at 1800, or 6:00pm) the command will be executed. (in this case, the reboot command)

I’m not Linux savvy, but followed these step by step instructions, and all worked perfectly upon test. I added the cron job to init.sh of my Plex Media server. I set it for a time 10 minutes after appending the cron job to init.sh, rebooted the NAS, and at the specified time it rebooted. I then went to the NAS’ log and saw the reboot in the log.

Once sure it worked, I changed the cron job to 5 in the morning, rebooted and thought all was good. Next day I went to the NAS’ log via the console and expected to see the reboot at 5am listed, but it was not. All the log showed was the reboot after changing the hour in the cron job. When I look at my cron jobs (crontab -1 at root), reboot is listed with the correct desired daily reboot time.

Can anyone explain to me if there’s something I’m missing? All I’ve done is changed the hour.

Thanks,
Ron

What hour did you specify?

I can only really think of one possible sticking point, and that is if you are trying to use midnight as the hour, and are incorrectly specifying ‘24’ as the hour, instead of ‘0’. (there is no such hour as 24:00, Only 0:00)

Thanks so much Wierd_w for responding to a post 2 years later. I have the job set to run daily at 9am. Here’s exactly what init.sh for plexmediaserver looks like now. Any further suggestions would be greatly appreciated. You’ll note that this reboot is on my PR4100. I also have an EX2Ultra. The linux commands should work identically the same on either NAS.

Further update. I tested again, by setting some times for reboot. It’s hit and miss. Some execute and some don’t. I’ve now set it for 5 am and we’ll see what happens tomorrow. FYI, here’s a snapshot of my crontab -l
Screen Shot 2021-06-16 at 11.39.52 AM

I will examine what is being run by the internal scripts when I go home later today.
‘expire.sh’ might be an interesting read.

It looks like the box tries to do some things at midnight that might potentially cause issues (eg, wants to return to a sane/clean slate condition-- and given the lack of persistence in the root FS, could be part of the issue)

I will dig into it more later, when I have access to my EXT2 Ultra.

Sorry about the very late reply. (2 years is quite the wait.) I got busy doing some other stuff before the pandemic, and then got VERY VERY busy during the pandemic. (I work in healthcare.) I logged in to see if there were any topics that needed answering after remembering about this place, and had the little blue notification. So I answered. shrug

I really appreciate you digging into this for me. When I did a google search for how to set a reboot for the WD NAS, your post was near the top of the list and the only one, for a non-savvy Linux person like me, that was understandable. Others were quite technical and not helpful. I loved your step by step instructions to the non-savvy Linux person, like me who was the original poster.

The hijacking of init.sh to add the echo append works brilliantly, as you can see by my listing of what’s in crontab -l. I set the reboot for 5am for both my EXUltra and my PR4100. The crontab -l listings are almost identical for each NAS.

My hats off to you as a healthcare worker. They are the true heroes of the past year+. No hurry for a response. BTW, I was not waiting for your response for 2 years. I had only stumbled upon it several weeks ago when trying to initiate the reboot for my NAS.

Oh, and FYI, the 5am reboot did not execute on either NAS.

Thanks,
Ron

As I mentioned in previous reply, neither reboot commands executed at 5am this morning. I wrote that prior to taking a look at what’s in crontab. I just looked at both NAS devices crontab list, and see that the reboot command, which was the command in each respective list, has disappeared. See screenshot of the crontab list for both my NAS devices.

Most of what I am seeing in here is log rotation stuff.

I am going to add a crontab entry that basically records the current time, (hour and minute) every minute. I will then track down when the job stops working.

That will help me narrow down what part of the default crontab is nuking the crontab table.

So far so good-- it is recording the output of date into a persistent file every minute. I will check it after 24hr, to see when it fails.

OK. My experiment has yielded fruit.

The crontab gets nuked at midnight.

Further testing:

The line:

0 0 * * * random_check -s&

is responsible for the reset of the crontab. This is not a script, but is a WD supplied binary.

It takes about 1 to 2 seconds to complete on manual invocation. I suggest another kludge:

In addition to your reboot cron entry, have another that contains a simple “wait” timer, that activates 1 to 2 minutes prior to midnight. It should activate (and thus, be in the process of firing!) before the offensive WD program does, and can wait out the program’s execution. It can then re-add the crontab entry.

Say, something like this:

[crontab]

....

58 23 * * * /mnt/HD/HD_a2/KeepCrontab.sh
0 5 * * * reboot

[KeepCrontab.sh]

#!/bin/bash
# Wait 125 seconds (2 minutes + 5 seconds), then add these entries to crontab
sleep 125
echo '58 23 * * * /mnt/HD/HD_a2/KeepCrontab.sh' >> /var/spool/cron/crontabs/root
echo '0 5 * * * reboot' >> /var/spool/cron/crontabs/root 

make sure the KeepCrontab.sh file is executable.

chmod +x /mnt/HD/HD_a2/KeepCrontab.sh

This kludge would fire at 2 minutes before midnight, (and thus, before the offensive WD program)-- and would be waiting for the WD program to fire, and then finish-- then it would do its work, and re-add the crontab entries. The scheduled reboot should then happen at 5 am.

Thanks so much for the time you spent troubleshooting and experimenting in order to determine the cause and solution. I will add these commands to my init.sh file and see what happens.

I will be leaving on a 2 week vacation, later today, but will have the ability to remote into my home network to at least check on both NAS devices. However, it might not be convenient to terminal in if any changes are needed (sporadic internet connectivity), so I might have to wait to do so until I return.

I’m not a computer professional, but love to tinker and wish I understood this stuff better. Again, really appreciate you looking into this for me and I will report my results.

It’s interesting that the original poster, from 2 years ago that asked for help, and you kindly responded with the step by step instructions, never further replied nor did anyone else, until I came along.

Take care and I’ll be back to you.

I’ve added above commands, repeated below, to the init.sh file and will report back later.

sleep 125
echo ‘58 23 * * * /mnt/HD/HD_a2/KeepCrontab.sh’ >> /var/spool/cron/crontabs/root
echo ‘0 5 * * * reboot’ >> /var/spool/cron/crontabs/root

In the above instruction, sleep 125, where does that go? Should it be an echo command? Doesn’t show up in the crontab list.

Also, when I check to see if the KeepCrontab.sh file is executable (as you suggested) by typing chmod +x /mnt/HD/HD_a2/KeepCrontab.sh, terminal response is No such file or directory. So I’m missing something.

P.S. You don’t know how appreciative I am for your assistance with this!!

A new file is created at /mnt/HD/HD_a2 named KeepCrontab.sh

You can create this file with vi.

vi /mnt/HD/HD_a2/KeepCrontab.sh

It will start a new file with no contents. Edit it like any other file, and add the lines I cited-- specifically:

#!/bin/bash
# Wait 125 seconds (2 minutes + 5 seconds), then add these entries to crontab
sleep 125
echo '58 23 * * * /mnt/HD/HD_a2/KeepCrontab.sh' >> /var/spool/cron/crontabs/root
echo '0 5 * * * reboot' >> /var/spool/cron/crontabs/root 

Then save it.

After you have done that, you need to make it executable.

chmod +x /mnt/HD/HD_a2/KeepCrontab.sh

Think I’ve got it now. Here’s my crontab list after adding this new file.

Screen Shot 2021-06-18 at 12.49.24 PM

And here’s the other NAS

Screen Shot 2021-06-18 at 1.05.44 PM

As previously mentioned, thanks so much for your help and I’ll let you know the results.

Ron

As I mentioned, I have extremely sporadic internet. I’m on a train, traveling across country, so using my phone’s hotspot whenever there’s enough signal.

Let me update you. On the EX2Ultra, the reboot worked just the first day at 5am, as specified in KeepCronTab. However, when I looked at Crontab -l, afterward, those last two commands were no longer there. I then checked the next day, and the 5am reboot, the first one from the previous day, did not execute.

I then looked at the PR4100 and neither did the reboot execute nor is the KeepCronTab command showing in Crontab -l. So it worked one time on one NAS, and not at all on the other one. And the KeepCrontab has disappeared.

I’m not returning home until July 2nd and remoting in and getting to the terminal is not easy. So no rush, if you think of something else. But when you do, I’d be extremely appreciative. Actually I wished I knew my way around Linux so I could experiment myself.

Again, thanks!!

I will look into it more aggressively over the next day or so.

I will see if a longer wait (say, a full 200 seconds, or a whole minute + some change after the offensive program fires, before re-adding) will do the trick.

However, since it fired at 5:00am on the EX2,

I’m back home. Wonder if you’ve had a chance to take a look? The KeepCronTab is gone when I go to list crontab.

Appreciate you help.

Good morning Weird_w:

Still playing around with trying to get this to work consistently. Here’s what I’ve done.

  • Checked that new file is still executable
  • On the EX2Ultra, I left the timer at 125 seconds
  • On the PR4100, I changed the timer to 200 seconds
  • I did not make any other changes to the new KeepCrontab.sh file other than the sleep timer
  • I manually added via cron tab -e, the mount of KeepCrontab.sh at 2 minutes before midnight and reboot at 5am to both crontabs at the root.
  • Both NAS devices rebooted at 5am, however upon inspection of the crontab, this morning, the new commands have disappeared again, so I suspect that it will not reboot again.
  • I’m baffled.

I’ve google searched to the best of my ability to no avail.

Thanks,
Ron

FINALLY GOT IT WORKING!!

The KeepCrontab.sh kludge script was fine and no changes were needed on the sleep timer.

Problem was that I neglected to add the line

echo ‘58 23 * * * /mnt/HD/HD_a2/KeepCrontab.sh’ >> /var/spool/cron/crontabs/root

to the respective init.sh scripts that were being “hijacked”. Once I did that and rebooted, the above, as well as the reboot command, appeared in the crontab -l.

This morning, I first checked each NAS and they both rebooted at 5am. Then I terminaled into each NAS’ crontab and the commands were still there. I fully expect it to work each and every night, from now on.

If not ………….

Thanks again for your patience and help.

Ron

July 26, 2021 Update

The nightly reboot of both my NAS devices, PR4100 and EX2Ultra, have been working flawlessly each and every day. My sincere thanks to Weird_w for taking the time to troubleshoot his original solution and determine why it was not working as intended, and providing the additional script.

For anyone desiring to do scheduled reboots of their NAS devices, as per the request of the original poster, over 2 years ago, I’d be happy to provide a summary of the steps, including the additional needed script added by Weird_w, in order for scheduled reboots to work flawlessly.

Again my sincere thanks to Weird_w for providing the original solution and then taking the time to troubleshoot why it was not working, and coming up with the additional needed script.

Ron

1 Like