JayDee73

This is the error message: Log said: 2026-09-15 18:14:50 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-09-15 18:14:50 INFO PHASE 3: BORG BACKUP (CREATE) 2026-09-15 18:14:50 INFO ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2026-09-15 18:14:50 INFO Repository: /mnt/disks/USBHDD/borg-backup/borg-backup-data 2026-09-15 18:14:50 INFO Backup paths: /mnt/user/photos /mnt/user/music /mnt/user/data/Backup /mnt/user/data/Hausbau /mnt/user/syncthing /mnt/user/immich /mnt/user/immich-gen 2026-09-15 18:14:50 INFO Excluded paths: none 2026-09-15 18:14:50 INFO Exclusion markers: none 2026-09-15 18:14:50 INFO Performance: Compression=lz4 2026-09-15 18:14:50 INFO File activity output: disabled 2026-09-15 18:14:50 INFO Cache: /mnt/user/borg-backup-ui/cache/usb_data_photos_music_usb 2026-09-15 18:14:50 INFO 2026-09-15 18:14:50 INFO Borg create starting... (7 paths, compression=lz4) 2026-09-15 18:14:52 INFO Warning: Attempting to access a previously unknown unencrypted repository! 2026-09-15 18:14:52 INFO Do you want to continue? [yN] Aborting. 2026-09-15 18:14:52 INFO Cache initialization aborted 2026-09-15 18:14:52 INFO terminating with error status, rc 2 2026-09-15 18:14:52 ERROR ERROR: Borg create failed (exit 2) And because of this "previously unknown..." I did a Refresh. We had this error already in another situation a couple of weeks ago, and you told me to refresh. I did remember this and did it again. ;-) So, to answer your next question: Yes, the backup is unencrypted. No, I didn't have restarted Unraid straight beforehand. But wait....I restarted it about 4 days ago because of a new network card driver. So yes...between the last successful job and the latest failed one there was a restart. And yes, you told me that a permanent fix for this is still in the making and until then, a Unraid restart leads to this behaviour. So in the end it's not related to the USB mount problem, but to the "unencrypted backup" problem?! And regarding the last questions: I refreshed every job, not all of them with the general button. JD

Thanks for the Update. USB Backup jobs are up & running again. But a small note: I had to refresh the repositories to get them going again. Without a new refresh, the job still failed.

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

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?

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

Dito bei mir. Sobald ich mit dem Standardtreiber L1 (also Helper Mode 2) setze, bricht der Speed auf 450Mbit ein. Nutze eine 2.5Gbit-Anbindung, ist also deutlich unter den Möglichkeiten. Allerdings bricht es auch nur in einer Richtung ein. Speed zu Unraid hin ist 450Mbit, in die andere Richtung 2.35Gbit. Dafür komme ich hoch bis C10.

Das Phänomen habe ich bei mir auch. Entweder C3 und voller Speed, oder höhere C-States, aber dann bricht die Netzwerkperformance ein. Habe schon tausend Dinge probiert, und keine Lösung gefunden. Falls das jemand bei diesem Board mit höheren C-States UND voller 2.5G-Performance hinbekommen hat, gerne melden. @_alo_ : Meines Wissens nach zeigt er zwar L1 aktiv an, aber trotzdem erreicht man eben nur C3. Oder aber (mit einem anderen Treiber), hat man bessere C-States, aber dann weniger Durchsatz (gemessen mit iperf). Ist halt abhängig davon, ob man den Stock-Treiber aus Unraid nimmt oder den Plugin-Treiber. Der eine macht gute C-States möglich, der andere macht volle Performance. Auch hier: Wenn das bei dir anders ist, sag gerne mal Bescheid.

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"?

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?

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

Another question (and I hope I won't receive a trophy for "most annoying user" :-) ): When backing up containers, one has to choose the appdata folder to be backed up. So far, so good. But what about the individual container configuration stored in the xml files on the flash storage? Will they also be backed up "automagically" in the background within the appdata-job? Yes, when I do have another job for the flash, the xml files will be backed up with this job. But it would be more fitting if they will be stored together with the appdata itself, won't it? What is your opinion about that?

Is it intentional, that during a VM backup process, a warning regarding the shutdown will be thrown in Unraid notifications? I know, a shutdown of a VM could be a scary thing 🤣, but in this case it is more of a "expected behaviour", right? So maybe this could be categorized as a informational notification (therefore a green check mark, no yellow exclamation mark)? What do you think?

Good morning, thanks again. So I will add this to my VM backup job. Another one: I have created several jobs, ran all of them (all were successfull according to the UI) and also did a restore test for every job, which also went successfully. As I was curious, I observed the live log with every task (most of the time...). With nearly every task, I encountered an "error icon" within in the live log on the upper right at one time during the task (not permanently!). But after a refresh, the icon was gone. And, as I said, the tasks themselves have finished with no errors at all. Two examples: Do I have to be concerned that I now have corrupted backups? As mentioned, the restore tests (Level 2) were all fine. And the backups are also listed with status success in the History tab. PS: As you might see, I am also from Germany. ;-) But I'll stick with English here, as maybe other users around the world can also benefit from my findings.

Great, thank you! This helps. On to the next one. ;-) When backing up VMs, it seems that it is "enough" to just back up the domains folder, which means the .img file of every VM. Is the file really everything one needs to get this VM going again? Let's say you backup this img file to an external backup environment and your primary Unraid system literally "burns down". Can I set up a new Unraid system, install your plugin and do a restore job (=restore the img file)? Or do I need more? For example, the well known Appdata Backup plugin offers the possibility to backup "VM meta data", which seems to be the /etc/libvirt/qemu folder.

