XCrownedClownsX

@sude @etrevi1 Apologies, I was working on a fix for this and implemented in dev but never pushed main due to getting busy in life. I will push an update today to hopefully resolve those issues.

Can you include your diagnostics export? Settings > FolderView Plus > Advanced > Diagnostics, and export at the bottom.

All good, yea if you can manage to grab a screenshot and export your diagnostic file i can take a look.

FolderView Plus 2026.04.17.04: Features, fixes, and UI/UX updatesThis update includes everything shipped since 2026.04.14.17 and brings a mix of new features, bug fixes, UI/UX improvements, Docker runtime upgrades, VM fixes, and broader settings/editor cleanup. What’s new- Added a dedicated Appearance tab with a managed Theme Workspace flow - Added saved folder-default profiles for Docker and VM folders - Added new Docker page views (Found in Settings > Sort Mode and View Settings > Run Time > Docker Page View): - FolderView - No FolderView (host list only) - Command view - Tree explorer - Added privacy mode across settings and runtime surfaces - Added environment snapshot recovery flow and richer support-bundle diagnostics Command View: Tree Explorer View: What’s improved- Reworked Docker Command View and Tree Explorer layout and presentation - Polished settings workspace layout, controls, and shared button chrome - Improved Setup Assistant, rules, smart-detect, starter templates, and folder editor flows - Refactored the shared folder editor so Docker and VM behavior are cleaner without splitting into separate editors Fixes- Fixed Docker update-state refresh after Update All - Fixed Docker isolated-view persistence and native action handling - Fixed Docker privacy toggle placement and rapid-toggle save behavior - Fixed fast Docker page-view changes in Settings so the latest selection is preserved - Fixed the folder editor Rules tab deep-link so it opens the correct advanced rules workspace - Fixed the default VM folder icon fallback - Fixed VM detail expansion inside folders so details stay attached to the VM you clicked TestingIf you want to help test this release, the main areas are: - Docker page-view switching and persistence - Docker privacy toggle behavior in all Docker views - Update All clearing Docker update state properly - Theme Workspace / Appearance flows - Folder editor Rules workspace deep-linking - VM folder detail expansion behavior - Support-bundle and recovery flows

FolderView Plus 2026.04.14.17 is now live on main.What’s fixed since the last main release:Uploaded custom icons now persist across reboot, plugin reinstalls, and Unraid upgrades. Custom icons are now stored under /boot/config/plugins/folderview.plus/images/custom instead of only living in the temporary runtime plugin path. The live /plugins/folderview.plus/images/custom/ path is now rebuilt automatically from persistent storage after boot or upgrade, so existing custom icons continue working without needing to be re-uploaded. Fixed custom icon manager request failures on Unraid flash-backed storage. The custom icon list/upload path now uses a /tmp lock file and shared read locks, which resolves the request failures some users were seeing when loading or uploading custom icons. Improved Docker support bundle diagnostics so render-state and update-state issues are easier to troubleshoot from one export. Fixed the orange preview update text option so it now applies correctly when enabled. Still being worked on:The Docker update display bug persists in some cases. I am still working on a proper fix for that, and I am not calling it resolved in this release. Please Test:Upload a custom icon Reboot the server Confirm the icon is still there and still applied Open the custom icon manager and confirm icons load normally Upload, rename, or delete a custom icon, and confirm that those requests complete normally If you use orange preview update text, confirm it shows correctly on containers with updates available If anything still looks wrong, attach a fresh FolderView Plus support bundle and include the exact steps to reproduce it.

