Hi

Thank you for creating and sharing this, it's really great!

Two issues I noticed on setting this up:

1. Using a SSH Storage profile, backup over ssh to a Debian 13 host failed with this error showing in borg_backup_ui.log

Remote: command-line: line 0: Bad configuration option: warnweakcrypto

I worked around it by commenting out WarnWeakCrypto on line ~26 in plugins/borg-backup-ui/api/borg_ssh.py

This might be down to my out of date Unraid version - 6.12.15.

2. When I'm using the UI, the plugin is regularly writing to the USB stick, even when not making configuration changes. It looks like user session and notification data in /boot/config/borg-backup/config/

This can't be good for the longevity of the usb stick?

Otherwise, it's working really well!

Cheers!

8 hours ago, pheelay said:

Hi

Thank you for creating and sharing this, it's really great!

Two issues I noticed on setting this up:

1. Using a SSH Storage profile, backup over ssh to a Debian 13 host failed with this error showing in borg_backup_ui.log

Remote: command-line: line 0: Bad configuration option: warnweakcrypto

I worked around it by commenting out WarnWeakCrypto on line ~26 in plugins/borg-backup-ui/api/borg_ssh.py

This might be down to my out of date Unraid version - 6.12.15.

2. When I'm using the UI, the plugin is regularly writing to the USB stick, even when not making configuration changes. It looks like user session and notification data in /boot/config/borg-backup/config/

This can't be good for the longevity of the usb stick?

Otherwise, it's working really well!

Cheers!

Hi,

Thanks for your feedback, the detailed reports, and for sharing your workaround!

Your suspicion about the SSH error is correct: the SSH client on Unraid 6.12.15 does not recognize WarnWeakCrypto, which was introduced in OpenSSH 10.1.

This option was the sole reason we raised the minimum Unraid version to 7.2.0. We need it on newer SSH clients because the warning interferes with the plugin’s SSH handling.

The planned fix is to keep WarnWeakCrypto=no and add IgnoreUnknown=WarnWeakCrypto before it. Older clients would ignore this specific option, while newer clients would continue to suppress the warning. We also plan to lower the minimum Unraid requirement to 6.12.5.

This is tracked in Issue #496.

Regarding the USB writes, we investigated file activity on our Unraid installation during five minutes of idle operation and ten minutes of UI usage, including rapid navigation between pages.

What we found:

• The notification queue is unnecessarily rewritten approximately every 30 seconds, even when nothing has changed and the UI is closed. Each update writes a temporary file and replaces notification-queue.json on the boot USB stick.

• This extrapolates to approximately 2,880 unnecessary saves per day of continuous operation. These are real file writes and create avoidable USB write load, although we cannot quantify how much they shorten a particular stick’s lifespan.

• Repeated session writes were not reproduced in our tests. users.json and sessions.json were each saved once at sign-in and were not rewritten during subsequent navigation.

• An inventory lock file on the USB stick received repeated permission updates. Other observed configuration-file accesses were reads.

We also found repeated write-access probes in the configured data directory during UI usage. In our setup, these affected the data storage rather than the boot USB stick.

Our proposed fixes are to:

• Save the notification queue only when its contents change.

• Avoid redundant permission updates on the lock file while preserving the required permissions.

• Remove write-access probes from routine page-status requests, retaining appropriate checks during setup and actual write operations.

These findings and proposed fixes are documented in Issue #497.

Neither fix has been released yet. Once implemented, we will repeat the measurements and provide a test version for verification.

I'm looking for approximately five volunteers to test the migration to permanent job IDs in Borg Backup UI.

Testing on my installation has been successful. Before making the version generally available, I would like to verify that the migration also works reliably with other existing installations and configurations.

❗❗❗ 👉 As this is a significant architectural change, further feature development is currently on hold until the migration has also been validated on other installations. Your feedback will help me move development forward with confidence. 👈 ❗❗❗

If you are interested, please send me a private message, ideally including your Unraid version, number of jobs, and storage types used: Local, USB, SMB, or SSH. I will then provide the test version and further information.

