Outdated tips and tricks

All the sections of this article are outdated and no longer work or have no purpose for the current Magisk release. They are only kept for posterity and for anyone who might possibly use an old release of Magisk. If you do, take a look at "Asking for help/reporting bugs" for things you can do to provide details and logs so that compatibility with your device can be achieved.

Magisk - Installation and troubleshooting

magisk_daemon -post-fs use a lot of CPU

Magisk v16+ checks if logging is enabled before starting the daemon
If you suddenly start experiencing high CPU usage and see that a process named magisk_daemon -post-fs is using a lot of your CPU, it's probably caused by having disabled Android logging with an app like Kernel Adiutor or by some other process. Enable logging again and the issue should disappear.

MagiskSU doesn’t remember superuser

This has been fixed as of Magisk v16.0 and Manager v5.6.1
Some devices have issues with the superuser database. You’ll probably see error lines in the log about sqlite3. It’s possible that this could be fixed by uninstalling and reinstalling the Manager. Do this from within the Manager by pressing “Uninstall” and then “Uninstall App”. If that doesn’t work, use the latest Magisk uninstall zip or do a comlete uninstall through the Manager (“Uninstall” -> “Complete Uninstall”). If it still doesn’t work, provide logs… (also see "Asking for help/reporting bugs").

MagiskSU doesn’t work

This has been fixed as of Magisk v16.0 and Manager v5.6.1
If superuser access doesn’t work, there are probably issues with the superuser db (also see “MagiskSU doesn’t remember superuser access” above). One of these issues might be a faulty implementation of f2fs. See “Issues with f2fs”.

Magisk but no MagiskSU

This no longer seems to be an issue on Magisk v15+.
There have been a few reports of devices/ROMs where Magisk gets installed properly, but MagiskSU fails to install. This might have to do with your device/ROM not letting Magisk symlink the required binaries and files to /sbin. See the release thread for known issues. If you know of a solution that's not listed, here or in the release thread, please let me know and I'll add it.

Can't reboot after installing modules

If you have updated Magisk from v13.3 and Magisk Manager v5.1.1 you might come across this issue. The solution is to clear data for the Magisk Manager (busybox integration has been updated and needs to be reloaded).

Long boot time

Magisk v15+ no longer produces the debug log in the same way as before.
If your device get stuck on the splash screen for a minute or so, it might mean that the magisk daemon have crashed or that there is some SELinux issue. If it is the case that the magisk daemon crashed, the Magisk debug logging during boot will never finish, even after the device has booted. This will eventually cause the debug log to eat up all your storage space! Take a look in /data and see if the file magisk_debug.log is very large and growing. Save the log and report the issue. Try rebooting to see if this fixes things, otherwise you'll probably need to uninstall Magisk and wait for a fix. Also see "Nothing works".

Randomly losing root

Busybox is no longer bundled with Magisk since v13.1.
Some devices and/or ROMs (known: Lineage OS) have issues with losing root when using MagiskSU. This can sometimes be fixed by disabling busybox in Magisk Manager settings. Some users have also reported success by disabling systemless hosts instead/as well.

MagiskHide - Hiding root and passing Safety Net

Universal SafetyNet fix module

The module is outdated and also replaces Magisk internal busybox with an incompatible one. Not recommended.
Or you can use the Universal SafetyNet Fix module. Spoofing the device fingerprint is part of what it does.

Check the logs

Magisk v15+ have introduced a much improved daemon that will restart automatically
Take a look in the Magisk log. In there you should see something like this (just an example, YMMV):
<log example removed>
If there are no entries in the log about MagiskHide starting, take a look under "Restarting the MagiskHide daemon" below and "Starting MagiskHide Manually".

Restarting the MagiskHide daemon

Sometimes the MagiskHide daemon needs to restart, or haven't properly started on a reboot. Fix this by toggling MagiskHide off and then on again in settings. You can also try disabling MagiskHide, rebooting and then enabling it again.
If you previously have had MagiskHide functioning on your device, but suddenly it stops working, it's a good chance the MagiskHide daemon hasn't properly started on boot. Toggle off and on (and possibly reboot) and you should be good. If not, keep reading under "Starting MagiskHide Manually".

MagiskHide isn't unmounting folders as it should

Unmounting of folders is no longer showed in the Magisk log, since Magisk v13.1.
If MagiskHide isn't unmounting as it chould for the processes/packages added to the Hide list (there are no "hide_daemon: Unmounted" entries in the log or there are entries showing that the unmount failed ("hide_daemon: Unmount Failed")), see "MagiskHide isn't unmounting folders as it should".
If you don't see any entries in the Magisk log for "hide_daemon: Unmounted", MagiskHide isn't functioning as it should and can't hide Magisk from apps and processes that trigger if root is found. There are a few reasons as to why this might happen. See "Kernel logcat support", "Logger buffer size", and "Mount namespace issues". Of course, these might not be the only reasons. If you're lucky, one of the solutions below will work for your particular case.
If there are entries in the Magisk log showing that the unmount failed ("hide_daemon: Unmount Failed"), take a look at what folder it's failing for and disable the corresponding Magisk module. If you can't work out what module is causing the issue, disable them all and enable one by one until you find the culprit. If it is one of your installed modules causing the issue, ask for advice in the module's support thread.
It might be that you have to rely on manually starting MagiskHide to make it unmount folders properly (known: some Xiaomi devices/MIUI). See "Starting MagiskHide manually".

Magisk v12 can't hide root (but v11.6 could)

