20 minutes ago, chodeus said:

Are you talking about uninstalling and reinstalling the whole plugin?

Did you try hard refreshing your browser?

Any dev console errors in your web browser? (f12)

Yes uninstalling and reinstalling the whole plugin.
Yes. I hard refresh my browser. Also, tried different browser.
This is what it look like in the browser dev console:

When I install the plugin.

When I uninstall the plugin:

@chodeus Can you try this on your end? Uninstalling and reinstalling the whole plugin? Thanks.

BTW, these are the logs on syslog:

Aug 13 20:57:42 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline4-folder.view3.sh'
Aug 13 20:57:42 HHUBS plugin-manager: folder.view3.plg removed 
Aug 13 20:58:26 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline1-folder.view3.sh'
Aug 13 20:58:26 HHUBS plugin-manager: creating: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - downloading from URL https://raw.githubusercontent.com/chodeus/folder.view3/main/archive/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 20:58:26 HHUBS plugin-manager: checking: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - MD5
Aug 13 20:58:26 HHUBS plugin-manager: running: upgradepkg --install-new /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 20:58:26 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline3-folder.view3.sh'
Aug 13 20:58:26 HHUBS plugin-manager: folder.view3.plg installed
Aug 13 21:02:49 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline4-folder.view3.sh'
Aug 13 21:02:49 HHUBS plugin-manager: folder.view3.plg removed
Aug 13 21:03:09 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline1-folder.view3.sh'
Aug 13 21:03:09 HHUBS plugin-manager: creating: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - downloading from URL https://raw.githubusercontent.com/chodeus/folder.view3/main/archive/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 21:03:09 HHUBS plugin-manager: checking: /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz - MD5
Aug 13 21:03:09 HHUBS plugin-manager: running: upgradepkg --install-new /boot/config/plugins/folder.view3/folder.view3-2026.08.01-x86_64-1.txz
Aug 13 21:03:09 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline3-folder.view3.sh' 
Aug 13 21:03:09 HHUBS plugin-manager: folder.view3.plg installed
Aug 13 21:04:23 HHUBS plugin-manager: executing inline script: /bin/bash '/tmp/inline4-folder.view3.sh'
Aug 13 21:04:23 HHUBS plugin-manager: folder.view3.plg removed

.

Edited August 13Aug 13 by HHUBS
add logs

@HHUBS appreciate the logs! That makes it a bit more clear for me. If you want the plugin re-installed use this link and do a Force Install

https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg

The uninstall method will be fixed in the next release.

1 hour ago, chodeus said:

@HHUBS appreciate the logs! That makes it a bit more clear for me. If you want the plugin re-installed use this link and do a Force Install

https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg

The uninstall method will be fixed in the next release.

That did the trick, the "Force Install" option. Thank you.

3 minutes ago, HHUBS said:

That did the trick, the "Force Install" option. Thank you.

Glad it worked. I have just pushed an update so it wont be an issue going forward. Appreciate the report!

2026.08.14

• Uninstalling now removes the plugin cleanly after previous version improvements

• Import Everything now accepts a folder.view2 backup file instead of rejecting it as invalid

• Container autostart order fixes

Very minor issue:
I had a category called manual (lowercase) I wanted it initial capitalised as the others, got messaging about duplicate category name when renaming to Manual.
Worked around it by changing to manual1 then to Manual, seems some regex is case insensitive, should it be?

8 hours ago, the1_ts said:

Very minor issue:
I had a category called manual (lowercase) I wanted it initial capitalised as the others, got messaging about duplicate category name when renaming to Manual.
Worked around it by changing to manual1 then to Manual, seems some regex is case insensitive, should it be?

What do you mean by “category”?

Which page of the plugin are you on?

Hi, I had an issue, this is what my bot figured out. Thx!

Bug: a folder whose id is not pure base64 can never be deleted — and trying freezes the page

Plugin: Folder View 3 (folder.view3) 2026.08.28 Symptom: duplicate folders the UI refuses to remove, and a page that freezes behind a spinner when you try to delete one.

What I saw

Three folders named "LLM infra" on the Docker page. Two were empty and would not delete. The config held these keys:

