Strange new behaviour from cron

[john the hat]

I have just set up a new machine with a fresh install of Ubuntu 22.04 (with xorg) and echo $DISPLAY :0. Previously I had no problems backing up with FFS and naturally I expected no glitch with the new set-up. How foolish. :-)

Line from crontab:

#Accounts to DB
00 13 * * * DISPLAY=:0 /opt/FreeFileSync/FreeFileSync /home/byson/FFS/Accounts.ffs_batch > /home/byson/logs/backup3.log 2>&1

The log gives me:
Authorization required, but no authorization protocol specified
17:00:01: Error: Unable to initialize GTK+, is DISPLAY set properly?

And the log file is, for some reason owned root:root
An clone of that line:

#Tbird
00 15 * * * DISPLAY=:0 /opt/FreeFileSync/FreeFileSync /home/byson/FFS/Tbird.ffs_batch > /home/byson/logs/backup5.log 2>&1

Gives the same error but the log file is owned user:user

These lines BOTH functioned on the old machine (also Ubuntu 22.04.)

Any suggestions as to what I have done wrong ? I am certain this has been answered before ( I may even have answered it myself) but this is new to me...

[bgstack15]

Depending on the cron implementation in Ubuntu, and where you are storing your cron job, you might need to (get to) specify the user that should run the command.
For example, when I place a cron job in /etc/cron.d/40_myappname_cron I use this format:

00 13 * * *  bgstack15   DISPLAY=:0 /opt/FreeFileSync/FreeFileSync /path/to/file.ffs_batch


But if I were to place a job for this in crontab -e when running as the user, I wouldn't include the intended username because it's already just my cron table.

00 13 * * *  DISPLAY=:0 /opt/FreeFileSync/FreeFileSync /path/to/file.ffs_batch


Also, I cannot seem to recall details if you might need to do something with xauth so your user can use :0, if say, at the time the process is supposed to run, this user is not the one logged in on the graphical terminal session (CTRL+ALT+F7, or is it F1?).

[john the hat]

Thanks for the response.
The jobs were all set up with crontab -e, and I am the sole user. The batch files are all in a FFS directory under home as you can see. As I said, this USED to work fine. :-(

[john the hat]

I have downgraded from Donation Edition v 13.5 to version 11.27 and it all works.

What is that all about ??

[filesyncer2017]

I have this in my cron and it works correctly with my donation edition.
0 23 * * * DISPLAY=:0 /opt/FreeFileSync/FreeFileSync /home/secret/something.ffs_batch > /dev/null 2>&1
I used crontab -e as well and am only user.

[Zenju]

A cron howto has been added to the manual: https://freefilesync.org/manual.php?topic=schedule-batch-jobs#linux

[droidkid]

I have been at this for over a month but I cannot get this to work via crontab -e. It works fine from terminal but not from crontab. Running Debian 12 and latest version of donation version.

I've tried with bash scripts I've tried like in the doc above nothing.

40 21 * * * DISPLAY=:0 /opt/FreeFileSync/FreeFileSync /mnt/path/ServerBackup/FreeFileSync/sitebackup.ffs_batch > /dev/null 2>&1

This does not work if I output it to a log I can see the same
Error: Unable to initialize GTK+, is DISPLAY set properly?

I'm losing my mind!

[bgstack15]

It's possible that your DISPLAY is a different value. Perhaps when you've logged off, and your computer is just at the login screen, the DISPLAY might be :0.0 or :10. That's not very likely, but possible. If you've left your session logged in, then most likely DISPLAY=:0 would still suffice. Searching how to find the DISPLAY on your "display manager" might help you.

[droidkid]

I've tried everything this is crazy. It's really too bad Free File Sync is by far the best sync program I have ever used. I just want it to do nightly sync's on my Linux server from one HDD to another. I legit might install Windows server instead of Linux at this point LOL

[Zenju]

DISPLAY=:0

This is superfluous, as "DISPLAY=:0" is the default. Settings this environment variable is only useful for values other than ":0".

Have you tried:

DISPLAY=:1