Before updating:

• Let running backup and restore operations finish, then stop the plugin service before taking your precautionary backup.

• Back up the existing configuration and data directories completely, including hidden files. Keep the backup outside those directories.

• Example paths are /boot/config/borg-backup and /mnt/user/borg_backup_ui. Your actual paths depend on your configuration. Include any separately configured data directories as well.

Existing configuration exports: Previous job and profile exports cannot be imported into this test version. Create fresh exports after updating and successfully completing the migration. Existing Borg backup archives remain usable and do not need to be recreated.

Migration runs automatically on the first start. Depending on the number of jobs and files and the storage speed, it may take several minutes. The web interface will not yet be available because the web server starts afterwards. Please do not interrupt the running migration.

You can monitor progress in the Unraid terminal:

tail -n 100 -F /var/log/borg_backup_ui.log

You should see messages similar to these abbreviated examples:

Migration job_ids_v1: Saving recovery copies ...
Migration job_ids_v1: Updating job references ...
Migration job_ids_v1: Verifying migrated files ...
Startup migrations: status=ok, ... failed=[]
Borg Backup UI started: http://...

Progress messages include file counts and elapsed time. After startup, please check that your jobs, settings, schedules, history, and restore results are present and correctly associated.

If an error occurs, please send the relevant log excerpt by private message after checking it for confidential information. Thank you for helping test this update!

Edited September 8Sep 8 by Thorsten

I am using Borg Backup UI for several weeks now. My schedule for my five jobs is "once a week", which happened again yesterday night. The weeks before, all five backups went succcessfully. But yesterday, four out of five backups failed. These were all local backups, which aren't encrypted. The fifth backup is to Hetzner storagebox (encrypted), this was successfull.

All failed backups showed this in the log:

2026-09-08 02:45:42 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2026-09-08 02:45:42 INFO PHASE 3: BORG BACKUP (CREATE)

2026-09-08 02:45:42 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2026-09-08 02:45:42 INFO Repository: /mnt/disks/USBHDD/borg-backup/borg-backup-appdata

2026-09-08 02:45:42 INFO Backup paths: /mnt/user/appdata /boot/config/plugins/dockerMan

2026-09-08 02:45:42 INFO Excluded paths: none

2026-09-08 02:45:42 INFO Performance: Compression=lz4

2026-09-08 02:45:42 INFO File activity output: disabled

2026-09-08 02:45:42 INFO Cache: /mnt/user/borg-backup-ui/cache/usb_appdata

2026-09-08 02:45:42 INFO

2026-09-08 02:45:42 INFO Borg create starting... (2 paths, compression=lz4)

2026-09-08 02:45:43 INFO Warning: Attempting to access a previously unknown unencrypted repository!

2026-09-08 02:45:43 INFO Do you want to continue? [yN] Aborting.

2026-09-08 02:45:43 INFO Cache initialization aborted

2026-09-08 02:45:43 INFO terminating with error status, rc 2

2026-09-08 02:45:43 ERROR ERROR: Borg create failed (exit 2)

Besides the several Plugin-updates in the last week, nothing has changed. I also did a reboot yesterday (before the backup jobs started) because of the folder permission thing. Any thoughts what could have happened? The log says "previously unknown (and unencrypted) repository". But how can it be unknown? As I did backup jobs before...

Regards,

Stefan

1 hour ago, JayDee73 said:

I am using Borg Backup UI for several weeks now. My schedule for my five jobs is "once a week", which happened again yesterday night. The weeks before, all five backups went succcessfully. But yesterday, four out of five backups failed. These were all local backups, which aren't encrypted. The fifth backup is to Hetzner storagebox (encrypted), this was successfull.

All failed backups showed this in the log:

2026-09-08 02:45:42 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2026-09-08 02:45:42 INFO PHASE 3: BORG BACKUP (CREATE)

2026-09-08 02:45:42 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2026-09-08 02:45:42 INFO Repository: /mnt/disks/USBHDD/borg-backup/borg-backup-appdata

