guglgeo.blogg.se - What is disk utility console

#What is disk utility console how to#
#What is disk utility console password#

sudo fsck_apfs -n -S /dev/disk7 to check but not repair the container disk7, excluding all snapshots.

sudo fsck_apfs -n -S /dev/disk7s2 to check but not repair, but excluding all snapshots.

sudo fsck_apfs -y /dev/disk7s2 to check and repair all errors automatically, and include snapshots.

sudo fsck_apfs -n /dev/disk7s2 just to check the volume disk7s2 but not repair it, and include snapshots.

To unlock the volume without mounting it (thanks to kapitainsky for suggesting that).įor example, choose between the commands: If the volume is encrypted, you could keep it mounted and use the -l option to check the live file system, or you can use a command likeĭiskutil apfs unlockVolume /dev/disk7s2 -nomount

I advise you to include all snapshots, which are important, but if you want to exclude them all, use the -S option. For the former, use the -n option, and for the latter the -y option will perform all repairs automatically. The command to use depends on whether you just want to check the item, or repair it as well. In Disk Utility (or Terminal) mount the container or volume again, by selecting it and clicking on the Mount tool.Once that has completed, consider whether the container or volume needs any repair using fsck_apfs.Watch as the volume or container is checked.

#What is disk utility console password#

Then enter your admin user’s password at the prompt.

Open Terminal and type the chosen command with the correct device name.

When you’re checking a container, it’s best to unmount each of its volumes before unmounting the container itself.

In Disk Utility (or Terminal) unmount the container or volume, by selecting it and clicking on the Unmount tool.

In this case, I’ll use disk7s2, which is the sort of volume name you’re looking for, or disk7 for a container.

In Disk Utility (or Terminal) obtain the device name of the APFS container or volume you want to check.The bizarre twist is that you can use Disk Utility’s Unmount tool to unmount volumes and containers which the app itself appears unable to unmount successfully. The best news of all is that you can still use the command tool fsck_apfs directly, and work around this bug in Disk Utility. macOS does now provide a good means of ‘freezing’ file system access if you do try that when running in normal user mode, but Recovery is always better. If you’re intending to check and repair the boot volume group (System and/or Data) then this is the preferred way. One way around this is to cave in, start up in Recovery, and use Disk Utility there, where there’s no excuse for problems unmounting anything. Oddly, though, it doesn’t seem to affect HFS+ volumes. It can also happen every time with an APFS container. This may happen persistently when you try to check and repair an APFS volume.

#What is disk utility console how to#

When I was researching yesterday’s article about how to check Time Machine backup volumes, it hit me again and again, so I went back and had a closer look at what now goes wrong, and what to do about it. That some day clearly hasn’t come in Monterey 12.0.1. It would have been far better if Disk Utility had told us honestly that “this is a known bug, and some day we might get round to fixing it.” In Catalina and Big Sur, the error reported was confusing, and the recommendation to “back up the data on this volume” inappropriate. So to prepare for the call to fsck_apfs, Disk Utility has to unmount the volume or container, and that’s the step which appears to go awry. I suspect that privacy isn’t sinister, merely allowing communication between the tool and app using XPC.īest practice for performing disk checks and repairs like this isn’t with a live file system, and those options won’t work when the item being checked is still mounted. The y option simply agrees to make all the repairs suggested by the tool, but the x option is private. This article suggests ways around this, while we wait for Apple to fix this bug.įor much of this period, the First Aid tool in Disk Utility has relied on the command tool fsck_apfs to do the work, calling it using two options, y and x. To my shock, in Monterey 12.0.1 this problem appears worse than ever, and I now have one disk which Disk Utility is completely unable to check or repair. One of its most persistent and pervasive problems has been complete failure because Disk Utility has been unable to unmount volumes or containers. Checking and repairing disks is one of the more important tasks performed by Disk Utility, but ever since the introduction of APFS, it has been more fraught than it should have been.