Hi, thank you for this awesome plugin. I was desperately searching for a "one-stop-shop-solution" replacing my different backup programs (Appdata-Backup, VM-Backup, Duplicati). This plugin seems to be what I am looking for. That being said, I am testing your plugin for my different needs. One of them is my docker containers (about 20). When doing a first test-run, I saw the logs saying something about "priorities" when re-starting the containers. What is that about? I haven't found any priority-settings in your Borg-UI, nor in the Unraid Docker section. According to the log, all my containers are "priority level 3". As I do have some DB containers who should start first, I'd like to use this priority feature. How can I achieve this?

Ich würde das "Problem" mit den Dummy-Ports, die auf Tunable Bad stehen, bei mir auch gerne angehen. Bevor ich mir da ins Knie schieße, würde ich allerdings gerne nochmal 1-2 Sachen klären/hinterfragen. Zum Ist-Zustand: Gigabyte B760M DS3H DDR4 mit Onboard Intel-Sata-Controller. Keine weiteren SATA-Controller im System. Zwei HDDs an den Ports angeschlossen. Host 0-3 stehen auf "bad" (das sind ja Dummy-Ports, so wie ich es verstanden habe) Host 4-7 stehen auf "good" Hier geistern jetzt ja zwei Parameter rum, die das beheben sollen: ahci.mobile_lpm_policy=3 ahci.mask_port_ext=0000:02:00.0=0xffffffff Der Mask-Parameter muss dann noch mit der passenden Adresse abgeändert werden. Bei mir läuft der Controller auf: 00:17.0 SATA controller: Intel Corporation 700 Series Chipset Family SATA Controller (AHCI) (rev 11) Folglich müsste der bei mir korrekte Parameter dann lauten: ahci.mask_port_ext=0000:00:17.0=0xffffffff Ist das so korrekt? Und was ist mit dem "0xffffffff"? Ist das auch system-abhängig? Oder ist dieser Wert immer gleich? Und die Parameter setze ich dann in "Main -> Internal Boot -> Boot parameters"? Ich habe auf Internal Boot umgestellt und seitdem (oder seit 7.3?) sieht das etwas anders aus als früher... Gruß, JD Edit: Ergänzung: Ich habe hier ein Menü "custom parameters". Ich würde vermuten, dass die beiden o. g. Parameter dann hier gesetzt werden müssten:

You were right (as usual... 😄). I just rebooted and updated to 7.3.2 without any problems. Thanks for your support.

You may be right with the temp issue. Now it's also working for me. Nevertheless....now I'm a little hesitant with rebooting...😬 Because I canceled the update process before rebooting during the first try (because of the plugin error) and now, when I start the 7.3.2-update process again, there simply isn't any kind of plugin update helper tool saying anything. No "everything done, please reboot to install 7.3.2" or stuff like that.

It seems that several (maybe all?) of the plugins of user ich777 are affected. At least I found three different threads, where users are all facing the same issue. Unfortunately, it seems that user ich777 wasn't online here for a couple of weeks. Maybe @JorgeB can give some advice? Update to 7.3.2 is strongly recommended, but we can't update because of several plugins aren't ready.

Did a little research myself. I found @ich777 Plugin Helper Github repo (https://github.com/ich777/unraid-plugin_update_helper/blob/master/README.md) and executed the mentioned command in Unraid terminal. Output was: Force Plugin Updates script version: 2026.05.04 by ich777 Please don't close this window until it says finished! /boot/config/plugins/it87-driver/packages/6.18.33/: Is a directory /boot/config/plugins/r8125-driver/packages/6.18.33/: Is a directory Finished, please take a look at your unRAID notifications if all packages where downloaded correctly! So for both my problematic plugins (RTL8125 and IT87) there was an output. After that, Unraid again pushed an error notification. So maybe ich777 can shed a little light on this?

I just ran into a plugin error while initiating the 7.3.2 update: For now, I have canceled the update process to reboot and install 7.3.2. Any advice?

I just ran into the same problem when I was trying to update to 7.3.2. After the error, I have canceled the update process (for now). Hope to get some advice here.

Kann ich auch bestätigen, ist bei mir ebenfalls. Als Disks hängen zwei ST8000VN002 dran.

I've upgraded my 11notes-unifi-reborn-docker to 10.3.58 three days ago (coming from 10.1.89). Worked like a charm (at least for my environment).

Hallo zusammen, ich habe schon Anleitung/KB und Forum durchsucht, aber nix adäquates gefunden. Gibt es bei Unraid eine Möglichkeit, Dateien, die auf einem Share liegen, via http-Link herunterzuladen? Ausschließlich im internen Netz, der Link muss nicht extern verfügbar sein. Also sowas wie http://IP:PORT/mnt/user/share1/file1.jpg oder sowas. Vorzugsweise mit Bordmitteln, also ohne dass ich dazu ein/e App/Plugin/Docker benötige. Und möglichst ohne Authentifizierung (oder ich kann sie über den http-Link mitgeben). Ich kann ja so einen Link auch schon jetzt konstruieren, aber ich lande dann immer in der Unraid-Anmeldemaske, sprich muss mich authentifizieren. Hintergrund: Ich habe eine Smarthome-Applikation, die regelmäßig über http Dateien abrufen will/muss. Die Dateien habe ich aktuell auf einem Internet-Webserver liegen, sie werden also aus dem Internet abgerufen. Ich würde sie aber lieber intern bei mir im LAN ablegen. Hat da jemand einen Tipp? Danke & Gruß, JD