First Aid process fails on partition

Question

Level 2

192 points

First Aid process fails on partition

Hello

CONFIGURATION:

iMac 27 mid 2011. Two brand new internal HDs, one 120GB SSD and a second internal 2TB Rotational Drive.

Two user accounts, one admin on internal SSD. Main account, alex, mapped via User and Groups System preferences advanced options to /Volumes/Macintosh/alex (a rotational drive - a Toshiba drive).

El Capitan 10.11.1.

Disk Utility Version 15.0 (1150)

No migration took place, this is a clean install and both HDs are new.

ISSUE:

When running First Aid on the Toshiba Drive, there are no errors to report.

When running First Aid on the Macintosh partition First Aid fails, I've included the log for the failure. While booted in Recovery Mode, no issues are present when performing Disk First Aid on the Macintosh volume.

11/3/15 12:02:21.560 PM fseventsd[54]: Events arrived for /Volumes/Macintosh after an unmount request! Re-initializing.

11/3/15 12:02:21.560 PM fseventsd[54]: creating a dls for /Volumes/Macintosh but it already has one...

11/3/15 12:02:21.893 PM diskmanagementd[1439]: Unmount of disk1s2 blocked by dissenter PID=297 (/System/Library/PrivateFrameworks/TCC.framework/Versions/A/Resources/tccd) status=0x0000c010 (Resource busy)

PID 297 shows up as tccd

When I run diskutil from the terminal on the volume Macintosh (the affected volume) I get

$ sudo fsck_hfs -l /dev/disk1s2

** /dev/rdisk1s2 (NO WRITE)

Executing fsck_hfs (version hfs-304).

** Performing live verification.

** Checking Journaled HFS Plus volume.

The volume name is Macintosh

** Checking extents overflow file.

** Checking catalog file.

** Checking multi-linked files.

** Checking catalog hierarchy.

** Checking extended attributes file.

** Checking volume bitmap.

** Checking volume information.

** The volume Macintosh appears to be OK.

Here is the Finder info window on the internal "Macintosh" volume

RELEVANT NOTE:

My mac in the last 2 or 3 days has been waking but apps appear to freeze, force quit does nothing, and the control eject button, although it brings up the shutdown option I won't. I tried halt from the terminal to no avail. I am actually forced to power down using the button. This is a symptom as of 2-3 days ago. Any further ideas on isolation?

Can anyone explain if this is a false negative?

Kindest regards

Alex

iMac, OS X El Capitan (10.11.1), iMac mid 2011, 3.4Ghz i7 32GB RAM

Posted on Nov 3, 2015 3:15 AM

Reply

Answer 1

LostAccount Author

Level 2

192 points

Nov 3, 2015 3:59 AM in response to LostAccount

One additional pice of information:

When I login to m admin account , which resides on the SSD, I can successfully run First Aid from Disk Utility. It seems the error appears one when running Disk Utility from the alex account which resides on the /Volume/Macintosh

I don't really seeing this difficult before but might this issue have something to do with parking my main user account to the /Macintosh volume?

Reply

Answer 2

R C-R

Level 6

17,794 points

Nov 3, 2015 4:30 AM in response to LostAccount

LostAccount wrote:

... might this issue have something to do with parking my main user account to the /Macintosh volume?

I am almost certain that it does. I'm just guessing but I suspect the current version of Disk Utility is not coded to recognize that it should do a 'live verify' on the volume where the user account that is running DU is located. It would have to do that because it can't unmount the volume with the current user account on it.

Since no problems are found when running DU from recovery mode, I would guess that you can ignore the failure warning, but you do apparently have some problems (mentioned in your note) that suggest there may be other issues you need to consider when running El Capitan with a user account mapped to something other than the startup drive.

Reply

Answer 3

LostAccount Author

Level 2

192 points

Nov 3, 2015 6:02 AM in response to R C-R

I am almost certain that it does. I'm just guessing but I suspect the current version of Disk Utility is not coded to recognize that it should do a 'live verify' on the volume where the user account that is running DU is located. It would have to do that because it can't unmount the volume with the current user account on it.

Firstly, thank you for our evaluation and for making your suspicions known.

From a technical perspective, I wonder why I can login to the admin account (residing on the SSD; the boot volume) and not confront the same issue when running Disk First Aid. Additionally, you can see that the diskutil command works as expected while logged in to the expected account. I should also research what the process tccd is all about.

My Apple Care ran out a few months ago but perhaps El Cap has 90 days phone support, in which case I will contact AppleCare and potentially get an engineering escalation to understand if this is a known issue and if the error is erroneous.

Thanks again for you point of view.

Reply

Answer 4

LostAccount Author