The changed prop values have been reintroduced with Magisk v13.1.
If you have an app that you can hide root from with Magisk v11.5/v11.6 but not after upgrading to v12, you need to take a look at the "Sensitive props" section. In Magisk v11.5 and v11.6, Magisk Hide would alter a few build.prop values, specifically a couple of the usual suspects mentioned in "Sensitive props". These are ro.build.tags and ro.build.type. This was reverted with Magisk v12 since it has the potential to cause issues and is better left to the users discretion.
So, if you can fool an app with Magisk v11.5/v11.6, but not with v12. Try changing ro.build.tags and/or ro.build.type to "safe" values.

Scripts are no longer used in Magisk v13.1.
If you have a device where you find you have to start Magisk Hide manually to pass SafetyNet, try editing the enable script (found in /magisk/.core/magiskhide) and change the last line to:

This might make Magisk Hide work properly on your device.

Busybox conflict

Busybox is no longer bundled with Magisk since v13.1.
If you already have busybox installed or your ROM comes with it built-in, enabling Magisk busybox may cause a conflict that breaks Magisk Hide. Either use and update the existing installation or remove it if you want to use Magisk busybox.

Magisk v13.1+ does not have these issues.
Since beginning of June 2017, SafetyNet has been updated. Magisk v12 and lower versions can't pass. The solution is to enable Core Only Mode in Magisk Manager settings and you might also have to disable systemless hosts. In Magisk v13.0 beta, this has been fixed (but of course, there might be other issues present). Note that this guide is written for Magisk v12 and the tips in it may not be applicable for Magisk v13 beta. I'll update the guide for v13 when it is released from beta.
For users of Magisk v12 Deic have made a Magisk module that might make SafetyNet pass with modules active. Note that this module will also change your device's fingerprint to match a Xiaomi Mi 6 (for devices/ROMs that have no CTS certification), also see "Spoofing ro.build.fingerprint". yochananmarqos have made a version of the module that leaves out the fingerprint part, for users that could pass SafetyNet before the update. See the links for details.

Module link removed from the guide since it does so much more than just editing the fingerprint.
Deic have updated his Xiaomi SafetyNet fix module to be a Universal SafetyNet Fix module that does just this. It'll change your devices fingerprint to match an official one for Xiaomi Mi 6. It'll also make Magisk v12 pass SafetyNet with modules installed.
IMO it'd be best if you could use a fingerprint that more closely matches your device (you'll find it in the build.prop file). If you're on a custom ROM that doesn't pass SafetyNet and the stock ROM does, use the stock ROM's prop values, etc. To change the fingerprint set by the module, unzip it and open up the post-fs-data.sh file in a text editor that can handle Unix line endings (on Windows this means Sublime, Atom, Notepad++ etc). Change the following two lines to match your device's stock ROM:
$RESETPROP "ro.build.fingerprint" "Xiaomi/sagit/sagit:7.1.1/NMF26X/V8.2.17.0.NCACNEC:user/release-keys"
$RESETPROP "ro.bootimage.build.fingerprint" "Xiaomi/sagit/sagit:7.1.1/NMF26X/V8.2.17.0.NCACNEC:user/release-keys"

An app still detects the original prop value

No longer applicable.
If Magisk Hide doesn't start properly at boot, it can be started by toggling Hide off and on again in settings. But, when doing this, some of the prop values changed by Magisk Hide may not get set properly. Try rebooting your device and see if Hide starts up properly. If it doesn't it might be one of your modules causing issues.
If it's a prop value you're changing yourself with a Magisk module and you're using system.prop to set the value, try moving the script to post-fs-data.sh and use resetprop instead. See here for more resetprop syntax. Example:
system.prop code:
post-fs-data.sh code:
resetprop ro.build.tags release-keys

Samsung KNOX

Removed from the guide since the feature doesn't seem to work anyway.
If you're having issues with Samsung KNOX, use a KNOX checker app from the Play store to see if it reports as triggered or not. Samsung pay and other Samsung apps/services that check KNOX have been reported to still see the KNOX counter as triggered, even though it gets masked by Magisk Hide.

Since Magisk v11.5 resetprop is added to PATH and can be called directly through shell and apps.
/data/magisk/resetprop ro.build.tags release-keys

This part is no longer necessary since Magisk v11.5. It's changed by Magisk by default. Only do this if you're using an earlier release.
Some Samsung users with custom ROMs have reported that they have had to do some modifications to the permissions for a couple of files related to SELinux to pass SafetyNet. These files are "/sys/fs/selinux/enforce" and "/sys/fs/selinux/policy". The "enforce" file should have permission 640 (rw-r-----) and the "policy" file should have permission 440 (r--r-----). This can be easily automated with Magisk's General Purpose Boot Scripts (see here for details) or a Magisk module. The lines needed for the script are:
chmod 640 /sys/fs/selinux/enforce
chmod 440 /sys/fs/selinux/policy

Permissive SELinux

Magisk Hide uses a pseudo-enforcing SELinux state to mask a permissive kernel
You can check if it’s SELinux causing problems by typing (without quotation marks) “getenforce” in a terminal emulator. If it reports permissive you can try temporarily setting it to enforcing by typing “setenforce 1” (this requires root access) and see if this makes SafetyNet pass. To make SELinux permissive again, use “setenforce 0” or reboot your device (if it’s permissive by default). If you want a more permanent solution it can be done with Magisks General Purpose Boot Scripts. See here for details. The lines needed for the script to set SELinux to enforcing are:
setenforce 1
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki