I have a backup cronjob that I’m trying to implement.
And then I’m wondering if it’s possible to run qvm-copy automatically? Without a pop-up window.
I realise that currently I have to return to my screen and type in the VM name when away, and that it could interrupt my workflow if I happen to be working at that time.
First time doing something like this, so probably some stuff I could improve upon.
Crontab: 0 5 * * 1 ~/.rc/back
Run at 5 am every week
This will copy from my airgapped VM where the database will be unlocked and modified.
I always make a new file name because qvm-copy fails if the same file already exists on the destination VM.
From there I use nextcloudcmd to sync with the server.
You don’t need to make any entry in rc.local or symlink - Qubes has already covered
this as you will see if you examine /rw/bind-dirs/var/spool/cron, and
cron will work out of the box when you enable the service.
You should use crontab -e to create and change crontab entries.
I see your entry: * * * * * user /rw/home/user/path/to/./backup.sh
Can you try that without the user field?
It would be helpful if you posted the contents of backup.sh
$ sudo systemctl status cron
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/cron.service.d
└─30_qubes.conf
Active: inactive (dead)
Condition: start condition failed at Sat 2020-12-19 13:03:38 CET; 8min ago
└─ ConditionPathExists=/var/run/qubes-service/crond was not met
Docs: man:cron(8)
Dec 19 13:03:38 VM systemd[1]: Condition check resulted in Regular background program processing daemon being skipped.
I’ve tried sudo and user crontab now, but doesn’t look like anything is being done. /var/run/qubes-service/crond doesn’t exist.
I thought you said this was a Fedora based qube? The service there is
crond isn’t it?
Are you now using a different template?
The error suggests that you have not enabled the crond service: qvm-service -e <qube> crond
I’m not the OP, but could use some help as well. Looks like the services are different in Debian, since after running that command I still get the same output.
The services are different in Debian, but the command is the same, and
the required file is the same. (Qubes cleverness)
Did you restart the qube after issuing the command?
Nice, cron works now after a reboot.
However, the Filecopy dialog still pops up, after changing the /etc/qubes-rpc/policy/qubes.FileCopy, since the source VM doesn’t know which VM it’s being sent to, for security reasons.
Edit: Command seems to be qrexec-client-vm cloud qubes.FileCopy file.txt
But I still get permission denied. I tried both qubes.FileCopy and qubes.Filecopy files.
I’m getting a little lost in the other (very welcome!) issues raised in the thread.
My current state of play is:
Crond has been enabled in qvm service crond status confirms that crond is up when the AppVM is running
there is an entry in the rc.local to replace /etc/crontab with /rw/home/user/path/to/new/crontab
the script which is invoked in the crontab, runs fine when run manually and doesn’t require sudo
Tl;dr - Crond is running (in a Fedora based AppVM), the script backup.sh runs fine when invoked, crontab is rewritten upon boot to
* * * * * user /rw/home/user/path/to/./backup.sh
I’ve tried it with ‘user’ and without ‘user’, no difference. Cron doesn’t seem to have logs so can’t find whether the issue is with the crontab edit, some permissions thing or something more fundamental.
One reason why I hate forums like this - they make it incredibly
difficult to follow lines of discussion within a single thread.
My remark was directed toward @9009 who complained that the FileCopy
dialog opened.