Level 2

192 points

Nov 3, 2015 6:03 AM in response to R C-R

Ah but yes, I do agree that this might have to do with my main user account residing on a volume separate to the boot volume. I wanted to let you know that.

Reply

Answer 5

R C-R

Level 6

17,794 points

Nov 3, 2015 9:07 AM in response to LostAccount

LostAccount wrote:

From a technical perspective, I wonder why I can login to the admin account (residing on the SSD; the boot volume) and not confront the same issue when running Disk First Aid.

I think that is because First Aid "knows" it can't unmount the boot volume so it does a 'live verify' -- the same thing that the old version of Disk Utility's "Verify Disk" command does when you select the boot volume. In that version you can see that "Repair Disk" is greyed out for the boot volume; in the new one there is no obvious distinction between a disk verify & repair, other than like in the old version the Mac becomes sluggish or unresponsive when it is doing a live verify of the boot disk.

Additionally, you can see that the diskutil command works as expected while logged in to the expected account.

I'm not sure what diskutil command you ran -- all I see in your first post about that is the output of a sudo fsck command, which clearly shows a live verification was performed.

Reply

Answer 6

LostAccount Author

Level 2

192 points

Nov 3, 2015 9:22 AM in response to R C-R

Ah but yes, I do agree that this might have to do with my main user account residing on a volume separate to the boot volume.

I re-read your answer, I think I got a eureka moment, yes it does make sense that Disk Utility may not know that the second drive, where my user account is, can't be unmounted and therefore the error is displayed – as per the screenshot in the original message.

I apologize, the command I ran was not diskutil, that was an oversight, it was actually a file system check. It was sudo fsck_hfs -l /dev/disk1s2

-I should confirm, the fsck is the same command run by Disk Utility correct? I should read the man page to be sure but perhaps you know.

Ok, well I went through the man page for diskutil and executed the following while logged in to the user living on the rotational drive. As a reminder, while logged into this user DiskUtility.app will complain that it can't unmount the volume.

$ diskutil verifyVolume /dev/disk0s2

Started file system verification on disk0s2 Macintosh

Verifying file system

Using live mode

Performing live verification

Checking Journaled HFS Plus volume

Checking extents overflow file

Checking multi-linked files

Checking catalog hierarchy

Checking extended attributes file

Checking volume information

File system check exit code is 0

Finished file system verification on disk0s2 Macintosh

I also ran:

$ diskutil verifyVolume /dev/disk0s2

Started file system verification on disk0s2 Macintosh

Verifying file system

Using live mode

Performing live verification

Checking Journaled HFS Plus volume

Checking extents overflow file

Checking multi-linked files

Checking catalog hierarchy

Checking extended attributes file

Checking volume information

File system check exit code is 0

Finished file system verification on disk0s2 Macintosh

iMac27:_MASReceipt alex$ diskutil verifyDisk /dev/disk0

Started partition map verification on disk0

Checking prerequisites

Checking the partition list

Checking the partition map size

Checking for an EFI system partition

Checking the EFI system partition's size

Checking the EFI system partition's file system

Checking the EFI system partition's folder content

Checking all HFS data partition loader spaces

Checking booter partitions

Checking Core Storage Physical Volume partitions

The partition map appears to be OK

Finished partition map verification on disk0

For your reference. Marked in Bold is the partition where my main user account resides, an internal rotational drive.

$ diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *2.0 TB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_HFS Macintosh 2.0 TB disk0s2

/dev/disk1 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *120.0 GB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_HFS Boot_Volume 119.2 GB disk1s2

3: Apple_Boot Recovery HD 650.0 MB disk1s3

Reply

Answer 7

LostAccount Author

Level 2

192 points

Nov 3, 2015 12:24 PM in response to LostAccount

I don't know how my answer I above got mangled.

Here are the diskutil commands I ran.

$ diskutil verifyVolume /dev/disk0s2

Started file system verification on disk0s2 Macintosh

Verifying file system

Using live mode

Performing live verification

Checking Journaled HFS Plus volume

Checking extents overflow file

Checking multi-linked files

Checking catalog hierarchy

Checking extended attributes file

File system check exit code is 0

Finished file system verification on disk0s2 Macintosh

$ diskutil verifyDisk /dev/disk0

Started partition map verification on disk0

Checking prerequisites

Checking the partition list

Checking the partition map size

Checking for an EFI system partition

Checking the EFI system partition's size

Checking the EFI system partition's file system

Checking the EFI system partition's folder content

Checking all HFS data partition loader spaces

Checking booter partitions

Checking Core Storage Physical Volume partitions

The partition map appears to be OK

Finished partition map verification on disk0

Reply