It looks like cron(ie) does not get installed by default in Fedora 32. qvm-service [appvm] crond only determines if the service is “enabled” from a Qubes OS perspective. The issue here is that the packages for cron aren’t even installed - perhaps this is a Fedora 32 template bug? My Debian 10 template already had cron installed by default.
In your Fedora 32 template, execute:
sudo dnf install cronie
Shut down the template and your AppVM.
Ensure you have the crond service enabled by Qubes; in dom0:
qvm-service [appvm] crond on
Now, cron will be enabled in the appvm. To verify, boot the appvm, and check:
systemctl status crond
Result should have Active: active (running) (on Debian, change crond to cron).
This the baseline - making sure cron(d) is running before changing anything. If the above doesn’t check out, you have to resolve that first.
At this point now you can make your changes.
When you enable crond from Qubes OS (with qvm-service), Qubes redirects the crontabs that would normally be stored on the root file system to be to be stored persistently within the AppVM under /rw/bind-dirs/var/spool/cron. The system-wide root crontab at /etc/crontab is not affected.
To stay in the “Qubes OS” lane as well as being a little more declarative, I would suggest to leave /etc/crontab alone and place your cron entries in the crontab for the user user.
In your appvm, have these files:
-
~user/backup/backup.sh: Performs the backup commands -
~user/backup/crontab: Contains crontab entry to exec backup.sh:* * * * * ~user/backup/backup.sh
Assuming you have no other crontab things to add for this AppVM, set the crontab for the user:
$ crontab ~user/backup/crontab
Logs? Check journalctl -u crond in Fedora or journalctl -u cron in Debian. This will tell you when crond is triggered.
If your backup.sh script generates output, check user’s mail with the mail command. Or, make sure backup.sh redirects output within the script itself to a file…or change the crontab…etc.