ASUSTOR Community Forum

phantasmnz wrote:I guess I agree - it was just annoying me that I couldn't work out what was overwriting it each boot. To be fair - I guess if I had to support it, I'd want the critical files to be as untamperable as possible too.


Sent from my iPhone using Tapatalk

It's probably loaded from flash into a ramfs, i.e. it's in a directory that only exists in RAM (not physical disk). It's not so much that it's overwritten at boot, than it is the fact that it goes away when you shut down.

Great tip. Thanks.

Guys, updated to 2.2.2 and have had this stop working for a script that I have normally set to run on startup.

Any tips on where to start fault finding this issue?

If I run the script manually from /usr/local/etc/init.d it runs fine as it as done for the previous 12 months.

Edit: No matter, wasnt an issue with the mentioned process, looks like the start-stop-daemon, did not like the script.

The shebang at the start was wrong but for some reason if it was launched from a terminal it worked fine. From the daemon though, it did not and I did not have a logging setup in the start-stop script.

Just want to double check that this will work for auto-starting a script on bootup..

If I place the line:

@reboot /volume1/misc/maraschino/Maraschino.py

in this file:

/var/spool/cron/crontabs/root

the script will run every time the NAS reboots?

Updates: It doesn't appear that this works. This is a standard Ubuntu Linux method of making scripts start on boot up, but for some reason, it appears that this just doesn't get seen or work correctly.... Will try a couple of other things and post results here.

OK, after delving in to the @reboot and trying to get a python script to auto start, it appears there is no way to make this work with the current implementation of the NAS's cron.

This will require a bit of rework from Asustor to make what is considered an industry standard method to start scripts. I will be opening a ticket with Asustor to get this on their plate.

In case anyone else had any issues with this, my scripts stopped starting automatically from 2.4.0. I contacted Asustor and they have suggested the scripts now need to be called S<number><name>.sh e.g. S99start.sh

Without the .sh mine wont run anymore, but add .sh and it will run normally again. So instructions may need to be updated now...

Curious but how does this differ from editing the ROOT file in volume0 to run startup scripts? I'm adding several scripts to automate the process of converting video files using FFMPEG and see different instructions that show you add the lines of code in the Crontabs/root file.

Also, does it matter if you edit the Root file by using WinSCP and logging in as Admin instead of root? Do these edits have to be done through a terminal window like in PuTTy?

Thanks

Just for information I just did a auto mount network share script and it works...

I added a script in the directory as told and I named it S00NS.sh so what I got:

/usr/local/etc/init.d/S00NS.sh

inside I put my mount shell command and everything worked.

#!/bin/sh
mount -t cifs -o username=XXXX,password=XXXX,sec=ntlm //10.0.0.1/XXXX /volume1/XXXX


I had to add the line sec=ntlm to be able to mount my apple time capsule. I'll work the script to relocate my username and password but it's a good start...

I did it also but for an NFS share from a Netgear NAS.

/usr/local/etc/init.d/S00NAS1.sh

#!/bin/sh
# author: Data Dan
# date: Feb 27 2018
# purpose: To mount shares from DAN_CAVE_PRO
mount –t nfs 192.168.2.22:/media /volume1/NAS1
#end

My first attempt failed when I tried to add the script using Winscp, it ran the script as 'admin'
I had to use putty, login as 'root' and create the script with the 'vi' command.

I'm not sure what will happen if it can't find the remote share at reboot for whatever reason but for now it works fine!