2026-09-08 02:45:42 INFO Backup paths: /mnt/user/appdata /boot/config/plugins/dockerMan

2026-09-08 02:45:42 INFO Excluded paths: none

2026-09-08 02:45:42 INFO Performance: Compression=lz4

2026-09-08 02:45:42 INFO File activity output: disabled

2026-09-08 02:45:42 INFO Cache: /mnt/user/borg-backup-ui/cache/usb_appdata

2026-09-08 02:45:42 INFO

2026-09-08 02:45:42 INFO Borg create starting... (2 paths, compression=lz4)

2026-09-08 02:45:43 INFO Warning: Attempting to access a previously unknown unencrypted repository!

2026-09-08 02:45:43 INFO Do you want to continue? [yN] Aborting.

2026-09-08 02:45:43 INFO Cache initialization aborted

2026-09-08 02:45:43 INFO terminating with error status, rc 2

2026-09-08 02:45:43 ERROR ERROR: Borg create failed (exit 2)

Besides the several Plugin-updates in the last week, nothing has changed. I also did a reboot yesterday (before the backup jobs started) because of the folder permission thing. Any thoughts what could have happened? The log says "previously unknown (and unencrypted) repository". But how can it be unknown? As I did backup jobs before...

Regards,

Stefan

Thank you for the detailed report. We reproduced the problem on our Unraid system and confirmed the cause.

By default, Borg stores information used to recognize previously accessed repositories under /root/.config/borg/security. On Unraid, this directory resides in RAM and is lost during a reboot. The persistent backup cache alone is not sufficient to retain this recognition.

When an unencrypted repository is accessed afterward, Borg therefore asks for confirmation again. An automated backup cannot answer this interactive prompt, so it aborts with exit code 2. This explains why the backups worked previously and failed after the reboot. Encrypted repositories do not trigger this particular confirmation prompt.

Temporary workaround:

After a reboot, open the repository management page and refresh the Borg information for each affected unencrypted repository. This recreates the missing security information. You can then run the backup jobs again. We have successfully tested this procedure.

A fix is in progress to store this information persistently so it survives reboots. Until the fix is released, the workaround needs to be repeated after each reboot.

Issue #498 – Persist Borg security state to prevent unencrypted backups failing after reboot

Edited September 8Sep 8 by Thorsten

Hallo,

ich habe heute schon zum zweiten mal das Problem

Ich habe nichts verändert.
Benutzername und Password wurden wie immer durch den Passwortmanager ausgefüllt.

Ein Restart hat zur Folge das man das Plugin nicht mehr starten kann.
Beim ersten mal musste ich Unraid komplett runterfahren.

Edited September 8Sep 8 by mikiunraid

25 minutes ago, mikiunraid said:

Hallo,

ich habe heute schon zum zweiten mal das Problem

Ich habe nichts verändert.
Benutzername und Password wurden wie immer durch den Passwortmanager ausgefüllt.

Ein Restart hat zur Folge das man das Plugin nicht mehr starten kann.
Beim ersten mal musste ich Unraid komplett runterfahren.

Okay das Problem hatte ich noch nie kannst du mir per PN mal ein Support Paket schicken damit ich mir das anschauen kann

4 hours ago, Thorsten said:

Thank you for the detailed report. We reproduced the problem on our Unraid system and confirmed the cause.

By default, Borg stores information used to recognize previously accessed repositories under /root/.config/borg/security. On Unraid, this directory resides in RAM and is lost during a reboot. The persistent backup cache alone is not sufficient to retain this recognition.

When an unencrypted repository is accessed afterward, Borg therefore asks for confirmation again. An automated backup cannot answer this interactive prompt, so it aborts with exit code 2. This explains why the backups worked previously and failed after the reboot. Encrypted repositories do not trigger this particular confirmation prompt.

Temporary workaround:

After a reboot, open the repository management page and refresh the Borg information for each affected unencrypted repository. This recreates the missing security information. You can then run the backup jobs again. We have successfully tested this procedure.

A fix is in progress to store this information persistently so it survives reboots. Until the fix is released, the workaround needs to be repeated after each reboot.