Appdata Cleanup Plus v2026.04.13.02The latest round of changes has now been promoted from dev to main. Current stable release:v2026.04.13.02 GitHub release: https://github.com/alexphillips-dev/Appdata-Cleanup-Plus/releases/tag/v2026.04.13.02 Stable install URL: https://raw.githubusercontent.com/alexphillips-dev/Appdata-Cleanup-Plus/main/plugins/appdata.cleanup.plus.plg What’s Included In This ReleaseThis stable release includes everything that was added and refined during the recent dev cycle, including: - ZFS-backed appdata cleanup support @Muddoggg - exact dataset mountpoint resolution - case-sensitive dataset handling - dataset-aware permanent delete using zfs destroy - recursive ZFS destroy support when required - dedicated ZFS mappings workflow - improved ZFS delete wording and confirmation flow - child datasets and snapshots shown in ZFS delete preview/results - stronger safety gating for ZFS-backed rows - quarantine response-path hardening for larger moves - updated docs and extended behavior smoke coverage ZFS Workflow SummaryFor anyone testing the new ZFS-backed cleanup support: - Appdata sources is still only for scan roots - ZFS mappings is now a separate workflow - ZFS mappings stays hidden until Enable ZFS dataset delete is turned on - ZFS-backed rows still require Enable permanent delete before they can actually be destroyed - ZFS-backed rows cannot be quarantined in the current implementation Fixes IncludedThis release also includes the fixes that came out of recent user testing: - clearer ZFS mapping UX - safer save behavior for mapping drafts - better distinction between scan discovery vs ZFS resolution - dataset-specific wording in delete flows - richer recursive ZFS preview details - improved handling for larger quarantine actions so the UI is less likely to hang after a successful move @demiller Testing / FeedbackIf you were testing on dev, please switch to the stable release above and let me know if anything regressed. If you are specifically using the new ZFS-backed cleanup flow, the most useful feedback is still: - dataset detection / resolution - recursive destroy behavior - case-sensitive dataset handling - confirmation / preview clarity - any edge cases around mappings or mixed appdata layouts

Were you able to test on the latest dev release?

Looks like an import bug. Can you attach your exported config and diagnostics from advanced settings so I can see why it didn't import properly? You can DM me if you don't want that info public, even tho its scrubbed by default.

Thanks for the report and for pulling the log lines. I reviewed the code path against what you saw and this did not look like a random one-off. What likely happened:- The quarantine move itself appears to have succeeded, but the response path after the move was still doing extra backend work - On a larger appdata folder like Plex, that could take long enough for nginx/php-fpm to time out - The request was also holding the PHP session lock, which could then block follow-up page/auth requests from the same browser session - That matches what you saw: quarantine actually happened the dialog hung refreshes stopped loading nginx logged upstream/php timeouts I’ve pushed a dev build that hardens this flow.Dev install URL: https://raw.githubusercontent.com/alexphillips-dev/Appdata-Cleanup-Plus/4cb624e/plugins/appdata.cleanup.plus.plg What changed:- The cleanup/quarantine request now releases the PHP session lock before the long-running action work starts - The lightweight quarantine summary path no longer forces expensive uncached size scans right after a quarantine action completes - This should reduce the chance of a successful quarantine ending with a hung spinner and the web UI timing out behind it What to test on dev:1. Quarantine a moderate or larger removed appdata folder - especially one similar to Plex in size/shape if possible 2. Watch the action flow - confirm the quarantine dialog completes normally - confirm the page remains responsive afterward - confirm you can refresh the page immediately without it hanging - confirm you can still navigate around the Unraid web UI normally after the action 3. Confirm the result is still correct - the original appdata folder should be gone from the active appdata path - the quarantined folder should appear under the plugin quarantine location - the quarantine manager should still load normally If you still hit the problem, the most useful things would be:- whether the issue happens every time or only on certain apps - roughly how large the quarantined folder was - whether the web UI hang starts immediately after clicking quarantine or only after waiting a bit - fresh nginx / php-fpm related log lines from the same time window Thanks again for the report. This was a helpful one because the log timing lined up with a real backend issue we could actually harden.

