Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Run Repair Permissions via an AppleScript System
I'm not sure if this is new. Anyway, I was browsing this forum, looking for a way to enable journal. Then thanks to this thread, I found out there is a way to repair permissions from terminal. The command is:
sudo diskutil repairPermissions /
By combining this with AppleScript, you can easily repair permissions from Script menu or Youpi Key or Quickeys without having to open Disk Utility (which, by the way, isn't scriptable.) To open a new window and run the command, use this AppleScript (you'll need to enter your admin password afterwards):
tell application "Terminal"
do script "sudo diskutil repairPermissions /"
end tell
To run it silently in the background, use this AppleScript:
do shell script "sudo diskutil repairPermissions /" 
password "yourAdminPassword" with administrator privileges
Replace "yourAdminPassword" with your admin password. The drawback using this silent command is you wouldn't be able to see the log. I'm wondering if it's possible to get the log from terminal, trigger TextEdit to make a new document with the log and then save it somewhere. Any suggestion?

[Editor's note: If you're going to create an AppleScript with your admin password in it, make sure you put it somewhere safe from potential prying eyes...]
  • Currently 3.20 / 5
  You rated: 4 / 5 (5 votes cast)

Run Repair Permissions via an AppleScript | 12 comments | Create New Account
Click here to return to the 'Run Repair Permissions via an AppleScript' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
To prevent timeout errors
Authored by: bostmass on Jan 20, '03 12:47:41PM

Because AppleScripts can time out after a certain period of what it considers inactivity, a better approach would be:

with timeout of 1000000 seconds
do shell script
"sudo diskutil repairPermissions /" password "adminPassword" with administrator privileges
on error errormsg
display dialog errormsg --in case anything goes wrong
end try
end timeout

activate me
display dialog "Finished!" --so you'll know the script is through running

[ Reply to This | # ]
Terminal Applescript question
Authored by: photoboy on Feb 14, '03 11:09:59AM

Question, couldn't you have Applescript ask for a password then enter that string into the text? Then it could have the "sudo -K" command mentioned in another string so this not expose your password and would also not leave sudo open.

[ Reply to This | # ]
To prevent timeout errors
Authored by: jstaudte on May 11, '03 09:06:07PM

I'm not sure what I'm doing wrong here, but I am new to but Terminal and Applescript.

If I cut and paste the code listed into Script Editor (with my own password) I get and error: Expected "given", "in", "of", expression, "with", "without", other parameter name, etc. but found unknown token. And the token highlighted is the first backslash (\)

So I tried doing in in Terminal to see if my Script was the problem, but I always get prompted for my password, even thout I've included in the sudo command.

Thanks if you can help.

[ Reply to This | # ]
Instead of Apple Script use a Cron tab
Authored by: gavinque on Jan 20, '03 01:28:20PM

Yes that is a great hint but instead of using Apple Script use a Cron tab.

Download two utilities; CronniX and Pseudo (if you don't already have them) from version tracker.
put both applications in your /Applications folder, then drag and drop CronniX on to Pseudo this will launch Pseudo ( it will ask for your password) as the root user then setup the crom tab to execute "diskutil repairPermissions /" ( remember no quotes ).

The hardest part will be to set the time or date to run the command. Perhaps someone out there could help with that. For me it's been about a year since I've set one up.

I know that this can work as I've done it with other commands.

You will need to read the man pages on "cron" from the terminal or fav. man page reader.

The best part is that usernames and passwords are not stored anywhere as with an Apple Script.

I hope this gets someone going with this tip.

[ Reply to This | # ]
Instead of Apple Script use a Cron tab
Authored by: gavinque on Jan 20, '03 02:19:53PM


instead of using two applications as I discribed Psuedo and CronniX you can now downlaod CronniX 2.0.2 just released today ( on ) and be able to set a crontab to execute diskutil repairPermissions /

and have a easy schedule setup. This is the best news as you don't have to read any man pages or deal with exposed username and passwords. give it a try.

[ Reply to This | # ]
sudo and you
Authored by: Mikey-San on Jan 20, '03 05:10:25PM

If you're going to let this script run in the background, take note:

1. "with administrator privileges" invokes sudo, which is (by default) left open for 5 minutes when used
2. Just because you'll be presented with an AppleScript dialog doesn't mean it automatically closes sudo access--AppleScript will /always/ ask for it, as it doesn't pay attention to the sudo time stamp.

You may want to add:

do shell script "sudo -K"

... To that script before the end tell.

[ Reply to This | # ]
then again ...
Authored by: Mikey-San on Jan 20, '03 05:12:37PM

You should never put your admin password in an AppleScript, anyway. ;-)



[ Reply to This | # ]
Authored by: mahakali on Jan 21, '03 04:44:32PM
Interesting. (about sudo -K) I'm new to unix, by the way. And learn new things each day :) I revised the script to display a dialog to enter the admin password instead. And added a dialog at the end. Still the dialog doesn't contain complete log. So, here it is:
display dialog "enter your admin password:" default answer ""
set admin_password to (text returned of result)
do shell script "sudo -K diskutil repairPermissions /" 
password admin_password with administrator privileges
set rp_log to (do shell script "sudo -K diskutil repairPermissions /")
display dialog rp_log
Is this how we use the sudo -K, by the way, Mike?

[ Reply to This | # ]
Authored by: Mikey-San on Jan 22, '03 09:16:24AM


sudo -K

As a separate command to reset the sudo time stamp. E.g.,

do shell script "rm -rf ~/Applications/Internet\" with administrator privileges
do shell script "sudo -K"


[ Reply to This | # ]
Repairs and Receipts
Authored by: bluehz on Jan 21, '03 08:01:17AM

If I am not mistaken - doesn't RepairPermissions rely on Receipts in the /Library(s)/Receipts dir?

The reason I as is that I have a seperate HD assigned as my /Applications partition. All works well, but occasionally when doing an install - the installer will get confused about whats going on and create a new empty /Applications/Library dir and then deposit its appropriate reciept inside. No biggie really and I have been trying to remember to move the odd Receipt into the proper /Library/Receipt dir - but on occasion I have just deleted the Receipt. Consequently my Receipts dir may not be as up to date as my actual installations are. Is this a problem, and if so is there a way I can reinstall just the missing receipts?

[ Reply to This | # ]
Repairs and Receipts
Authored by: mahakali on Jan 21, '03 04:48:49PM

Yes, it uses the receipts. Software update also uses these receipts to update softwares. I'm not sure about 3rd party apps, but you better keep apple applications & system receipts.

[ Reply to This | # ]
Run Repair Permissions Automatically On A Schedule In the Background Late at Night, Elegantly
Authored by: Lectrick on Jun 05, '03 07:39:43PM

A more elegant way to do this is to create a daily.local script in /etc/ with the single line of "diskutil repairPermissions /"

cd /etc/
sudo pico daily.local

diskutil repairPermissions /

control-O to save out, hit enter
control-X to exit

sudo chmod +x daily.local

You're done!

This file is then called by the "daily" script which is already run by the default OS X installation, every night at 3:30AM (which you can see if you use Cronnix- if you pick the menu command "Open System Crontab" you will see "periodic daily/periodic weekly/periodic monthly" which are just ways to execute maintenance scripts.)

The other nice thing is that a new OS X install (as long as you install over your existing install) likely won't obliterate this file. (if you want, you can probably make a non-root-user copy of this file in your home directory somewhere as a backup)

[ Reply to This | # ]