On 8/21/2026 at 12:33 AM, XCrownedClownsX said:

This was caused by a release metadata mistake that changed the plugin’s registered Community Applications URL. It has been fixed in 2026.08.20.19.

Please update or reinstall using:

plugin install https://raw.githubusercontent.com/alexphillips-dev/Appdata-Cleanup-Plus/main/plugins/appdata.cleanup.plus.plg

Confirm version 2026.08.20.19Refresh Community Applications and rerun Fix Common Problems. No cleanup, quarantine, purge, or delete functionality was affected.

Sorry for the inconvenience.

Switch from the DEV Version to the CA/MAIN Version.

Without the Force Option:

With the Force Option:

Edited October 4Oct 4 by Revan335

I am confused I have a section labeled Blocked and the message "Safety-blocked rows cannot be unlocked here." how do I un blocked this. My AI assitance in searching is not helping me figure this out

appdata-cleanup-plus-diagnostics-20261101-135130.json

1 hour ago, eyarea51 said:

I am confused I have a section labeled Blocked and the message "Safety-blocked rows cannot be unlocked here." how do I un blocked this. My AI assitance in searching is not helping me figure this out

appdata-cleanup-plus-diagnostics-20261101-135130.json

The wording is confusing—“cannot be unlocked here” means there isn’t an unlock button or setting for these safety blocks.

I checked your diagnostics. All four folders are blocked because an installed Docker container has the AppData root containing those folders mapped into it. The plugin therefore cannot treat those folders as safely unused, even if their original applications have been removed.

To identify the container:

1. Click Details on any blocked row.

2. Expand Specific container mounts. This shows the container name and host paths responsible.

3. Review that container’s path mappings. If it needs those mappings, leave them in place—the folders will remain protected. If a mapping is obsolete or unnecessarily includes the whole AppData root, correct it only after confirming what the container needs, apply the change, and rescan.

Simply stopping the container will not clear the protection, because stopped containers’ mappings are checked too. Changing Safe Mode will not bypass it either.

If you’re unsure why that container needs the mapping, share a screenshot of Specific container mounts, with any private names or paths obscured, and we can help review it before you change anything.

On 11/1/2026 at 3:07 PM, XCrownedClownsX said:

The wording is confusing—“cannot be unlocked here” means there isn’t an unlock button or setting for these safety blocks.

I checked your diagnostics. All four folders are blocked because an installed Docker container has the AppData root containing those folders mapped into it. The plugin therefore cannot treat those folders as safely unused, even if their original applications have been removed.

To identify the container:

1. Click Details on any blocked row.

2. Expand Specific container mounts. This shows the container name and host paths responsible.

3. Review that container’s path mappings. If it needs those mappings, leave them in place—the folders will remain protected. If a mapping is obsolete or unnecessarily includes the whole AppData root, correct it only after confirming what the container needs, apply the change, and rescan.

Simply stopping the container will not clear the protection, because stopped containers’ mappings are checked too. Changing Safe Mode will not bypass it either.

If you’re unsure why that container needs the mapping, share a screenshot of Specific container mounts, with any private names or paths obscured, and we can help review it before you change anything.

I have the same issue, so I guess this plugin will no longer work for me! The old one was fine! I guess anyone with the code server container who needs access to all the AppData folders can't use it! Shame that!

I haven't ever been successful at getting the Appdata Cleanup Plus plugin to work properly, although I would like to. I mainly use it today to tell me if I have any orphaned data and then I manually delete it after a period of time. I am getting the below error and have a feeling it is because I don't use the standard /mnt/user/appdata and have everything coded to use my NMVE drives directly.

Within the app it has the automatically detected /mnt/user/appdata and I manually entered /mnt/black-ops/appdata. When Appdata Cleanup Plus runs, it creates the directory structure right up to the last directory. Using the screenshot as my example, when I browse my files, I will have /mnt/user/appdata/.appdata-cleanup-plus-quarantine/date-time/mnt/black-ops/appdata/, but that's it. ddns-updater, or any other app that I've attempted to quarantine, will not be present.

Is this a config issue on my side, or just something within the app/Linux preventing the files from being moved across two different mount points?

@UncleStu Can you export your diagnostic file from the plugin's "Tools" and either attach it here or DM it to me so I can further review why it failed?

1 hour ago, XCrownedClownsX said:

@UncleStu Can you export your diagnostic file from the plugin's "Tools" and either attach it here or DM it to me so I can further review why it failed?

Sent you a DM