Thanks again for the detailed testing. I went through your feedback and split it into two groups: things that were intentional by design, and things that were actual issues that needed fixing. Dev install URL: https://raw.githubusercontent.com/alexphillips-dev/Appdata-Cleanup-Plus/4be5512/plugins/appdata.cleanup.plus.plg What was intentional:- Yes, ZFS-backed rows require both Enable ZFS dataset delete and Enable permanent deleteThat is expected - zfs destroy is still a permanent delete, so it stays behind the normal permanent-delete safety gate - Child datasets are not supposed to appear as separate top-level orphan rows - The plugin scans direct child appdata folders, not nested descendants - Changing a ZFS mapping does not control whether rows are discovered - Discovery and ZFS resolution are separate - Scan discovery decides whether a row exists - ZFS mappings only decide whether that row resolves to a dataset-backed delete target What was actually wrong and is now fixed:- The original ZFS mappings workflow was too easy to misunderstand - A complete draft could be sitting there unsaved while Configured mappings was still empty - Empty selections showed as /, which was misleading - The labels were unclear - The ZFS mappings button is now hidden until Enable ZFS dataset delete is turned on - Empty selections now show Not selected - The labels are clearer: - Unraid share root - ZFS dataset mount root - The modal now explains that mappings affect ZFS resolution only, not scan discovery - If both roots are selected but you do not click Add mapping, Save mappings now auto-includes that draft - If the draft is incomplete, save is blocked with a clear message - If nothing changed, save is disabled - The delete wording was also wrong before - ZFS delete flows could still show generic folders wording in the confirmation flow - That has been cleaned up so the flow is clearer for dataset-backed deletes - I also added clearer messaging when ZFS dataset delete is enabled but permanent delete mode is still off - Recursive ZFS preview was too thin before - It only showed the parent dataset - The preview/result flow now surfaces recursive impact details so it is clearer when child datasets / snapshots are involved What to test now:1. Safety flow - Confirm ZFS mappings is hidden until Enable ZFS dataset delete is checked - Confirm ZFS rows still require Enable permanent delete before they become actionable 2. Mapping workflow - Open ZFS mappings - Confirm empty fields show Not selected - Confirm the new labels make sense - Pick both roots and click Save mappings without clicking Add mapping - It should still save correctly - Try saving with only one side selected - It should block save with a clear message 3. Discovery vs mapping behavior - Confirm rows still scan normally - Confirm mappings only affect whether matching rows resolve as ZFS dataset-backed rows - Confirm this now feels clearer in the UI text 4. ZFS preview and delete - Dry run a normal ZFS dataset - Dry run a dataset that requires recursive destroy - Confirm the wording looks correct - Confirm the dataset name is shown - Confirm recursive impact details are surfaced when applicable 5. Actual delete behavior - Test a normal dataset delete - Test a recursive dataset delete - Confirm ZFS-backed rows still cannot be quarantined - Confirm non-ZFS rows still behave normally 6. Case sensitivity - Confirm case-sensitive datasets like TEST, Test, and test still stay distinct If anything still looks off, please send:- the exact mapping you saved - the exact app path you tested - whether it was a normal delete or a recursive delete case - a screenshot of the preview/result, if possible

Definitely appriciate all the testing and attention to detail with screenshots. I'll work on getting it polished.

Thanks for the detailed testing and screenshots! I’ve pushed another dev build that addresses the issues you called out. Dev install URL: https://raw.githubusercontent.com/alexphillips-dev/Appdata-Cleanup-Plus/f78e63b/plugins/appdata.cleanup.plus.plg What changed in this build:- The ZFS mappings button is now hidden by default - It only appears after Enable ZFS dataset delete is enabled in Safety settings - This should make the workflow more logical: 1. enable ZFS dataset handling 2. configure ZFS mappings 3. switch to permanent delete mode if you actually want to destroy datasets - The ZFS mappings modal was cleaned up - Empty selections no longer show as / - The labels are clearer now: - Unraid share root - ZFS dataset mount root - The modal now explains that mappings affect ZFS dataset resolution only - Mappings do not change what gets discovered during scan - Saving mappings is safer now - If both roots are selected but you did not click Add mapping, Save mappings will auto-include that draft - If the draft is incomplete, save is blocked with a clear message - If nothing changed, save is disabled - ZFS delete previews/results are clearer - ZFS-backed rows now use dataset-specific wording instead of generic folder wording where appropriate - Dry run and results show the resolved dataset name - Recursive ZFS previews now surface impact details when -r is required - That includes child dataset / snapshot impact information in the preview/result flow - If ZFS dataset delete is turned back off while working in the ZFS mappings UI, the modal is closed cleanly What to test:1. Workflow / visibility - Confirm ZFS mappings is hidden until Enable ZFS dataset delete is checked - Confirm the button appears immediately after enabling the ZFS toggle 2. Mapping modal behavior - Open ZFS mappings - Confirm empty fields show Not selected instead of / - Confirm the new labels make sense - Try selecting both roots and clicking Save mappings without pressing Add mapping - It should still save correctly - Try leaving one side blank and saving - It should block save with a clear message 3. Detection / resolution - Add a mapping like: - Unraid share root: /mnt/user/appdata - ZFS dataset mount root: /mnt/docker_vm_nvme/appdata - Rescan - Confirm the same orphan rows are still discovered as before - Confirm ZFS-backed rows resolve correctly after the mapping is saved 4. ZFS delete preview - In permanent delete mode, run a dry run on a ZFS-backed row - Confirm the preview shows the dataset name - If the dataset requires recursive destroy, confirm the preview says so and shows the extra impact details 5. Actual ZFS delete - Test a normal dataset delete - Test a dataset that requires zfs destroy -r - Confirm both work correctly - Confirm ZFS-backed rows still cannot be quarantined 6. Regression checks - Non-ZFS rows should still behave exactly like normal folders - Case-sensitive datasets like Sonarr vs sonarr should still stay distinct If anything still looks off, please send:- the exact mapping you saved - the app path you tested - whether it was a normal destroy or recursive destroy case - a screenshot of the preview/result if possible

