Right. So as root, shouldn't the script have access to all permissions? I wouldn't think I would need to modify them (but I could be wrong).

When I execute the script from the terminal (and it works perfectly) it does so as a regular user with no sudo escalations.

I already did...it is posted above.

Are you talking about in your script or in crontab? If the cron command doesn't use full paths it won't run. So in cronttab you need something like

Ah, sorry, I thought you were trying something different and was not waiting anxiously for Monday's test.

Still, it would be helpful if you could be explicit about what exactly is different from the previous run so that others can follow more easily.

What is different is that I added in the absolute path to the command "droptobox" and now the cronjob doesn't even zip the file as it did previously.

It depends. If your running crontab -e to add the cron job then it will run as that user unless you specify the user via the -u option. System cron jobs i.e /etc/crontab or /etc/cron.d run as the specified user in that cron job itself. /etc/cron.daily,hourly and monthly always run as root as far as I know.

In the posted script all /etc/ files are world readable so running as root is not required. What dropbox uploader script are you using? The one I found has a test to check and exits if not bash.

https://github.com/andreafabrizi/Dro...ox_uploader.sh

There might be something specific to your droptobox script that could be causing the problem.

Did you also add the absolute path to the zip command?
Everything in a script run from cron needs an absolute path...

1 members found this post helpful.

No. I'll try that too. I didn't think the zip would since it worked before. I'll give it a go, thanks!

A typical cron default path environment is PATH=/usr/bin:/bin. Both 7z and the date command are located in /usr/bin which is why your original script could successfully create the archive. droptobox is probably located somewhere else which is why it failed to run from cron. You might of made a syntax error etc when modifying the script to include absolute paths.

I doubt that there's a syntax error since it executes fine from the terminal manually with the absolute paths.

It would also help to see exactly how your script is called from cron. Is this script be run as 'root' or 'you'? cron will allow you to do either. If it can be run as 'you' it should not be run a 'root'.

I would suggest also generating a logfile. This can be done by redirecting all the output to a file:
yourscript > /home/you/backup.log 2>&1
This will redirect stout & stderr to the file.

Chances are the output give us a pretty good idea about what the problem is. It would also allow you to add some 'debug' code to you script.

Thank you everyone for your help! I was finally able to get this working.
It seems very silly, especially because the 7z program executed without the full path being included, but the script didn't go further than that. I added the full path for 7z as well, and now everything works flawlessly.

I very much appreciate the help and suggestions!

@OP: How did you try to debug? Tried `set -xv`? Have you read this: https://www.linuxquestions.org/quest...0/#post5707383 ?