From time to time, you will see mount exception prompts in the app. However, due to space, we cannot give a clear solution in the app, so we will explain how to solve these problems on this page. Such a prologue seems impeccable, but some people may refute it: why does Cleaner prompt the mount exception and let the user solve it instead of automatically handling it? I understand you're in a hurry, but I have to save this question for last.

To solve the mount exceptions, it is crucial for us to understand their cause. Thus when you see mount exceptions in the app list, I'm afraid you should not continuously refresh and expect the problem to be magically solved, or complain about Cleaner having poor quality everywhere. We recommend that you click to enter the mount rules editing page and check the running status section to determine the cause of the problem, and then refer to this page to troubleshoot it.

To understand the cause of the exceptions, it is crucial to explain the working process of Cleaner storage redirect. You may mistakenly think that Cleaner will receive all apps' file operation requests and find the paths after storage redirect. But if you have read Description of Mount page, you may understand that these are all provided by the VFS instead of the Cleaner app. The core part of Cleaner storage redirect is very simple - calling mount when apps start, and that's it.

Next, we explain each exception separately:

There are two possible causes for this issue:

• When the Zygisk module not installed, we detect process starts depending on the logcat, which may exit actively. If you are sure you don't want to install the Zygisk module, you will need to manually restart the Cleaner service every time it occurs.
• If you see this issue with all apps and have ruled out the previous cause, then Cleaner doesn't yet support your system. The Android system we promise to support is Q and above. If you encounter this problem and the system version meets the requirements, please create an issue to tell us.

There are two possible causes for this issue:

• When Cleaner mounting, it needs to execute a series of system calls, which may fail. It's a rare event you can ignore, and I am afraid you must ignore it, as a forcible resolution may deadlock the entire system.
• If you see this issue with all apps and manual remounting doesn't help, then Cleaner doesn't yet support your system. The Android system we promise to support is Q and above. If you encounter this problem and the system version meets the requirements, please create an issue to tell us.

This is a race condition issue that occurs when some of an app's processes are being created or destroyed. You can ignore this problem or check again in a few seconds.

When Cleaner mounts, it needs to ensure that the source file systems are directories, and create directories at the mount points. This problem occurs if this process fails, you need to check whether these places are occupied by files.

This indicates that the source directory was deleted. If these directories are empty when the app is closed, the Cleaner service will delete them automatically, so please do not delete these directories. In addition, Cleaner's cleanup feature will automatically exclude these directories.

There are many reasons for this problem.

• The most direct reason is that other programs called mount or [umount2](https://man7.org/ linux/man-pages/man2/umount.2.html).
• Filesystems can invalidate mount points. For example, when you delete the directory at the mount point, the mount disappears.
• For Android S and above users, this problem is very likely to appear if "Record file operations in app-specific storage" option is checked without activating Media Provider Manager.

The Cleaner itself implements the analysis of the mount information. In the old version, the inspection results were incorrect under specific circumstances. Although the new version has fixed this problem, it may still incorrectly show "mounted" when the mounting is abnormal. If necessary, you can check the /proc/ + pid + /mountinfo files yourself.

Now we can go back to the question posed at the beginning, there are the following reasons for not automatically handling:

• The vast majority of mount exceptions are caused by improper user operations, so it is the user's responsibility to solve them. The remaining small part is compatibility issues, which require us to update the adaptation. However, updating using any method other than the Google Play's update mechanism violates the Developer Program Policy so cannot be handled automatically.
• Automatic resolution of some problems requires more permissions, and the reason for these problems is that the user did not give enough permissions, which is essentially the same problem. In other words, the "automatic solution" you want for this part of the problem is to install the Zygisk module.
• It is very suspicious whether there are any remedial measures for some problems. And even if there are, it's impossible better than nipping in the bud.