KluthR

Without checking the debug log: is the source path(s) set correctly? Are the container settings correct? Did you checked the „external volume“ logic?

Thanks. Ill review the changes asap

If first time group, just type some groupname in and save. Then the list becomes available

Create a PR. Seems ok except the variable starts with an uppercase „C“. 😅 apart from that the changes look good. I also want to play with ZFS snapshots but time is still limited. Ill do my best to continue work later.

Not possible (yet)

Thats because /mnt is excluded. Either in container or global exclusion list

No, it does not. If you create a folder inside the array or pool, unraid think it a user share an list it. Change the destination so it points in a folder inside a share. (One level deeper)

Never checked that. But it should remain that.

Depends. I missed to check that on the log. Please review the backup-method setting. It controls the backup procedure.

I dont think that this is an issue with the plugin, since it just sees the filesystem. I dont know how Unassigned drives are mounted on the current beta but, if its a simple path like now, it should work. I didnt had the time to setup my dev environment to beta yet. The log shows, that verification fails due to files which shrank. Is anything outside plex accessing these files? I dont see anything on the docker side which uses the same path.

Seems that somewthing is still working with the files. The debug log is missing the lsof section for tar creation (it shows what is accessing the paths). This section is only being written if verification fails, not if creation fails. I should change this. I dont see any other container using the path though.

No. And it does not harm that it does so. A simple "plex" in any name at any position triggers this UI-only information.

That would only apply to "Stop-All" method then. But: No, not possible currently. preBackup is being triggered before determining the method. postBackup after dockers are started again. Your request would require some changes in the code.

One per backup. So, changing number of to-keep-backups also changes the to-keep- flash backups.

Maybe you should reading the log then? The error comes from tar which fails to backup due to "mod time differs" error. The path in question (/mnt/cache/appdata/plex) is being accessed by (another?) Plex. The container "plex" however, is stopped. So, some other process is modifying the files during backup. Thats the issue.

Why? What are the advantages?

That would need manual extraction then. The restore function copies the contents at the same oaths as they were during backup. The restore function needs a bit more love to be able of this in future.

A new update includes enhancements for better debugging. Stay tuned

Share debug log. the copy of flash backup is a simple „cp“ command, so Im unable to tell whats wrong.

I guess thats something for an own thread. I dont see any relation to the plugin as it only stops/starts containers and packs data together.

Could someone test this yet?

So it seems you are affected by this bug as well. I cant reproduce it yet. Please view a fee posts before yours, I wrote a few things about it. Maybe you could male the mentioned changed and report back?

The list has a info above: "Each following paths need to be prefixed with your correct appdata path!". And this prefix is (in your case) "/mnt/user/appdata". Thats totally ok then.

Need more info. If the db path was included inside the backup, it should be restored correctly and the 1:1 sorce path. You could check the file contents by browsing the backup destination/run folder and open the archive which holds the database. the restore should also create a debug file which you could submit. Just checked - the script does not CREATE the destination at all! One has to create the main destination itself.

Regarding contaioner order: I created myself ~160 dummy containers. The AppdataBackup page settings is now huge but ordering works as expected. @affected users, could you tell me which browsers you use? Due to a debug logging issue (https://forums.unraid.net/bug-reports/stable-releases/61210-javascript-consoledebug-and-consolelog-disabled-due-to-vue-i18n-r3084/), you have to make another change to display me some information. Could you open the settings.php file once again, scroll to line ~907 (the line reading "$('#abSettingsForm').on('submit', function () {". A few lines later (~922) you should see two lines of " });". The latter of those both matter for the next step: Replace the WHOLE BLOCK with this: $('#abSettingsForm').on('submit', function () { console.error("SUBMIT!"); let mainValue = $('#containerOrderSortable').sortable('serialize', { expression: /(.+?)_(.+)/ }); console.error('Main order value: ', mainValue); $('#containerOrder').val(mainValue); $("input[id^='containerGroupOrder']").each(function (index) { console.error("Processing groupOrder " + $(this).attr('id')); let groupValue = $('#' + $(this).attr('id') + '_Sortable').sortable('serialize', { expression: /(.+?)=(.+)/ }); console.error('Group order value', groupValue); $(this).val(groupValue); }); console.error('Final form:', $(this).serialize()); console.error("Submit halted!"); return false; }); Then save, reload settings page and hit F12 (the developer console). Open the tab called "Console". Hit Submit on the settings page. Nothing will happen, which is fine. But the console will output some red lines. Maybe you can send me a PM with the result? Should look like: To re-enable submission either redo all changes ot just remove the "return false;" line at the last few lines.