Repair permissions was unceremoniously removed from OS X in El Capitan. This staple of the Mac gurus toolkit disappeared. There was no 21 gun salute, there was no flaming casket sent out to sea and there was no sweet, sweet wake to get drunk at. Instead, there was pain. There was pain, because when the button disappeared, the need did not. Need proof? If you haven’t yet run it, let’s check your system to verify the permissions of the standard packages:
sudo /usr/libexec/repair_packages --verify --standard-pkgs --volume /
In the above command, we used the repair_packages binary, which has not changed in awhile. We then feed that the –verify option and the –standard-pkgs option, finally providing the volume of the current boot volume using –volume followed by the /. Pretty straight forward. Assuming there’s something to repair, the below will actually run that repair operation:
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
Where’s the sweet, sweet button? The rest of the screen is so darn lonely without it.
And now that you know the command, feel free to throw it in your self service. That way users can do it without opening terminal or using an admin password!
krypted November 22nd, 2015
I’ve long been a supporter of building tools in self service portals such as those provided by JAMF and Munki to provide users who don’t have administrative permissions to perform tasks that wouldn’t typically otherwise be destructive. One such example is a simple repair permissions. An administrator can simply open Disk Utility, select their disk and then click Repair Disk Permissions
But if you want to do this as a user who doesn’t have administrative privileges you would need to elevate your privileges before doing so. In a larger environment this would be incredibly annoying for dozens, hundreds, thousands or even tens of thousands of users to bring their computer to an administrator just to type in a password. But, if you have a patch management solution that has some kind of a self service portal, users could do this themselves. Typically, you would create a very small payload free package. This package might just contain a single script that might even be as short as a one-liner. For example, the following command would actually run a repairPermissions.
diskutil repairPermissions /
You could also send some environmental variables from your patch management tool for the boot volume, but in this simple instance we’re just going to run it, with the following type of output:
Started verify/repair permissions on disk0s2 Macintosh HD
Permissions differ on "Library/Application Support"; should be drwxr-xr-x ; they are drwxrwxr-x
Repaired "Library/Application Support"
Group differs on "Library/Printers/InstalledPrinters.plist"; should be 80; group is 0
Permissions differ on "Library/Printers/InstalledPrinters.plist"; should be -rw-rw-rw- ; they are -rw-r--r--
[ \ 0%..10%..20%..30%..40%..50%..60%..70%................ ] 74% 0:00:34
Finished verify/repair permissions on disk0s2 Macintosh HD
You could get much more complicated, writing the output to syslog or even a syslog server. You can also have metapackages that just do a bunch of tasks and call them things like “Try to fix my computer.” Provided you have a patch management tool, you could also just scope some devices and push some of these things out en masse; however, for the most part, I’m a fan of self service, so that’s the example I’m using this for.
krypted October 28th, 2013
Posted In: Mac OS X
Yesterday I looked at using diskutil to repair the permissions on a boot volume. You can also use diskutil to repair the permissions on a non-booted volume provided that there is a valid Mac OS X installation on that volume. To do so you would simply provide the path to that volume rather than to the blessed boot volume. For example, if the disk that we mentioned in the previous article were called Seldon and it was in a host booted to target disk mode then you would simply provide the path /Volumes/Seldon as before:
diskutil repairPermissions /Volumes/Seldon
In the event that you are scripting and want to take into account a dynamic target you can use a positional parameter or create the script on the fly. If you will then be using a package to choose a destination folder you can send a variable to the script and you would then use $1 in the place of /Volumes/Seldon, indicating a positional parameter. For example, a script might appear as follows:
diskutil repairPermissions $1
This is how Mike Bombich used to summon repair permissions in NetRestore (if memory serves then his script is practically identical to the one I list here but I’m on a flight can’t cross-reference ’cause I’m still too cheap to get a GoGo account). In watching his scripts mature, I picked up running a repairPermissions as a post-flight deployment task. Since doing so I’ve noticed a slight decrease in the amount of troublesome hosts deployed to the tune of maybe 1 out of 40 imaging projects per year. If the volume name is identical across all hosts then this can be as simple as listing the first command above. If the volume will be a boot volume then you can use the bless command, as indicated yesterday, to grab the volume name.
krypted March 1st, 2010
Disk Utility has a nifty little button to Verify Disk Permissions and another to Repair Disk Permissions. Many use this frequently over the course of basic Mac OS X troubleshooting.
The underlying functionality is also exposed at the command line. Diskutil (located in /usr/sbin) has the verifyPermissions and repairPermissions, which roughly correspond to the buttons in Disk Utility. Because these can be run against different disks, each will need the volume indicated following the verb. For example, to run a Verify Disk Permissions against a volume called Seldon, you would use the following command:
diskutil verifyPermissions /Volumes/Seldon
To then run a Repair Disk Permissions on that same volume, you would use:
diskutil repairPermissions /Volumes/Seldon
In most cases, repairPermissions is done to the currently booted volume. To find this volume, you can use the bless command along with the –getBoot option. For example:
Bless will then respond with the device that comprises your boot volume. To convert this into a path that can be used with diskutil, you would use the diskutil command followed by info followed by the output of the bless command. For example, if the device were /dev/disk0s2 then you would run the following:
diskutil info /dev/disk0s2
You could then script a repair permission of the boot volume using the following, which would also dump the output into a log file:
bless –getBoot > $tmp
diskutil info $tmp | grep “Media Name:” | cut -c 30-100 > $boot
/usr/sbin/diskutil repairPermissions $boot >> /var/log/318/fixperm.log
echo “Repair Permisssions completed at `date` >> /var/log/318/fixperm.log
Placing this script into a package would then allow for sending a Repair Disk Permissions command to client computers though, let’s say, ARD or even allow a user to run it themselves using the JAMF self-service client. All without having to leave ones chair or provide an administrative password to a user (having said this the script will require local administrative privileges).
krypted February 28th, 2010