The popups are desktop notifications posted by the Backups app (Déjà Dup) whenever a scheduled backup starts and finishes, and you can silence them for that app alone with a single gsettings command. The backup schedule is untouched — only the start and finish banners disappear.
Why the banners appeared after the upgrade
The 22.04 → 24.04 release upgrade brought a newer Déjà Dup along with a newer GNOME stack, and recent builds announce the beginning and end of every scheduled backup as ordinary desktop notifications. The 22.04-era build stayed quiet during normal runs, which is why behavior changed even though no backup setting was touched.
On an LXDE session these notifications are drawn by whatever notification daemon the desktop runs, so they appear as banners that sit on screen until someone dismisses them — exactly what you do not want a relative to deal with.
One quick sanity check first: if you are seeing small banners in a corner of the screen, this is the notification behavior described here and the fix below applies. If a full Déjà Dup window opens by itself, something on the machine is launching the GUI (an autostart entry or a shortcut, for example), and that is a separate problem.
The fix: switch off notifications for the Backups app
GNOME stores a per-application notification switch in a schema whose storage path is keyed by the application id. The colon syntax below tells gsettings to write into the copy of that schema stored under the deja-dup path:
gsettings set org.gnome.desktop.notifications.application:/org/gnome/desktop/notifications/application/deja-dup/ enable falseOn a stock GNOME session the equivalent click-path is Settings → Notifications → Backups, toggled off. On LXDE the GNOME Settings application may not even be installed, so the command line is the dependable route — it only needs the GLib schemas that Déjà Dup already depends on.
Confirm it took effect
gsettings get org.gnome.desktop.notifications.application:/org/gnome/desktop/notifications/application/deja-dup/ enableThis should print false. To put the banners back later, repeat the first command with enable true or flip the toggle in Settings.
Applying it remotely over SSH
Notification settings live in each user's own dconf database, so the command must run as the person who actually uses the desktop — running it as root silently writes to root's database and changes nothing. When connecting over SSH, point the command at that user's session bus:
sudo -u herusername env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u herusername)/bus \
gsettings set org.gnome.desktop.notifications.application:/org/gnome/desktop/notifications/application/deja-dup/ enable falseIf the banners still show up
Work through this short list:
- Wrong user. Verify the command ran as the desktop user, not root (see above).
- Daemon differences. LXDE's notification daemon may not honor GNOME's per-app switch on every setup. In that case, configure the daemon itself — most support per-application rules or a do-not-disturb mode that you can scope to this app id.
- Double scheduling. Check that backups are not being triggered twice — for example Déjà Dup's own automatic schedule plus a cron job. Every extra run means another pair of banners.
Then test by triggering one backup manually and watching the screen.
Alternative: schedule backups from cron instead
If you would rather own the schedule entirely, configure what to back up, where, and any password once in the Backups GUI, turn off automatic backups there, and run the job from the user's crontab:
/usr/bin/deja-dup --backup --autoThis performs one backup using the stored settings without opening the main window. From cron you must give the job the session's environment; on an X11 session that means DISPLAY and DBUS_SESSION_BUS_ADDRESS:
# user's crontab (crontab -e); replace 1000 with the user's UID
30 11 * * * DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /usr/bin/deja-dup --backup --autoTrade-offs to weigh: you get a schedule that survives future upgrades unchanged, but cron only fires if the machine is on at that minute, and you lose the GUI's "next backup" indicator. Wayland sessions may need different environment handling, so test before relying on it. And keep automatic backups disabled in the GUI so two schedulers do not fight.
Keeping the desktop predictable after future upgrades
Since a release upgrade is what introduced the change, treat notification defaults as part of your post-upgrade checklist:
- Keep a small "desktop baseline" script of
gsettingscommands — including this one — and reapply it after every upgrade. - After upgrading, run one manual backup and watch the screen for banners.
- Document each tweak so anyone else supporting the machine knows why it is set that way.
Frequently Asked Questions
Will disabling these notifications stop my backups from running?
No. The switch only controls whether the app may raise notifications. Scheduled backups continue exactly as before; open the Backups app occasionally to confirm the last backup date.
I don't have GNOME's Settings app on LXDE — how do I change this?
Use the gsettings command shown above. It works from a terminal or over SSH and does not require GNOME Settings to be installed.
Can I keep failure alerts but drop the start and finish banners?
Not with this switch — it is all-or-nothing per application, not per message type. If failure alerting matters, monitor the backup log or run backups from a script that reports failures itself.
gsettings complains it cannot connect — what now?
You ran it outside the user's graphical session. Log in as that user, or use the SSH variant that sets DBUS_SESSION_BUS_ADDRESS to the user's session bus.
Does this hide notifications from other applications too?
No. The setting is scoped to the deja-dup application id; every other app's notifications behave as before.
How do I put the banners back?
Run the same command with enable true, or on a GNOME session re-enable Settings → Notifications → Backups.