grp_llm_infra          LLM infra   containers=[]                                    <- stuck
5xJlQxP162Ql9LjIXLs    LLM infra   containers=[llamacpp,ollama,LiteLLM,litellm-db]  <- the real one
yqzdeavmb0bCdsOQ3A     LLM infra   containers=[]

Root cause

generateId() mints ids from base64 with +, / and = stripped, so a folder id the plugin creates is always [A-Za-z0-9]{1,20}:

// server/lib.php:1547
function generateId(int $length = 20) : string {
    return substr(str_replace(['+', '/', '='], '', base64_encode(random_bytes(...))), 0, $length);
}

But three code paths validate ids against the full base64 alphabet, which allows the three characters generateId() removes and forbids everything else — including _ and -:

// server/delete.php:6
if (empty($id) || !preg_match('/^[A-Za-z0-9+\/=]+$/', $id)) { http_response_code(400); exit; }

// server/update.php:6
if (!empty($id) && !preg_match('/^[A-Za-z0-9+\/=]+$/', $id)) { http_response_code(400); exit; }

// server/lib.php:785 (updateFolderIds)
if (!preg_match('/^[A-Za-z0-9+\/=]+$/', $folderId)) continue;

So a folder keyed grp_llm_infra is unreachable by the plugin's own UI:

• Delete → HTTP 400, nothing happens.

• Edit / save settings → HTTP 400, nothing happens.

• Container membership → silently skipped, so the folder can never stop being empty. This is why the stuck folder showed containers: [] while its containerImages still named the containers someone had put in it.

It is a permanent, self-inflicted orphan: the one operation that would clear it is the one operation its id forbids.

The worse knock-on: deleting one of these freezes the page

Three of the four delete entry points await the POST with no rejection handling, after showing a full-screen spinner overlay:

// scripts/shared.js:700 — fv3RmFolder, used by the Docker tab (docker.js:801)
//                        and the VMs tab (vm.js:471)
// scripts/dashboard.js:816 — rmDockerFolder, used by the Dashboard (dashboard.js:1074)
$('div.spinner.fixed').show('slow');
await $.post('/plugins/folder.view3/server/delete.php', { type: type, id: id }).promise();
setTimeout(loadlist, 500);

The 400 rejects the promise, the await throws, and nothing catches it. So:

• loadlist is never scheduled,

• the swal stays open with showLoaderOnConfirm: true — buttons disabled, spinner running,

• and div.spinner.fixed, shown one line earlier, is never hidden.

The result is a full-screen overlay plus a locked modal with no way out but a page reload. It reads as "the browser hung when I deleted that folder". The page is not busy — it is covered by two spinners that nothing will ever dismiss.

Only scripts/folderview3.js:240 (the Folder View settings page) wraps the POST in try/catch, and that one correctly reports "Failed to delete folder: Bad Request". So whether this bug is a readable error or a frozen page depends purely on which of the four screens you happened to delete from — and the three that freeze are the three people actually use.

This is the fix worth taking first, independently of the id validation: every one of these callers needs the try/catch that folderview3.js already has, hiding the spinner in a finally. Then even an unexpected server error leaves a usable page.

The knock-on: "Remove ALL folders" deletes nothing

scripts/folderview3.js:276 loops every id inside a single try:

for (const cid of Object.keys(dockers)) {
    await $.post('/plugins/folder.view3/server/delete.php', { type: 'docker', id: cid }).promise();
}

The first 400 rejects the promise, the loop aborts, and the catch shows a generic "Failed to clear all folders". Object keys are in insertion order, so if the unreachable folder is early — mine was first — a bulk clear removes nothing at all and gives no clue why. That is what makes this look like "the folders cannot be deleted" rather than "one id is bad".

Suggested fix

Widen the three validators to cover any key that can legitimately be in the file, while still rejecting nothing the plugin needs to reject (the id is a JSON key, never a path):

if (!preg_match('#^[A-Za-z0-9+/=_-]{1,128}$#', $id)) { ... }

Then three behaviour fixes, the first of which matters most — it makes every failure readable instead of fatal to the page:

1. Handle the rejection in every delete caller (shared.js:700, dashboard.js:816), the way folderview3.js:240 already does, and hide div.spinner.fixed in a finally. This one turns a frozen page into a readable error, whatever the server says.