I can look into this issue. What version of Unraid are you running? Are you able to continue to replicate this issue, or did it only happen once?

I’ve added an initial dev build for ZFS-backed appdata cleanup and would appreciate testing. Dev install URL: https://raw.githubusercontent.com/alexphillips-dev/Appdata-Cleanup-Plus/dev/plugins/appdata.cleanup.plus.plg What’s included in this build:- Separate ZFS mappings button in the action bar - Appdata sources stays focused only on scan roots - ZFS mappings are now configured in their own modal - ZFS-backed rows can resolve /mnt/user/appdata/<app> style paths to exact dataset mount roots - ZFS-backed candidates use zfs destroy for permanent delete - If needed, the plugin previews and escalates to recursive destroy -r - ZFS-backed paths cannot be quarantined in this build How to test:1. Install the dev plugin from the URL above. 2. Open Appdata Cleanup Plus. 3. Click ZFS mappings. 4. Add a mapping like: Share root: /mnt/user/appdata Dataset root: /mnt/docker_vm_nvme/appdata 5. Enable ZFS dataset delete in Safety settings. 6. Run a rescan. What you should see:- Orphaned appdata folders backed by exact ZFS datasets should show up as ZFS dataset rows - The dataset name should preserve case exactly, so Sonarr and sonarr stay distinct - ZFS rows should only become actionable in permanent delete mode - Trying to quarantine a ZFS-backed row should be blocked - Permanent delete should use dataset destroy, not normal folder deletion Please test:- Detection after adding a ZFS mapping and rescanning - Case-sensitive dataset names - Standard dataset delete - Recursive delete when snapshots or child datasets exist - That non-ZFS rows still behave normally - That the new ZFS mappings workflow is clearer than having this inside Appdata sources If anything looks wrong, please send:- The app path you tested - The mapping you configured - Whether the dataset needed zfs destroy or zfs destroy -r - A screenshot of the row/result if possible

Thanks for reporting, I will check this out and let you know once I have an update.

Yeah, I can definitely look into it. Can you provide more information, as I don't know anything about the ZFS datasets. Where are they located, mount-wise?

FolderView Plus 2026.04.08.10 is now on mainWhat’s in this release:- Fixed Docker folder/member update actions so switching between basic and advanced view refreshes live instead of leaving stale force update or apply update states behind. @Jaybau - Fixed collapsed Docker folders so expanding them no longer makes every child container look like it has an update when only one or a few actually do. @ailliano - Improved support bundle diagnostics for Docker update-state issues by capturing list-view mode, clearer build provenance, and richer update details. Please test especially on the Docker page with folders that contain a mix of:- containers that are up to date - containers with updates available - collapsed folders - expanded folders - switching between basic and advanced view What I’d like confirmed:- Expanding a folder only shows apply update on the containers that actually need it - force update only shows where expected in advanced view - Switching basic/advanced updates the folder rows and member rows live without needing a page refresh - Refreshing the page does not bring the incorrect state back If anything still looks wrong, please attach a fresh FolderView Plus support bundle and include:- the folder name - which containers are affected - whether basic or advanced view was active - the exact steps that reproduced it That should give enough detail to verify whether there are any remaining Docker update rendering edge cases.

