18 minutes ago, XCrownedClownsX said:

@shiftylilbastrd It shows you the time added in a badge and the scheduled purge below.

Also, you have to have an item selected for those buttons to be enabled.

No it doesn't

19 minutes ago, XCrownedClownsX said:

@shiftylilbastrd It shows you the time added in a badge and the scheduled purge below.

Also, you have to have an item selected for those buttons to be enabled.

Oh I see. It should apply the purge timer automatically, I shouldn't have to do another step. That's the idea behind having a default purge time.

On 3/30/2026 at 2:20 AM, skywalker6705 said:

Like with your other project, Folderview Plus, this feels distinctly vibe coded on top of an existing app to "enhance" it.

I have some serious reservations about using this given that you haven't disclosed any use of AI in the process at all.

A bit of skepticism is warranted after the Huntarr debacle. The Github account ( https://github.com/alexphillips-dev) had on average about 5 contributions per year between 2021 and 2025. It has 1,700 contributions in 2026 so far.

There's no clear indication on the original plugin's Unraid forum thread that the creator is deprecating the plugin (https://forums.unraid.net/topic/51961-plugin-ca-cleanup-appdata/)

The original plugin dates back to 2016, and had a pretty bare-bones GUI. This new one created over the space of two months is much more polished.

@shiftylilbastrd It's not a default purge time. It only lets you set a purge time for quarantine items if you want to.

I can implement a default purge timer that can be enabled for all items moved to quarantine.

1 minute ago, XCrownedClownsX said:

@shiftylilbastrd It's not a default purge time. It only lets you set a purge time for quarantine items if you want to.

I can implement a default purge timer that can be enabled for all items moved to quarantine.

Thanks. I just feel this would fulfill the desire to be "safe" without having to make it a convoluted, multistep process to delete things.

And to add to my previous suggestion, quarantine visibility could be selectively switched just like the ignore list is.

50 minutes ago, robertey said:

There's no clear indication on the original plugin's Unraid forum thread that the creator is deprecating the plugin (https://forums.unraid.net/topic/51961-plugin-ca-cleanup-appdata/)

"Note: This plugin is deprecated."

How much clearer does the notice need to be?

@shiftylilbastrd Please update to the latest version of 2026.04.01.24.

I've implemented the default purge in days (by default, it's set to 0, which is disabled). Also added a custom purge for specific items, as well as other polishing and fixes.

2 hours ago, Sacred said:

"Note: This plugin is deprecated."

How much clearer does the notice need to be?

If you're referring to the top post, it says it was last edited Edited June 3, 2019 by Squid. The most recent comment by the author in that thread was from May of 2025.

2 hours ago, Sacred said:

"Note: This plugin is deprecated."

How much clearer does the notice need to be?

4 minutes ago, robertey said:

If you're referring to the top post, it says it was last edited Edited June 3, 2019 by Squid. The most recent comment by the author in that thread was from May of 2025.

If you're running Fix Common Problems you will 100% be getting a notification that the original is depreciated, it also directs you over to this one. If you don't have FCP I would suggest adding it.

If you don't want to believe that then just search CA for "Cleanup Appdata" and see what's available, the original is not.

Edited April 1Apr 1 by shiftylilbastrd
Additional comment

Is it possible to add support for non standard paths? Eg. when Docker containers are not using /mnt/user/appdata/. I have some Docker containers that mount on /mnt/fcache/appdata/ to remove some overhead from the /mnt/user mount. What happens now is that the plugin finds all live containers that use these mounts because in the config of the container it's referencing /mnt/fcache/appdata/ instead of /mnt/user/appdata/.

Maybe this can be solved by adding an option to add all your appdata paths? The appdata backup plugin does that by adding a source selector:

Thanks!

6 hours ago, VlarpNL said:

Is it possible to add support for non standard paths? Eg. when Docker containers are not using /mnt/user/appdata/. I have some Docker containers that mount on /mnt/fcache/appdata/ to remove some overhead from the /mnt/user mount. What happens now is that the plugin finds all live containers that use these mounts because in the config of the container it's referencing /mnt/fcache/appdata/ instead of /mnt/user/appdata/.

Maybe this can be solved by adding an option to add all your appdata paths? The appdata backup plugin does that by adding a source selector:

Thanks!

Yes, will definitely look into getting this implemented.

One more thing I have.

My AdGuard Home had created 2 folders under /mnt/user/appdata/adguard (config & workingdir).
These two folders were mounted in Docker and thus also found by the cleanup plugin.

So /mnt/user/appdata/adguard/config & /mnt/user/appdata/adguard/workingdir.

The resulting /mnt/user/appdata/adguard however was left behind empty and is no longer recognized.
So for the plugin everything looks fine. In reality though, I still have an empty folder left over as a remnant.

There would therefore need to be some kind of check whether the Docker mounts in relation to /mnt/user/appdata were located in subfolders.
So level 1 or level 2. And then a check would need to verify whether this folder is empty — if yes, safely deletable. If the folder has contents, then Risk.

----
Or alternatively, restructure it so that the plugin independently checks the folders in the default path as well. If there are empty folders there, it should simply offer to delete those too.
That way you wouldn't need to build any extra logic to extract level 1 from the /mnt/user/appdata/<level1>/<level2> mounts.

Edited April 2Apr 2 by Sacred

@Sacred Good find, I'll look into this as well.

Still getting symlink locked errors

am i missing something here? is the path configurable?
all of my containers use /mnt/cache_one/appdata/ vs /mnt/user/appdata/
this is reporting 120 containers as orphaned (Appdata share scan found this folder, and no saved Docker template or installed container currently references it)

i do see something similiar may have been mentioned above

When I first scanned it showed all of my apps then I came here and found it uses the default appdata location so, a +1 from me for configurable appdata location. I don't use the standard /mnt/user/appdata/ all of my apps are on /mnt/apps_cache/appdata/.

The app is looking pretty good though so thanks for working on it.

The old version was a much better no frills plugin....

Edited April 3Apr 3 by z0ki

11 hours ago, z0ki said:

The old version was a much better no frills plugin....

Then use it? It still works. In the mean time it's nice that someone else is picking up development of a newer version.

Edited April 4Apr 4 by VlarpNL

On 4/3/2026 at 6:27 PM, z0ki said:

The old version was a much better no frills plugin....

Agree, 100%. I reached here because Fix Common Problems showed me the deprecated warning today.

I see no reason to remove the old and install the new plugin. This plugin is trying to solve a problem that did not exist in the 1st place.

People need to realize that sometimes the software does what it needs to, and no feature updates are needed except security fixes.

I will keep the old version. TYVM

Thanks!

Appdata Cleanup Plus - 2026.04.07.10

Since 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 improvements

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

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

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

It works flawless in my setup now. I added my "non-standard" appdata path and it now just shows the paths that really should be removed.

@VlarpNL Awesome, glad Its working as expected now!

@XCrownedClownsX is there any chance you could add support for ZFS dataset deletes? Thanks so much!

29 minutes ago, Muddoggg said:

@XCrownedClownsX is there any chance you could add support for ZFS dataset deletes? Thanks so much!

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?