0

I have a deja-dup set up to backup into a mounted Truecrypt volume. It works fine but now I would like to run deja-dup in my own intervals via Cron (set up for my account):

* * * * * env DISPLAY=:0 deja-dup --backup (the every-minute schedule is just for testing)

The job is started fine but deja-dup outputs that the destination is not available:

enter image description here

If I try to set up the Cron job through the "Scheduled Tasks" GUI and select it to be "X application", it's added to the Cron jobs as:

* * * * * /usr/bin/python /usr/share/gnome-schedule/xwrapper.py c 2 # JOB_ID_2

However, when the job is run, it fails in the same way as with my own Cron setting.

As the task starts just fine if I run it from terminal, my assumption is that for some reason the task started via cron doesn't have permission to access the mounted volume.

Q1: As the task is started from my user's Cron settings and should therefore run as my user, why wouldn't it have access to a mounted volume?

Q2: Could the reason of failure be something else than permissions?

Q3: Can you suggest some solution for this problem?

  • If you've set up your cron command with your user it runs with the user permissions. Can you post the output here? You ALWAYS should use full and absolute paths to your commands when using it with cron. Maybe the deja-dup needs an configuration flag (environment) that is not set in cron.... – Wolfgang Mar 9 '14 at 17:27
  • I've added an image of the deja-dup output. It must know the configuration because it knows that it should backup to the '32 GB Volume' which is the mounted Truecrypt volume (and it truly is mounted). If I run deja-dup --backup it starts the backup just fine. – tmt Mar 9 '14 at 17:41
  • I've tried to set the full path to deja-dup as you suggested just to rule this out as a possible issue. It hasn't changed anything. – tmt Mar 9 '14 at 18:15
  • we need more information: is your destination just another hdd (please post what "mount" gives out) and show us your deja-dup configuration... – Wolfgang Mar 9 '14 at 19:42
  • The destination is a mounted Truecrypt container that otherwise physically resides on the same HDD. mount gives this output parts related to the given container: truecrypt on /tmp/.truecrypt_aux_mnt3 type fuse.truecrypt (rw,nosuid,nodev,allow_other) and /dev/mapper/truecrypt3 on /home/cascaval/Backup type ext4 (rw). – tmt Mar 9 '14 at 22:59
1

Based on answers for other question, I managed to find the solution myself. It consists of starting deja-dup with a script that adds some system variables. The cron job then obviously runs the script.

#!/bin/bash

export DISPLAY=:0

sessionfile=`find "${HOME}/.dbus/session-bus/" -type f`
export `grep "DBUS_SESSION_BUS_ADDRESS" "${sessionfile}" | sed '/^#/d'`
export `grep "DBUS_SESSION_BUS_PID" "${sessionfile}" | sed '/^#/d'`
export `grep "DBUS_SESSION_BUS_WINDOWID" "${sessionfile}" | sed '/^#/d'`

deja-dup --backup
exit 0

NOTE: If somebody comes up with a well-written answer that not only provides this or other working solution but that also explains the reason for the problem, what DBUS session is and what role it plays in this problem, I'll gladly accept your answer instead of this one.

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.