User cronjob can't access keyring/credentials

[algebro]

Hello all,

I’ve got duplicacy working great manually on my Arch Linux desktop, but when running from a cronjob duplicacy can’t seem to access the storage credentials. Running duplicacy backup manually works fine and doesn’t prompt for credentials, and I’ve verified that the credentials are in my gnome-keyring, but when the cronjob runs, duplicacy prompts for a password and b2 API keys. The cronjob is also set to run under my user’s crontab.

Has anyone run into this issue before? Thanks!

[algebro]

Actually, looks like I solved it. Had to set the dbus session bus address:

DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" duplicacy backup ...

[Christoph]

There are two related topics regarding that issue:

Cron job failed to get value from keyring

On a Linux box, I have the various passwords, etc. required for a backup stored in the keyring. I have scripted my backup operation and the script works as expected when invoked manually (with no prompts for passwords or other credentials). However, when I attempt to run it via cron, I get the following failure: Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set ssh_key_file i…

So how does the gnome keyring work with sudo?

I’m setting up duplicacy on an ubuntu (18.04) server and I can’t seem to get duplicacy to store the passwords in the gnome keyring. I previously used duplicacy on a NAS running on some old version of Debian and (as far as I can remember) I didn’t have problems with it remembering the passwords. Now on this ubuntu machine I don’t know what’s going on. It asks me to enter both the WebDAV password and the storage password everyt single time. Apart from the different version of Linux, I think the o…

However, one seems to have solved it: while the other concludes that:

So how does the gnome keyring work with sudo?

the gnome keyring doesn’t work with sudo. This is not Duplicacy’s fault – the dbus daemon doesn’t allow sudo to connect because it thinks it is from a different user id.