2. Never let a delete be refused for the id's shape. Deleting is the escape hatch. If any validation must stay, delete should be the one path that always accepts an existing key.

3. Do not abort the bulk clear on one failure. Collect the failures, delete the rest, and report which ids were refused — the current generic error hides the single bad key.

Repro

1. Add a folder to /boot/config/plugins/folder.view3/docker.json under a key containing _ or - (a UUID key does it, which is what automation tends to write).

2. Reload the Docker page. The folder appears.

3. Delete it from the Docker tab, the VMs tab or the Dashboard → the page freezes behind a spinner that never clears (400 in the network tab). Only a reload recovers it.

4. Delete it from the Folder View settings page instead → a readable "Bad Request" error.

5. Try "Remove ALL folders" → nothing is deleted at all, generic error.

Workaround until it is fixed

Edit /boot/config/plugins/folder.view3/docker.json by hand — back it up first, stop at a valid JSON object, and re-key the folder rather than deleting it, so its settings and membership survive:

"grp_llm_infra": { ... }   →   "VHlVa0Cw7yvX13LPgDVe": { ... }

Any key of 20 or fewer letters and digits works. Reload the Docker page and the folder behaves normally again.

Note for anyone scripting this file

If you register folders from a script, mint the key as [A-Za-z0-9]{1,20}. A UUID looks like the safe choice and is exactly the one that gets stuck.

@johner thankyou for reporting that. Did your bot happen to get a copy of your plugin diagnostics while this issue was present? Would be beneficial if you sent that to me.

@johner did you have your AI setup FolderView3 by chance and it modified the docker.json itself?

3 hours ago, chodeus said:

@johner did you have your AI setup FolderView3 by chance and it modified the docker.json itself?

Sorry, didn’t get the diagnostics, and yes at one point I got it to group a ton of containers it was managing.

It was a mix of auto and manual config.

11 minutes ago, johner said:

Sorry, didn’t get the diagnostics, and yes at one point I got it to group a ton of containers it was managing.

It was a mix of auto and manual config.

No problem. I appreciate people trying to break the plugin so I know how to strengthen it 😂

In future, try to not let it modify the .jsons and have it make the changes via the webui instead.

This should be resolved when I’m ready to release the next stable version.

Thankyou for reporting it!

Edited September 12Sep 12 by chodeus

Hi, after updating the plugin yesterday my folders are no longer working, and I get the following errors on my docker list as well as when trying to create a new folder:

When I go to the plugin settings page, all my folders are gone. I don't know what happened but something in the update left it in an unusable state. I feel like I will probably need to wipe all data and start over with this plugin, but not sure how to do that? I tried clearing the docker folders in the setting page but didn't fix this error. Are there some files on the OS file system I can remove to get back to a "fresh install" status?

Thanks

1 hour ago, sitheris said:

Hi, after updating the plugin yesterday my folders are no longer working, and I get the following errors on my docker list as well as when trying to create a new folder:

When I go to the plugin settings page, all my folders are gone. I don't know what happened but something in the update left it in an unusable state. I feel like I will probably need to wipe all data and start over with this plugin, but not sure how to do that? I tried clearing the docker folders in the setting page but didn't fix this error. Are there some files on the OS file system I can remove to get back to a "fresh install" status?

Thanks

Your best bet is to downgrade for now. The plugin author has a terminal command posted on their GitHub plugin page that I used. Here’s a link to it. https://github.com/chodeus/folder.view3/releases/tag/v2026.09.17

44 minutes ago, akai008 said:

Your best bet is to downgrade for now. The plugin author has a terminal command posted on their GitHub plugin page that I used. Here’s a link to it. https://github.com/chodeus/folder.view3/releases/tag/v2026.09.17

I will try that thank you!!

7 hours ago, sitheris said:

Hi, after updating the plugin yesterday my folders are no longer working, and I get the following errors on my docker list as well as when trying to create a new folder:

When I go to the plugin settings page, all my folders are gone. I don't know what happened but something in the update left it in an unusable state. I feel like I will probably need to wipe all data and start over with this plugin, but not sure how to do that? I tried clearing the docker folders in the setting page but didn't fix this error. Are there some files on the OS file system I can remove to get back to a "fresh install" status?

Thanks

Can you please send me your debug files? Or your docker.json?

DEBUG MODE

To enable debug mode, type fv3debug on any FolderView3 page (Docker, VM, or Dashboard). You should see a console message confirming it's enabled. Debug output appears in the browser console (F12) with a [FV3] prefix. State persists across page loads — type fv3debug again to disable.

For PHP server-side debug: run touch /tmp/fv3_debug_enabled on the Unraid console. Logs write to /tmp/folder_view3_php_debug.log.

If you have a problem you will likely be asked to share the console output.

6 hours ago, akai008 said:

Your best bet is to downgrade for now. The plugin author has a terminal command posted on their GitHub plugin page that I used. Here’s a link to it. https://github.com/chodeus/folder.view3/releases/tag/v2026.09.17

If you're also experiencing issues can you also send me your debug files so I can fix what is broken or let you know what happened?

@akai008 @sitheris your issue could potentially be related to your autostart file. Unfortunately the debug json I asked for wont give this detail so I need to work on improving that.

I've prepared this PR if you want to test and validate please.

You can install this in CLI, the same way you rolled back to the previous version or you can copy and paste the URL into the manual plugin install section of the Install Plugin page.

plugin install https://github.com/chodeus/folder.view3/releases/download/pr-98-2026.09.17.1.0260919022656/folder.view3.plg forced

Edited September 19Sep 19 by chodeus

Came to see about this issue. I'm having the same issue as @akai008 . I'm fine having this just not work for awhile and eventually work again with an update. But if there's something that's broken w/ it that is a fault or fix on my machine happy to do that fix.

@chodeus reading the thread it's a little unclear on if this issue is w/ the plugin or something those of us seeing the issue have misconfigured on our machine. If there's anything I can do to help test lemme know, but also happy to just leave it broken for a bit if a fix is coming and it will just automatically work on an upgrade.

I have 3 UnRaid boxes and my production box updated the plugin the day it was released with no issues. My other two boxes both had the same error as other posters above. I just tan the CLI: plugin install https://github.com/chodeus/folder.view3/releases/download/pr-98-2026.09.17.1.0260919022656/folder.view3.plg forced and my containers are back. I just had to reorder them. All good. Thank you.

3 hours ago, BigNavy said:

I have 3 UnRaid boxes and my production box updated the plugin the day it was released with no issues. My other two boxes both had the same error as other posters above. I just tan the CLI: plugin install https://github.com/chodeus/folder.view3/releases/download/pr-98-2026.09.17.1.0260919022656/folder.view3.plg forced and my containers are back. I just had to reorder them. All good. Thank you.

6 hours ago, jsatk said:

Came to see about this issue. I'm having the same issue as @akai008 . I'm fine having this just not work for awhile and eventually work again with an update. But if there's something that's broken w/ it that is a fault or fix on my machine happy to do that fix.

@chodeus reading the thread it's a little unclear on if this issue is w/ the plugin or something those of us seeing the issue have misconfigured on our machine. If there's anything I can do to help test lemme know, but also happy to just leave it broken for a bit if a fix is coming and it will just automatically work on an upgrade.

Thankyou for trying out the patch, I'm just pushing it to main now. You're now on the beta release branch, I've pushed this fix to main if you want to use the URL to force install (https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg)

or in CLI

plugin install https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg forced

It is related to broken or missing autostart configs which could simply be because you dont have any containers set to autostart. Unfortunately the debug package in the plugin wont tell me why exactly but I plan on fixing that this week.

Edited September 19Sep 19 by chodeus

2 hours ago, chodeus said:

Thankyou for trying out the patch, I'm just pushing it to main now. You're now on the beta release branch, I've pushed this fix to main if you want to use the URL to force install (https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg)

or in CLI

plugin install https://raw.githubusercontent.com/chodeus/folder.view3/main/folder.view3.plg forced

It is related to broken or missing autostart configs which could simply be because you dont have any containers set to autostart. Unfortunately the debug package in the plugin wont tell me why exactly but I plan on fixing that this week.

I have no containers configured for auto start, so that seems to have been my issue. Thank you for the help.

FWIW @chodeus the latest update fixed my issue. Works fine now. Thank you!

Epic! Sorry for the stuff around!

@Squid not sure who responsible for this, but it looks like @chodeus is still missing CA dev role in forum.