8 minutes ago, XCrownedClownsX said:

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?

Sure! So my setup is I have all my appdata on a zfs filesystem for my docker and for my vms.

mount point: /mnt/docker_vm_nvme/appdata/<app>
user share: /mnt/user/appdata/<app>

To destroy the dataset, you would do
zfs destroy -r docker_vm_nvme/appdata/<app>

Note the '-r' for recursive, this is required if the dataset has snapshots or children exist. If not, you do not need '-r'.

Important to note zfs is case sensitive, so Sonarr and sonarr would be two different datasets.

Let me know if that answers all your questions, thank you

14 hours ago, Muddoggg said:

Sure! So my setup is I have all my appdata on a zfs filesystem for my docker and for my vms.

mount point: /mnt/docker_vm_nvme/appdata/<app>
user share: /mnt/user/appdata/<app>

To destroy the dataset, you would do
zfs destroy -r docker_vm_nvme/appdata/<app>

Note the '-r' for recursive, this is required if the dataset has snapshots or children exist. If not, you do not need '-r'.

Important to note zfs is case sensitive, so Sonarr and sonarr would be two different datasets.

Let me know if that answers all your questions, thank you

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

12 hours ago, XCrownedClownsX said:

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

ZFS created:


After rescan:


Added capital TEST ZFS dataset:


Rescan:



Added child element to dataset with capital TEST:


ZFS found with grep (2 parent, 1 child of TEST):