I see the issue on my system as well. Currently working on a fix that should resolve this. Also includes an updated support bundle for better troubleshooting this issue if needed later on.

@VlarpNL Awesome, glad Its working as expected now!

Can you please send me your exported folder config and the support bundle from Settings > Advanced > Diagnostics tab? That way I can troubleshoot why that's happening. (Can be in a DM if you don't want others to see, since you have names blurred).

Appdata Cleanup Plus - 2026.04.07.10Since the last stable cycle, this update mainly adds: - Manual appdata source roots - Better alias-aware path matching - Scan-scoped unlock/relock for review rows - A browseable appdata source picker - Multiple picker UI refinements - Detection of empty parent remnants left behind by nested appdata mounts Manual appdata source support @VlarpNL You can now add extra appdata roots for setups that do not only use the default Docker appdata location. This is intended for systems using paths such as: /mnt/fcache/appdata /mnt/cache/appdata or other non-standard layouts. Configured manual roots are now treated as normal appdata sources during discovery instead of being treated like outside-share paths. Discovery and path matching improvementsThe plugin now does a better job matching appdata paths across different mount styles. This includes improved handling for cases where: /mnt/user/... and pool or disk-backed paths such as /mnt/cache/..., /mnt/fcache/..., or similar all point to the same underlying appdata location. This should reduce false orphan results when live containers or saved templates reference alternate host paths. Lock override for review rows @z0ki A scan-scoped unlock/relock workflow was added for outside-share review rows. This means: - Review rows locked only by outside-share safety can be manually unlocked for the current scan - Hard safety locks still cannot be bypassed - Server-side action validation still enforces the correct rules This gives experienced users a controlled override without weakening the global safety settings. New appdata source picker UIThe manual path entry flow was replaced with a folder picker. You can now: - Browse folder paths directly from the modal - Step up one directory with ... - See the current path while navigating - Add valid appdata roots without manually typing them - Manage multiple manual roots from the same modal Picker UI refinementsThe picker was refined to behave more like native Unraid controls. Updates include: - Cleaner compact folder rows - Left-aligned row content - Removal of host button chrome from folder rows - Reduced padding and tighter spacing - Better path display and parent navigation - Overflow and scrolling fixes New fix: empty parent remnants from nested mounts @Sacred This release also fixes a case where a Docker app uses nested appdata folders such as: /mnt/user/appdata/adguard/config /mnt/user/appdata/adguard/workingdir If those nested folders were removed later, the empty parent folder: /mnt/user/appdata/adguard could be left behind but remain invisible to the plugin because stale nested references still caused the parent to be suppressed. That is now handled more safely: - If a real nested descendant still exists, the parent stays hidden - If the nested descendants are gone and the direct child parent is empty, it is now surfaced as a safe discovery candidate - If the stale parent is not empty, it stays hidden in this first safe pass This should catch empty leftover folders from nested mount layouts without broadening the plugin into a general recursive empty-folder sweeper. Please Test:If you use: - non-standard appdata roots - mixed /mnt/user and pool/disk-backed paths - nested appdata mount layouts - outside-share review rows that need manual unlock - the new folder picker for manual appdata roots please test and report back. Especially useful test cases: - custom appdata roots like /mnt/fcache/appdata - containers using alternate host path mounts - nested layouts like /mnt/user/appdata/<app>/<subfolder> - empty leftover parent folders after nested appdata folders are removed - non-empty leftover parents that should remain hidden - picker behavior on desktop and mobile Please post any issues, path examples, screenshots, or edge cases that still do not behave correctly.

