I have a duplicity backup script set to run once per day through the root cron tab.

I set it up like this:

sudo crontab -e -u root

and added the line:

00 03   *   *   *  root   /home/[myusername]/Scripts/Backups/DuplicityBackup.sh

the script has commands to write to a text file like this:

echo "Creating backup of data directory"
PASSPHRASE='[mypassword]' duplicity /usr/share/nginx/data file:///dysonbackup/datadir &>> /home/[myusername]/Scripts/Backups/backup_logs/data_backup_log.txt

echo "Done"

Running the script itself as root starts the backup and writes to the text file.


sudo crontab -l

shows it listed


grep DuplicityBackup.sh /var/log/syslog


May 28 03:00:01 [myservername] CRON[89749]: (root) CMD (root   /home/[myusername]/Scripts/Backups/DuplicityBackup.sh)

so I am assuming it at least triggered to run, but there is no new information on the text file.

And it does not appear that the duplicity backup is running as there are no new files in the backup directory.

Ubuntu 20.04

duplicity 0.8.12

  • Did you look in root's mail for any output? – meuh May 28 at 12:27
  • I can't find the root mail. cd /var/mail/root bash: cd: /var/mail/root: No such file or directory – dysonsphere May 28 at 16:12

Excessive field

sudo crontab -e -u root edits crontab for the user root. This is different than the system-wide crontab (/etc/crontab). The former uses entries in a form of

m h  dom mon dow  command

and the latter uses

m h  dom mon dow  user  command

You used the latter syntax where you should have used the former. The tool tried to run

root   /home/myusername/Scripts/Backups/DuplicityBackup.sh

Solution: either move your job to /etc/crontab as-is; or fix the syntax by removing root.

If it's not enough then keep reading.

No shebang?

Does DuplicityBackup.sh contain a shebang that specifies Bash as the interpreter?

cron will run /home/myusername/Scripts/Backups/DuplicityBackup.sh in sh. If there is no shebang the situation is complicated in general, but sh should run it in sh, regardless of who provides sh (there are different implementations, compare this).

When you run the script from Bash, it gets run in Bash.

&>> you used is a bashism. In Bash &>> file is equivalent to >> file 2>&1 and this is what you want. In sh it's equivalent to & >> file and this is not what you want.

Solution: use a shebang.

Inaccessible /home/myusername?

/home/myusername may not be available because:

  • /home/myusername is automatically unmounted when myusername logs out (especially possible if it's encrypted);

  • or /home/myusername is mounted as FUSE without allow_other and therefore cron running as root cannot access it;

  • or cron is run by systemd and the service (cron.service) uses ProtectHome= or InaccessiblePaths= to restrict access to /home/myusername (not likely though).

Solution: do not use /home/myusername with cron jobs run by root.

| improve this answer | |
  • Thanks. I will try your first suggestion and see if it runs in the morning. I do have : #!/bin/bash at he start of the .sh file. If it doesn't run I will try your 3rd suggestion. – dysonsphere May 28 at 16:11
  • The first suggestion did the trick. Thanks! – dysonsphere May 29 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.