Rescan does NOT pickup child element (this seems correct to me, I don't believe it should)...

Dry run result with "test" (no child) ZFS dataset


Something I noticed, you cannot delete ZFS dataset even if Enable ZFS dataset delete is enabled, you have to ALSO enable Enable permanent delete... Is that expected?



Dry run for perm delete:


Delete... I believe the text vebiage is incorrect, it's showing "folders" instead of "datasets" on the top label text and on the delete button.


DELETE ran with Error:


Dry run for parent with a child dataset only lists the parent dataset:


Same for the actual delete:


That one errored as well:


Not sure what the share root is... and it seems if I change the path at the bottom then click "Use Current Path" and assign it to a path that doesn't contain any datasets, the rescan still shows my datasets. Is that expected? I'm not really sure what this ZFS mappings is, TBH. Might need some explanation...


Final Notes:
In addition to a dataset having children elements to force '-r', if a dataset has a snapshot, it would require '-r' as well. I didn't test this, because I can't even delete a normal dataset without any children datasets or snapshots yet.

Overall, it's looking good! Thanks for the quick reply.

I just ran this for the first time and let it quarantine a Plex docker I just removed. When I clicked the quarantine button the dialogue letting me know it was moving the files came up and the page hung with a spinning circle. I let it go for a bit and nothing changed. Refreshed the page and it couldn't load. I also was not able to access the server via web browser at all after this. The server was still up and my dockers were running. I went down the server and logged in console and rebooted. Everything is running normally now and the quarantine seems to have worked as the plex folder is gone from appdata and there is a new .quarrantine folder. I'm just not sure how running this borked the web access to the server completely.

I'm assuming the reboot cleared the logs that would have been there, but if there is something I can provide let me know.

Doug

I've downloaded my diagnostics, but I'm not seeing a way to attach it here. Am I missing something?

Here are the relevant log entries for the timeframe. You can see where I updated the plugin before running. Then there are some server web errors and then the reboot.

Apr 10 04:29:13 Tower root: Fix Common Problems Version 2025.08.07

Apr 10 04:29:14 Tower root: Fix Common Problems: Warning: Plugin appdata.cleanup.plus.plg is not up to date

Apr 10 04:29:37 Tower plugin-manager: executing inline script: /usr/bin/php '/tmp/inline1-appdata.cleanup.plus.sh'

Apr 10 04:29:37 Tower plugin-manager: executing inline script: /bin/bash '/tmp/inline2-appdata.cleanup.plus.sh'

Apr 10 04:29:37 Tower plugin-manager: creating: /boot/config/plugins/appdata.cleanup.plus/appdata.cleanup.plus-2026.04.07.10-x86_64-1.txz - downloading from URL https://raw.githubusercontent.com/alexphillips-dev/Appdata-Cleanup-Plus/main/archive/appdata.cleanup.plus-2026.04.07.10-x86_64-1.txz

Apr 10 04:29:40 Tower plugin-manager: checking: /boot/config/plugins/appdata.cleanup.plus/appdata.cleanup.plus-2026.04.07.10-x86_64-1.txz - MD5

Apr 10 04:29:40 Tower plugin-manager: running: upgradepkg --install-new /boot/config/plugins/appdata.cleanup.plus/appdata.cleanup.plus-2026.04.07.10-x86_64-1.txz

Apr 10 04:29:41 Tower plugin-manager: executing inline script: /bin/bash '/tmp/inline4-appdata.cleanup.plus.sh'

Apr 10 04:29:41 Tower plugin-manager: appdata.cleanup.plus.plg updated

Apr 10 04:40:01 Tower root: Fix Common Problems Version 2025.08.07

Apr 10 04:44:20 Tower nginx: 2026/04/10 04:44:20 [error] 5412#5412: *675 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.23, server: , request: "POST /plugins/appdata.cleanup.plus/include/exec.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock", host: "192.168.1.10", referrer: "http://192.168.1.10/Settings/AppdataCleanupPlus"

Apr 10 04:44:41 Tower nginx: 2026/04/10 04:44:41 [error] 5412#5412: *689 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.23, server: , request: "GET /Settings/AppdataCleanupPlus HTTP/1.1", subrequest: "/auth-request.php", upstream: "fastcgi://unix:/var/run/php-fpm.sock", host: "192.168.1.10", referrer: "http://192.168.1.10/Settings"

Apr 10 04:44:41 Tower nginx: 2026/04/10 04:44:41 [error] 5412#5412: *689 auth request unexpected status: 504 while sending to client, client: 192.168.1.23, server: , request: "GET /Settings/AppdataCleanupPlus HTTP/1.1", host: "192.168.1.10", referrer: "http://192.168.1.10/Settings"

Apr 10 04:57:16 Tower login: pam_unix(login:session): session opened for user root(uid=0) by LOGIN(uid=0)

Apr 10 04:57:16 Tower elogind-daemon[2384]: New session 1 of user root.

Apr 10 04:57:16 Tower login: ROOT LOGIN ON tty1

Apr 10 04:57:58 Tower shutdown[136084]: shutting down for system reboot

Apr 10 04:57:59 Tower init: Switching to runlevel: 6

Apr 10 04:58:02 Tower elogind-daemon[2384]: Removed session 1.

Apr 10 04:58:05 Tower rc.6: Running shutdown script /etc/rc.d/rc.6:

Apr 10 04:58:05 Tower init: Trying to re-exec init

Apr 10 04:58:05 Tower rc.6: Saving system time to the hardware clock (UTC).

Apr 10 04:58:05 Tower rc.6: Creating system time correction file /etc/adjtime.

Apr 10 04:58:05 Tower rc.6: /sbin/hwclock --utc --systohc

Apr 10 04:58:05 Tower rc.6: Save PCI Configuration.

Apr 10 04:58:07 Tower rc.local_shutdown: Waiting up to 90 seconds for graceful shutdown...

Apr 10 04:58:07 Tower kernel: mdcmd (36): nocheck cancel

Edited April 10Apr 10 by [email protected]

2 hours ago, [email protected] said:

I just ran this for the first time and let it quarantine a Plex docker I just removed. When I clicked the quarantine button the dialogue letting me know it was moving the files came up and the page hung with a spinning circle. I let it go for a bit and nothing changed. Refreshed the page and it couldn't load. I also was not able to access the server via web browser at all after this. The server was still up and my dockers were running. I went down the server and logged in console and rebooted. Everything is running normally now and the quarantine seems to have worked as the plex folder is gone from appdata and there is a new .quarrantine folder. I'm just not sure how running this borked the web access to the server completely.

I'm assuming the reboot cleared the logs that would have been there, but if there is something I can provide let me know.

Doug

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?

12 hours ago, Muddoggg said:

ZFS created:


After rescan:


Added capital TEST ZFS dataset:


Rescan:



Added child element to dataset with capital TEST:


ZFS found with grep (2 parent, 1 child of TEST):


Rescan does NOT pickup child element (this seems correct to me, I don't believe it should)...

Dry run result with "test" (no child) ZFS dataset


Something I noticed, you cannot delete ZFS dataset even if Enable ZFS dataset delete is enabled, you have to ALSO enable Enable permanent delete... Is that expected?



Dry run for perm delete:


Delete... I believe the text vebiage is incorrect, it's showing "folders" instead of "datasets" on the top label text and on the delete button.


DELETE ran with Error:


Dry run for parent with a child dataset only lists the parent dataset:


Same for the actual delete:


That one errored as well:


Not sure what the share root is... and it seems if I change the path at the bottom then click "Use Current Path" and assign it to a path that doesn't contain any datasets, the rescan still shows my datasets. Is that expected? I'm not really sure what this ZFS mappings is, TBH. Might need some explanation...


Final Notes:
In addition to a dataset having children elements to force '-r', if a dataset has a snapshot, it would require '-r' as well. I didn't test this, because I can't even delete a normal dataset without any children datasets or snapshots yet.

Overall, it's looking good! Thanks for the quick reply.

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

2 hours ago, XCrownedClownsX said:

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

Before enable:


After enable:


ZFS mapping shows not selected, and labels make more sense.



Both roots selected and save mapping was done without add mapping:


Save mappings disabled if one is blank:



NOTE: if i click "REMOVE" for the mapping, and click Done and open the modal back up, it is still there:



Rescan after mapping save... NOTE: Elements are not selectable on the check box, to quarantine. It seems I can only get the elements selectable when i enable perm delete....



Note: If you click rescan after disabling enable zfs dataset delete, it still shows files:


Dry run without recursion:



Children added to test_2:


Dry run with recursion... NOTE: should it list children datasets? it doesn't currently, but does show recursive text.



DELETE of test_1 (no children):




NOTE: the final DELETE for test_2 (with child elements) should show something like dry run does that it is recursive, also it's not showing all children that would be deleted...





Casing test:


Seems like it's working great now! Just a few notes to clean up... Thanks again!

7 hours ago, Muddoggg said:

Before enable:


After enable:


ZFS mapping shows not selected, and labels make more sense.



Both roots selected and save mapping was done without add mapping:


Save mappings disabled if one is blank:



NOTE: if i click "REMOVE" for the mapping, and click Done and open the modal back up, it is still there:



Rescan after mapping save... NOTE: Elements are not selectable on the check box, to quarantine. It seems I can only get the elements selectable when i enable perm delete....



Note: If you click rescan after disabling enable zfs dataset delete, it still shows files:


Dry run without recursion:



Children added to test_2:


Dry run with recursion... NOTE: should it list children datasets? it doesn't currently, but does show recursive text.



DELETE of test_1 (no children):




NOTE: the final DELETE for test_2 (with child elements) should show something like dry run does that it is recursive, also it's not showing all children that would be deleted...





Casing test:


Seems like it's working great now! Just a few notes to clean up... Thanks again!

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

8 hours ago, Muddoggg said:

Before enable:


After enable:


ZFS mapping shows not selected, and labels make more sense.



Both roots selected and save mapping was done without add mapping:


Save mappings disabled if one is blank:



NOTE: if i click "REMOVE" for the mapping, and click Done and open the modal back up, it is still there:



Rescan after mapping save... NOTE: Elements are not selectable on the check box, to quarantine. It seems I can only get the elements selectable when i enable perm delete....



Note: If you click rescan after disabling enable zfs dataset delete, it still shows files:


Dry run without recursion:



Children added to test_2:


Dry run with recursion... NOTE: should it list children datasets? it doesn't currently, but does show recursive text.



DELETE of test_1 (no children):




NOTE: the final DELETE for test_2 (with child elements) should show something like dry run does that it is recursive, also it's not showing all children that would be deleted...





Casing test:


Seems like it's working great now! Just a few notes to clean up... Thanks again!

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

13 hours ago, [email protected] said:

I just ran this for the first time and let it quarantine a Plex docker I just removed. When I clicked the quarantine button the dialogue letting me know it was moving the files came up and the page hung with a spinning circle. I let it go for a bit and nothing changed. Refreshed the page and it couldn't load. I also was not able to access the server via web browser at all after this. The server was still up and my dockers were running. I went down the server and logged in console and rebooted. Everything is running normally now and the quarantine seems to have worked as the plex folder is gone from appdata and there is a new .quarrantine folder. I'm just not sure how running this borked the web access to the server completely.

I'm assuming the reboot cleared the logs that would have been there, but if there is something I can provide let me know.

Doug

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.

Edited April 11Apr 11 by XCrownedClownsX

Apologies I forgot to come back and check for follow up.

At the time I was running 7.2.2. I just upgraded to 7.2.4 this morning.

I only tried it the one time. I just went back and checked and that Plex folder was 16.3 GB. I had no idea the plex folder would get that large.

I have attached the entire diagnostics file from that session in case it's helpful.

tower-diagnostics-20260410-0816.zip

Edited April 12Apr 12 by [email protected]

3 hours ago, demiller said:

Apologies I forgot to come back and check for follow up.

At the time I was running 7.2.2. I just upgraded to 7.2.4 this morning.

I only tried it the one time. I just went back and checked and that Plex folder was 16.3 GB. I had no idea the plex folder would get that large.

I have attached the entire diagnostics file from that session in case it's helpful.

tower-diagnostics-20260410-0816.zip

Were you able to test on the latest dev release?

On 4/10/2026 at 9:49 PM, XCrownedClownsX said:

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

1. Safety flow

- Confirm ZFS mappings is hidden until Enable ZFS dataset delete is checked -> working

- Confirm ZFS rows still require Enable permanent delete before they become actionable -> working

2. Mapping workflow

-> all working

3. Discovery vs mapping behavior

working

4. ZFS preview and delete

working

5. Actual delete behavior

DELETE works for both. NOTE: It might still be good to add child datasets to the delete modal for brevity.

6. Case sensitivity

Looking great! Thanks.

Appdata Cleanup Plus v2026.04.13.02

The 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 Release

This 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 Summary

For 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 Included

This 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 / Feedback

If 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

hi running a scan with the new plugin lags out my server. it stops responding for approx. 1 1/2 min

I'm having the same issue of plugin scanning for 15 or more minutes and then hangs WebUI. I can run my dockers via Homarr and they seem to be working. The last successful scan and quarantine I did was over a week ago. I am running Unraid version 7.2.4 and Appdata Cleanup Plus 2026.04.13.02. I removed plugin and reinstalled depreciated plugin and ran fine. Cleared orphaned folders. Removed depreciated plugin and reinstalled Appdata Cleanup Plus. Selected plugin to scan and hung WebUI after another 10 minutes of Scanning appdata sources and saved Docker templates.

Edited April 22Apr 22 by etrevi1

@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.

Appdata Cleanup Plus 2026.04.23.02 is now live on the main channel.

This stable release rolls up everything completed since the previous main release, 2026.04.13.02, including new support tooling, scan UX improvements, row-level detail workflows, selection and view presets, stronger inline guidance, and a fix for large scans that could hang the WebUI or hit gateway timeouts.

Features

- Added a Tools workflow with redacted diagnostics export for support and troubleshooting.

- Added Copy support summary so current version, scan counts, safety toggles, scan roots, ZFS state, notices, and quarantine totals can be copied quickly into forum posts or issue reports.

- Added a dedicated Scan summary panel so scan-root coverage and result breakdowns are easier to review at a glance.

- Added per-row Details dialogs so each candidate can show source evidence, safety state, storage metadata, path context, and stats before actioning it.

- Added saved view presets for common filter and sort combinations.

- Added bulk selection presets for ready rows, discovery-only rows, ZFS-backed rows, and rows older than 90 days.

Fixes

- Fixed large-scan WebUI hangs and gateway timeouts by keeping the initial scan request focused on orphan discovery instead of bundling all secondary dashboard work into the first response.

- Deferred audit-history and quarantine-summary loading until after the main scan renders, so large scans become responsive sooner.

- Optimized nested reference checks so filesystem discovery no longer walks every template path and live mount for every candidate folder.

- Hardened the main release worktree guard for Windows/shared checkout environments used during release automation.

UI

- Removed the extra search preset row so the dashboard stays cleaner and the bottom selection controls remain the primary preset workflow.

- Flattened and polished the bottom-bar preset control so it aligns better with adjacent actions.

- Added clearer inline blocker badges for ZFS delete disabled, permanent delete mode disabled, mapped-but-nonexact ZFS paths, and generic policy locks.

UX

- Improved empty-state guidance so zero-result scans better explain what was checked and what to verify next.

- Improved row-level guidance so locked, review, ignored, ZFS-backed, and manually unlocked rows are easier to interpret.

- Expanded row-level ZFS context to show matched share roots, matched dataset roots, and checked dataset-side path variants.

- Added on-demand ZFS destroy previews in row details so recursive impact, child datasets, and snapshots are visible without starting a delete flow first.

Support and privacy

- Diagnostics exports are redacted by default so app names, template filenames, and filesystem paths are safer to share while still preserving useful troubleshooting structure.

- Support summary output now makes it much easier to report the current scan state without manually gathering details.

As always, if you hit anything unexpected after updating, please post your support summary or diagnostics export in the support thread and include what you were scanning when the issue happened.

Edited April 23Apr 23 by XCrownedClownsX

I just ran this and it completely fucked my system... it boots up but I can not log into it nothing... WTF!!!!

I can not even get an HDMI signal to get into my bios.....

Update:

Unplugged my GPU, was able to get into Bios, loading now... will update soon

Had to delete and redownload plug ins... seems to be working now...

Edited April 27Apr 27 by itbemark
update

48 minutes ago, itbemark said:

I just ran this and it completely fucked my system... it boots up but I can not log into it nothing... WTF!!!!

I can not even get an HDMI signal to get into my bios.....

Update:

Unplugged my GPU, was able to get into Bios, loading now... will update soon

Had to delete and redownload plug ins... seems to be working now...

No ones else has had severe issues like this. Can you give me your diagnostic export as well as step by step what happened so i can see if I can reproduce it?

Also what version of Unraid are you on?

I just downloaded diagnostics, unfortunately, its starts at 10am, after I uninstalled the GPU, went into bios, booted from there, and deleted and redownloaded the GPU drivers...

I am on 7.2.4...

What I did was open it up it showed me a bunch or orphaned stuff... I did move to temp folder... it just sat there spinning for ~10 mins.. tried to access login page from another tab, nothing... so let it go for another 5 mins tried again, nada... turned off the machine.. would turn on but no signal from GPU.. did this multiple times.. took power away from GPU, used MB's HDMI was able to get into bios.. Booted from there it worked.. uninstalled GPU drivers.. shutdown.. hooked GPU back up, turned on went to bios to check it was working... booted... went to open the app (it had been downgraded for some reason)... just spinning for 3-5 mins and basically froze the system... turned it off.. everything booted correctly... deleted plug in...

I used the old one for a long time, I just upgrade to this one a week ago.

My system is strong so its not that, my old CPU died so I took my old gaming computer and used that CPU and RAM that was just sitting in the closet...


i5-12600k, 64 GB of DDR4 RAM, GPU is B570 (which gets used very sparingly, just installed it and took the old 3060ti that was with AMD set up out)

16 minutes ago, itbemark said:

I just downloaded diagnostics, unfortunately, its starts at 10am, after I uninstalled the GPU, went into bios, booted from there, and deleted and redownloaded the GPU drivers...

I am on 7.2.4...

What I did was open it up it showed me a bunch or orphaned stuff... I did move to temp folder... it just sat there spinning for ~10 mins.. tried to access login page from another tab, nothing... so let it go for another 5 mins tried again, nada... turned off the machine.. would turn on but no signal from GPU.. did this multiple times.. took power away from GPU, used MB's HDMI was able to get into bios.. Booted from there it worked.. uninstalled GPU drivers.. shutdown.. hooked GPU back up, turned on went to bios to check it was working... booted... went to open the app (it had been downgraded for some reason)... just spinning for 3-5 mins and basically froze the system... turned it off.. everything booted correctly... deleted plug in...

I used the old one for a long time, I just upgrade to this one a week ago.

My system is strong so its not that, my old CPU died so I took my old gaming computer and used that CPU and RAM that was just sitting in the closet...


i5-12600k, 64 GB of DDR4 RAM, GPU is B570 (which gets used very sparingly, just installed it and took the old 3060ti that was with AMD set up out)

I reviewed this from the plugin side.

The WebUI spinning/freezing part could plausibly have been Appdata Cleanup Plus, especially if you were on an older build. We recently fixed a class of large-scan/quarantine response issues where the plugin could keep the Unraid WebUI busy long enough to look hung or trigger gateway timeouts. That fix is in 2026.04.23.02.

The GPU/no HDMI/no BIOS signal part does not line up with anything the plugin directly does. Appdata Cleanup Plus scans Docker templates/appdata folders, checks folder sizes, and moves selected orphaned folders into quarantine. It does not load/unload GPU drivers, touch PCI devices, change BIOS/boot settings, reboot/shutdown the server, or manage GPU driver plugins.

My best read is:

- The WebUI hang may have been caused by the plugin, and that is the exact type of issue the latest release was intended to address.

- The GPU/no display issue was most likely separate, or possibly triggered indirectly by the forced power-off while the system was already under load/hung.

- I do not see a direct path where Appdata Cleanup Plus could break GPU output or prevent BIOS display.

If you are willing to help narrow it down, please share:

- The exact Appdata Cleanup Plus version you were running when it happened.

- Whether you installed from the main/stable link or a dev/test link.

- Whether you clicked quarantine/move to temp, dry run, or permanent delete.

- The paths/items that were selected, if you remember.

- The plugin support summary/diagnostics if the plugin still opens.

- /boot/config/plugins/appdata.cleanup.plus/cleanup-audit.jsonl

- /boot/config/plugins/appdata.cleanup.plus/quarantine-records.json

- Syslog from the time of the event, if you had syslog mirroring enabled.

For now, I would update to 2026.04.23.02 before testing again. That version specifically reduces large-scan WebUI hangs/timeouts.

latest version installed, still getting stalled web UI, watching syslog got max children reached, restarted php-frm and web UI came back.....

suggestions?

seeing same issue.