FolderView Plus v2026.04.06.19 Includes a batch of Docker-related fixes plus diagnostics cleanup work. If you were hitting any of the recent issues, please update and test. Included in 2026.04.06.19:- Restored the missing diagnostics fallback detail for Folder details, Rules details, Backup details, and related issue reporting. - Added a diagnostics repair action for stale/orphaned saved member references that no longer exist. - Fixed Docker folder sort syncing so saved order changes now reflect correctly on the Docker page. @Luke_Starkiller - Fixed switching Docker folder sort back to Created so it returns to the correct created order instead of staying stuck in the previous sort. - Added additional folder sort modes: - Created newest first - Created oldest first - Last updated newest first - Fixed a Docker runtime issue where expanding a minimized folder could show Apply update on every container row, when only one container in that folder actually had an update available. @john_smith ~ The current Docker runtime still had a gap where hidden folder member rows were not re-syncing their own td. updatecolumn before being shown again. That let a stale folder/update state bleed into expanded member rows, so one updated container could make every row in that folder look like Apply update. Please test the following:1. Run Health check in Diagnostics and confirm orphaned member issues can be repaired/cleared correctly. 2. Change Docker folder sort modes in Settings and confirm the Docker page reflects the saved order immediately. 3. Switch from A-Z or another explicit sort back to Created and confirm the order resets correctly. 4. Open a Docker folder that contains a mix of updated and non-updated containers and confirm only the containers with real updates show Apply update. If anything still looks wrong on 2026.04.06.19, please post a fresh support bundle from that exact version and include the exact steps to reproduce it.

That is a fair concern, and I want to answer it directly. FolderView Plus replaced the older Folder View line because it is the maintained successor built on the folder.view3 foundation, with compatibility kept intentionally for older installs and migrations. It still supports legacy imports, legacy Docker labels, and legacy CSS/JS override roots, and it also handles conflicts when older Folder View plugins are still present. So this was not meant to be a random replacement with no migration path. On the update frequency: the burst of releases between April 5 and April 6, 2026, was not “normal steady-state churn,” it was a concentrated fix cycle after real user reports started coming in from wider use. Most of those updates were narrow fixes for Docker ordering, diagnostics fallback/reporting, orphaned saved members, and Docker update-state edge cases. I chose to turn those around quickly rather than let known regressions sit for days or weeks. For background, I have over 10 years in IT working as a network/systems engineer. I also test what I push on my own live Unraid server before I ask others to run it. I take security seriously, and I put a heavy focus on defensive checks, validation, and guardrails when building and updating this plugin. On the AI question: yes, I do use AI-assisted tooling during development. But I am not blindly pasting generated code into releases. The work still gets reviewed, traced against the actual codebase, covered with targeted regression tests, and run through release guards/CI before it ships. AI is being used as an accelerator, not as a substitute for understanding or verification. Also, this plugin is not designed to delete user data. FolderView Plus manages folder views, metadata, rules, preferences, and related plugin state. It is not intended to remove your actual Docker appdata, shares, VM disks, or server data. Safety and recovery have been a major focus, which is why there is so much attention on backups, restore paths, validation, and diagnostics. If you want the least amount of churn, stay on main and do not use dev unless I specifically ask for testing there. dev is where I push fast-turnaround fixes so issues can be verified quickly. main is the stable channel. The recent cadence was a response to active bug reports, not the long-term intended pattern. If you are seeing anything on main that still feels off, send me the exact version and a fresh support bundle and I will look at that specific case.

I misunderstood. Does the order change work in settings, but it's not being reflected on the Docker view?

FolderView Plus 2026.04.06.04ChangesThis release includes the full cumulative delta since v2026.04.05.13. Runtime and Preview FixesStabilized Docker and VM runtime rows, folder state handling, and action refresh paths so status surfaces stay aligned during in-place actions. Fixed Docker preview cards, status icons, labels, and action buttons to live-refresh after folder actions instead of showing stale started, paused, or stopped state. Ensured Docker preview click menus and native container menus resync runtime state before opening so context actions match the current container state. Diagnostics and ClarityDiagnostics health cards now call out the real Docker or VM integrity issue instead of falling back to generic folder, rule, or backup counts. Added targeted regression coverage for diagnostics summary rendering, orphaned-member reporting, and path-issue presentation. @Luke_Starkiller @john_smith Please test the latest release, the previous issues should be resolved. From my testing it works on my side, If it still persists let me know.