"when drive connected (udev)" schedule gives "can't find snapshots folder" error

[riquezjp]

After running an initial successful back-up & having the Schedule > When drive connected (udev) (every 1 days) On subsequent days connecting the drive, I immediately get a desktop notification "BackInTime: can't find snapshots folder" Clearly the software detected the drive being connected, but it doesn't run the backup. After several days testing no further backups were run when connecting drive. but the drive does contain the initial backup & folder hierarchy.

The error/notification appears immediately when connecting the USB drive.

Manjaro 21.3.0 Gnome 42.2 BackInTime 1.3.2

Please refer to this discussion on Manjaro forum with a possible solution for devs: https://forum.manjaro.org/t/backup-software-advice/113811/21?u=riquez

Thanks.

[aryoda]

Could be a mounting problem (drive not mounted).

Please check with the unconnected (!) drive: Are the snapshots written to the mounting point folder instead of the mounted drive?

[emtiu]

Closing because we haven't heard from the reporter in two months, and can't reproduce the problem.

[aryoda]

OK, even though I would have been interested in the device type and udev rule but without a response... :-(

Would have been interesting to learn more about what a user in the link wrote:

So it appears BackInTime uses udev to create a custom rule under /etc/udev/rules.d/ I tried to modify it to wait 10 seconds (sleep 10s) before issuing the command to run any scheduled backups. The problem is, BackInTime seems to detect if this udev rule was modified and wants to change it back.

[riquezjp]

@emtiu @aryoda The problem still happens, i just live with it. After connecting the drive, the error pops up, I then manually launch BackInTime & manually run the backup. BackinTime does detect the snapshots folder when manually launched & there is no issue when manually launching the app. Its just the automated detection daemon part that throws the error.

[emtiu]

Thanks for reporting back! If the problem still exists and you're willing to help with diagnostics, I'm happy tp re-open the Issue. Can you tell us more about the device, show us the udev rule and maybe some related log outputs?

[aryoda]

@riquezjp Could you please

1. improve the title by adding eg. "when drive gets connected (udev)" to help other users finding this issue easier
2. give me more details to reproduce this:
   • What type of ext. device are you using (USB stick, HDD, SSD...)?
   • Will the device be mounted automatically after connecting it (do you see it and can access its file in a file browser)?
   • Which file system is on the ext. device
   • Are you using BiT as user or root?
   • Most important: How does your config/profile look alike for this device (could you share an anonymized file with pseudo paths here)? The config file is stored in ~/.config/backintime/config normally

Thanks a lot!

[aryoda]

Note: This feature request from user "winnie" describes very well a better method instead of triggering the backup directly via “udev”:

The filesystem’s UUID becomes immediately available upon plugging in the USB device. Without a built-in delay, the command to backup (via BackInTime) tries to run immediately when the USB is plugged in.

However, the filesystem being detected (its “UUID” is known immediately) is not the same as the filesystem being mounted. THIS is the reason for its failure.

Not to mention, many users do not enable “auto mount” for their removable devices. (In my case, I need to manually permit a USB to mount. I do not allow it to mount on its own.)

Speaking of which, a better method (instead of only “udev”) could probably use the mtab. In other words “When the MOUNT PATH is active, only THEN try to run the backup task.”

So it would be a two-part logic:

1. Upon inserting the relevant USB device, udev will trigger step 2…

2. …which now polls the mtab every 5 seconds until the mount path is active.

If everything checks out, the backup task runs!

Otherwise, maybe after one minute, if the mount path is never active, only then will it fail and abort with the message “Mount path for the backup location was not available for over a minute. Backup task will not proceed. Please try again later.”

[riquezjp]

@aryoda no problem,

What type of ext. device are you using (USB stick, HDD, SSD...)?

Its a Crucial SSD 1TB in ext4 format connected by USB cable.

 Will the device be mounted automatically after connecting it (do you see it and can access its file in a file browser)?

Yes. It is auto-mounted & appears in Nautilus (gnome files) when connected.

 Which file system is on the ext. device

ext4

 Are you using BiT as user or root?

user

Most important: How does your config/profile look alike for this device (could you share an anonymized file with pseudo paths here)? The config file is stored in ~/.config/backintime/config normally

config.txt

I believe this is the udev rule, found in /etc/udev/rules.d ACTION=="add|change", ENV{ID_FS_UUID}=="167b250f-4858-44d4-b642-2048a562bdba", RUN+="/bin/su - 'rico' -c '/usr/bin/nice -n19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null'"

[aryoda]

THX for the input, please give me some time to check this (I am occupied with higher-prio bugs ATM but will revisit this issue after that)