Issue #498 – Persist Borg security state to prevent unencrypted backups failing after reboot

I can confirm that this workaround has also worked for me. Thanks for that!

In addition to that, I do have a question (it's most probably not an issue itself...): I do make a backup of my two VMs (one Linux based, the other one Windows 11). Same retention as for the rest, and one backup job per week. What I have observed through the last couple of runs is, that the Repository increases quite a bit with every run. Several additional GB per run. Of course, the two VMs are "changing", but besides from usual OS updates, nothing special was added. But maybe this simply is "by design" how Borg works?

What I was thinking about: Is it possible to do a full backup with every run (so no incremental) and specify some kind of "only keep x full backups"? So that with e. g. 3 kept backups, the oldest one would always be deleted when a fourth backup begins? This would result in a "nearly stable" amount of Storage space needed, right?

Yes, this is basically how Borg works, although VM disk images are a somewhat special case.

Borg does not really distinguish between "full" and "incremental" backups in the traditional sense. Every archive created by Borg represents a complete backup from the user's perspective. Internally, however, Borg splits the data into chunks and deduplicates them across all archives in the repository.

So if a chunk already exists in the repository, Borg does not store it again.

VM disk images can unfortunately generate quite a lot of new data between backup runs even if you do not actively add much data inside the VM. Windows/Linux updates, logs, temporary files, swap/pagefile activity and filesystem metadata can modify many areas of the virtual disk image. Borg then sees new chunks that have to be stored.

So several additional GB per VM backup can be perfectly normal.

Regarding your idea of doing a "full backup" each time: with Borg this would not really change anything, because every Borg archive already behaves like a full backup.

What you can do instead is configure the retention so that only the last X archives are kept. For example, if you want exactly three backup generations, this would effectively correspond to:

keep-last = 3

After pruning the older archives, Borg can remove chunks that are no longer referenced by any remaining archive. The subsequent compact operation then reclaims the unused repository space.

So with three retained backups, the repository size should eventually reach a certain range rather than growing indefinitely. However, it will not necessarily remain completely stable, especially for VM images, because the amount of changed data between the three generations can vary considerably.

1 hour ago, Thorsten said:

Okay, das Problem hat mich noch nie kannst du mir per PN mal ein Support Paket schicken damit ich mir das anschauen kann

Geht nicht das Webinterface ist nach dem Restart nicht mehr erreichbar.

Edited September 8Sep 8 by mikiunraid

Unter /var/log/ gibt es eine Datei borg_backup_ui.log die brauche ich.

Was mir noch einfallen würde wäre wenn du ein Docker Container installiert hast der evtl. Den gleichen Port nutzt dann kan Borg Backup UI auch nicht starten

Edited September 8Sep 8 by Thorsten

33 minutes ago, Thorsten said:

Unter /var/log/ gibt es eine Datei borg_backup_ui.log das brauche ich

Habe ich dir gerade geschickt.

1 hour ago, mikiunraid said:

Habe ich dir gerade geschickt.

Ich habe dir meine Analyse per PN geschickt .....

I’ve sent you my analysis via private message.

On 9/8/2026 at 8:00 PM, Thorsten said:

What you can do instead is configure the retention so that only the last X archives are kept. For example, if you want exactly three backup generations, this would effectively correspond to:

keep-last = 3

Thanks for the explanation. To be honest: How can I achieve this? Can I specify this "extra parameter" anywhere in the GUI? Haven't found that yet...Or is a "special combination" of the four retention values an equivalent of "keep the last three backups"?

2 hours ago, JayDee73 said:

Thanks for the explanation. To be honest: How can I achieve this? Can I specify this "extra parameter" anywhere in the GUI? Haven't found that yet...Or is a "special combination" of the four retention values an equivalent of "keep the last three backups"?

You haven’t missed anything — the GUI currently only provides daily, weekly, monthly and yearly retention settings. There is no field for adding --keep-last.

My previous example referred to an option supported by Borg itself, which the plugin does not currently expose. Sorry, I should have made that clear.

There is also no combination of the four existing settings that always means “keep the last three backups,” regardless of when they ran. For example, daily retention selects backups from different days, so several backups on the same day are treated differently. Borg’s retention documentation explains these rules.

More flexible retention options are already planned, and keeping a fixed number of backup generations is a use case I want to cover.

At the moment, my priority is completing and validating the migration to permanent job IDs. Before adding further features, I need to verify this change on more existing installations.

I’m still looking for volunteers. If you would like to help, you can find the details in my call for testers. Just send me a private message if you’re interested.

Hi everyone,

I’ve put together a short video showing Borg Backup UI for Unraid in action — from creating a backup job to restoring a file and checking that a backup can be restored.

The walkthrough covers:

• Storage profiles and repositories

• Creating jobs, scheduling backups and configuring retention

• Running a backup and reviewing its log and history

• Browsing archives and restoring individual files

• Automated restore tests and their reports

• Repository maintenance and notification settings

The video was recorded using the current test version with demo data. This version introduces permanent job IDs, keeping jobs consistently linked to their history and restore results when their names or archive prefixes change.

I hope this gives both existing users and anyone considering the plugin a useful overview. Questions and feedback are welcome!

Edited September 14Sep 14 by Thorsten

On 9/7/2026 at 10:49 PM, pheelay said:

Hi

Thank you for creating and sharing this, it's really great!

Two issues I noticed on setting this up:

1. Using a SSH Storage profile, backup over ssh to a Debian 13 host failed with this error showing in borg_backup_ui.log

Remote: command-line: line 0: Bad configuration option: warnweakcrypto

I worked around it by commenting out WarnWeakCrypto on line ~26 in plugins/borg-backup-ui/api/borg_ssh.py

This might be down to my out of date Unraid version - 6.12.15.

2. When I'm using the UI, the plugin is regularly writing to the USB stick, even when not making configuration changes. It looks like user session and notification data in /boot/config/borg-backup/config/

This can't be good for the longevity of the usb stick?

Otherwise, it's working really well!

Cheers!

Both issues were fixed in version 2026.09.12.0054

I do have another question. I've ran the "Fix Common Problems" Plugin today (I am doing this from time to time...) and it threw a warning regarding Borg Backup UI:

I don't really understand why the Plugin thinks that Borg Backup UI is an "array only share". I've created the share as a Cache-Only share:

Do you have any explanation for this? Can you reproduce this? And of course: What can I do to solve this warning?

Regards,

JD

29 minutes ago, JayDee73 said:

I do have another question. I've ran the "Fix Common Problems" Plugin today (I am doing this from time to time...) and it threw a warning regarding Borg Backup UI:

I don't really understand why the Plugin thinks that Borg Backup UI is an "array only share". I've created the share as a Cache-Only share:

Do you have any explanation for this? Can you reproduce this? And of course: What can I do to solve this warning?

Regards,

JD

Thanks for the screenshots. Your settings—Primary storage: Cache and Secondary storage: None—are appropriate for keeping this share on the cache pool.

Borg Backup UI creates its data directories at the configured path, but does not change Unraid’s share storage settings. A path under /mnt/user/ can also store data on the cache pool; it does not automatically mean the array.

I have not been able to reproduce the warning on my own installation. My data directory is /mnt/user/borg_backup_ui, the share is configured to use the array, and Fix Common Problems reports no errors or warnings. However, this differs from your cache-only setup, so it does not rule out a problem specific to that configuration.

The specific FCP warning is triggered when it finds the share directory on the cache but cannot find the corresponding saved share configuration file. This can happen with an automatically discovered share. We still need to confirm whether that is what happened on your installation. FCP check

Please try the following:

1. Open Shares → borg-backup-ui.

2. Keep Primary storage: Cache and Secondary storage: None.

3. Enter a comment, for example Borg Backup UI data.

4. Click Apply, then Done, to explicitly save the share settings.

5. Run Rescan in Fix Common Problems.

If the warning remains, please send your Unraid and FCP versions and the output of:

ls -l /boot/config/shares/borg-backup-ui.cfg

You can keep /mnt/user/borg-backup-ui as the plugin’s data path.

8 minutes ago, Thorsten said:

1. Open Shares → borg-backup-ui.

2. Keep Primary storage: Cache and Secondary storage: None.

3. Enter a comment, for example Borg Backup UI data.

4. Click Apply, then Done, to explicitly save the share settings.

5. Run Rescan in Fix Common Problems.

Interesting. After these steps and a rescan of FCP the warning was gone.

So I assume you won't need the output of the cfg and the version numbers?

50 minutes ago, JayDee73 said:

Interesting. After these steps and a rescan of FCP the warning was gone.

So I assume you won't need the output of the cfg and the version numbers?

No, I don't need that. The file was created automatically by the description text and saving it. FCP was complaining that it's missing.

English

Borg Backup UI 2026.09.13.1711 – More flexible retention and exclusions

The new version adds more control over backup retention, new exclusion options and improvements to repository management.

New retention options

The job wizard now offers three strategies:

• Tiered: Combine hourly, daily, weekly, monthly and yearly restore points. Optionally keep every archive within a recent time window as well.

• Last X archives: For example, keep the last three matching archives, regardless of which days they were created on.

• Keep all: Disable automatic pruning for the job.

Existing jobs retain their current retention rules. Info dialogs explain the settings with examples. Empty policies and time-window-only policies are blocked to prevent a long backup gap from making every archive eligible for deletion.

Retention applies to the job’s current archive prefix. Archives using earlier prefixes are retained in addition.

A dedicated Exclusions step

Excluded paths, marker filenames and an uploaded exclusion file are now shown together on their own wizard page.

• Use a marker file such as .nobackup to exclude an entire folder and its subfolders.

• Upload one text file containing Borg exclusion patterns per job. The application stores its own copy, which can be downloaded, replaced, removed and included in job exports.

• All nine wizard steps keep the same window size. Wider path inputs make long directory paths easier to read.

Other improvements

• Administrators can delete individual archives under Repositories > Archives, with an additional confirmation requiring DELETE. Logs and run history remain available. Use Compact afterwards to reclaim disk space.

• Archive counts in the tab and overview now follow the loaded archive list.

• Apprise has been updated to 1.13.1, providing 141 notification providers.

Compatibility notes: Job exports using the extended settings use a new format that older plugin versions cannot import. NotificationAPI is no longer supported by Apprise; affected profiles display reconfiguration guidance. Saved settings and credentials are preserved.

The update is available through Unraid > Plugins. Thank you for your feedback and testing!

Maybe I do have another issue....

I am running weekly backups for quite some time now. They all went successful. But yesterday 4 out of 5 failed. All do have in common that they have my USB HDD as a target. The fifth job to Hetzner Storagebox went without problems. So no general issue I think.

Log says that USB HDD isn't mounted:

2026-09-15 07:01:30 INFO 
2026-09-15 07:01:30 INFO Created lock file (PID: 3767891)
2026-09-15 07:01:30 INFO Parity check enabled (ABORT_ON_PARITY_CHECK=true)
2026-09-15 07:01:30 INFO USB mount check enabled: /mnt/disks/USBHDD/borg-backup
2026-09-15 07:01:30 INFO Saving skipped status: USB is not mounted: /mnt/disks/USBHDD/borg-backup
2026-09-15 07:01:30 INFO Saved backup status: /mnt/user/borg-backup-ui/status/2026-09-15_07-01-30_Data_Photos_Music_auf_USBHDD_usb_a1754058-fb8d-4fe4-8856-b2ca5d20ff01.status
2026-09-15 07:01:30 INFO Notification event processed (event=backup_skipped source=backup_job unraid=True email=False apprise=False apprise_mode=queued apprise_profiles=[])
2026-09-15 07:01:30 INFO Unraid dashboard widget cache updated (backup finalization)

But USB Profile Check says "all good":

Unraid Dashboard says: USB Drive is mounted:

And Access to the drive (e. g. through the hyperlink shown above (USBHDD)) is also possible.

The only thing that changed (from my perspective): Updates of the Plugin. Maybe the "job id update" could play into this?

Any thoughts?

Regards,

JD

1 hour ago, JayDee73 said:

Maybe I do have another issue....

I am running weekly backups for quite some time now. They all went successful. But yesterday 4 out of 5 failed. All do have in common that they have my USB HDD as a target. The fifth job to Hetzner Storagebox went without problems. So no general issue I think.

Log says that USB HDD isn't mounted:

2026-09-15 07:01:30 INFO 
2026-09-15 07:01:30 INFO Created lock file (PID: 3767891)
2026-09-15 07:01:30 INFO Parity check enabled (ABORT_ON_PARITY_CHECK=true)
2026-09-15 07:01:30 INFO USB mount check enabled: /mnt/disks/USBHDD/borg-backup
2026-09-15 07:01:30 INFO Saving skipped status: USB is not mounted: /mnt/disks/USBHDD/borg-backup
2026-09-15 07:01:30 INFO Saved backup status: /mnt/user/borg-backup-ui/status/2026-09-15_07-01-30_Data_Photos_Music_auf_USBHDD_usb_a1754058-fb8d-4fe4-8856-b2ca5d20ff01.status
2026-09-15 07:01:30 INFO Notification event processed (event=backup_skipped source=backup_job unraid=True email=False apprise=False apprise_mode=queued apprise_profiles=[])
2026-09-15 07:01:30 INFO Unraid dashboard widget cache updated (backup finalization)

But USB Profile Check says "all good":

Unraid Dashboard says: USB Drive is mounted:

And Access to the drive (e. g. through the hyperlink shown above (USBHDD)) is also possible.

The only thing that changed (from my perspective): Updates of the Plugin. Maybe the "job id update" could play into this?

Any thoughts?

Regards,

JD

I checked the code and found the cause: the plugin currently uses two different USB mount checks. This is unrelated to the job-ID migration.

The intended configuration is:

• USB profile: The drive’s actual mount point, such as /mnt/disks/USBHDD.

• Repository: The folder beneath that mount point, such as borg-backup/borg-backup-appdata.

However, the plugin does not consistently enforce this:

• The USB profile check uses findmnt -T, which also finds the underlying filesystem for a subfolder. It therefore reports /mnt/disks/USBHDD/borg-backup as “OK”, even though that folder is not itself the mount point.

• The backup startup check requires the configured path itself to be a mount point. It rejects that same subfolder and skips the backup.

This explains the contradictory results. Your drive can be correctly mounted while the plugin incorrectly reports it as unavailable.

The planned fix will support both the USB drive’s mount point and a subfolder on that drive.

For your configuration, the plugin will distinguish between:

• Configured storage path: /mnt/disks/USBHDD/borg-backup

• Actual mount point: /mnt/disks/USBHDD

Both the USB profile check and backup startup will use the same validation: confirm that the drive is mounted, then check that the configured storage folder exists and is accessible and writable.

The protection against missing drives will remain active. An empty directory left behind after unmounting will not count as a mounted drive, and genuine I/O errors will still prevent the backup from starting.

This approach will preserve your existing configuration and repository locations. You will not need to move any files, recreate jobs or reimport repositories.

The fix has not been released yet.

USB backup fix in Borg Backup UI 2026.09.15.1019

This version fixes an issue where USB backups were incorrectly skipped with “USB is not mounted”, even though the drive was mounted and the USB profile check reported OK.

This affected profiles pointing to a subfolder, for example:

• Drive mount point: /mnt/disks/USBHDD

• Configured storage path: /mnt/disks/USBHDD/borg-backup

The profile check and backup startup used different checks. Both now use the same validation and support the drive’s mount point or an existing subfolder. This issue was unrelated to the job-ID migration.

Missing drives, inaccessible folders and read-only targets still prevent backups from starting.

No configuration changes, repository imports or data moves are required. Update the plugin and run your affected backup job again. The log now shows the configured storage path, detected mount point and check result.

Thanks to everyone who reported the issue and helped identify the cause!