I'm running Kubuntu.

I've written a bash script that backs up my configuration files, 7zips them, uploads the archive to dropbox, and then deletes the local archive.

It runs beautifully.

I then added a cron job to have this script executed weekly. It always places the 7zip file in my home directory and then the file doesn't get uploaded. I've tried using absolute directory references rather than relative ones all to no avail.

It runs fine when I manually execute it. But it breaks when cron runs it.

It's driving me mad! Has anyone else experienced this and do you have any help/suggestions/tips/answers as to how to make the script work when it's run as a cron job?

Usually things like this occur due to the differing environment when run as cron, typically paths. You say that you have used absolute paths, but no one can tell you much more without actually seeing the script.

Please post a minimal example script which illustrates the actual problem.

Such behavior is almost always about the lack of an environment when running from cron.
You mention using absolute paths...does that include absolute paths to the executables as well as the source and zipped files?

Here's an example that has been simplified with less backup directories and my username removed. The zip file creates perfectly fine, with all of the files I want it in, but then nothing else happens.

Now that I'm looking at this, is it possible that cron is not executing the command "droptobox" due to privilege issues? If so, what's the easiest way to correct that while still be secure?

1 members found this post helpful.

1 members found this post helpful.

I am not a dropbox user so cannot comment on how it handles permissions, but if your example reproduces the problem then that is a very good place to start!

The link and posts provided by NevemTeve above are a very good reference for troubleshooting your shell scripts, give those a look!

1. which dropbox to determine the absolute path to that command.
2. put the absolute path in your script.

As others have mentioned, use absolute paths in you script. It will NOT run as a cron job as you have shown here. Running it as a user of some sort it has a PATH variable in the environment. Running it as a cron job, regardless of the user, it has NO PATH to refer to so the programs simply cannot be found. Find out where they are on your machine (/usr/bin/, /usr/local/bin/ or wherever) and use the complete path for each program.

Alright! I'm going to give it a go. That makes perfect sense.
I've added the absolute path in and (I'm a bit lazy) so I'm waiting until Monday for the next run...
That's why I made the script in the first place...

Mind you, if it is a GUI-application then it certainly won't work from cron.

Absolutely. Thanks for the reminder! This is 100% terminal and can run behind the scenes.

I experienced a similar problem. The problem was caused by using an environmental variable. In my case, the use of, "$SECONDS". From your post it is unknown if any environmental variables were or were not used. See this old post. Bash script works in terminal but not in cron.

I've tried with the absolute paths and it still doesn't work.
This time it didn't even zip the file up like it has in the past.

Have you checked your permissions? When a program runs from cron, it usually executes as root. When you run a program from terminal, you are usually running it as yourself. Unless you are executing the script with sudo.

What doesn't work? You need to show us the script and the relevant directory and file permissions or we can't help.