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

Use cron to repair permissions on a regular basis UNIX
I don't know why I didn't realize this before, but for those that want to make sure they keep up with repairing permissions, this was made much easier with Panther (10.3). Panther includes a command line version of Disk Utility, called diskutil. If you want to repair your permissions once a week, simply open the Terminal, and do the following:
sudo pico /etc/weekly.local
This uses the pico text editor to create a weekly.local file (feel free to substitute your favorite *nix text editor). This file is looked for by the /etc/weekly script, and run as part of that task if it exists. Then in the file, put something like the following:
# Begin Repair Permissions Script
PATH=/bin:/sbin:/usr/sbin:/usr/bin:/usr/libexec
export PATH
host=`hostname -s`
echo "Repairing Permissions on System Drive"
diskutil repairPermissions disk0s3
# End Repair Permissions Script
If you have changed your partitions and/or disk setup since you first received your machine, type the following in the Terminal to find out what your boot partition is called: diskutil list.

Finally, make the script executable, I suggest the following:
sudo chmod 555 weekly.local
These instructions, plus a better way to do it for OS X Server are available on my blog. If you are someone who turns your machine off at night, this hint, combined with Mac Janitor can take care of both normal cron maintenance and repairing permissions all at once.
    •    
  • Currently 1.60 / 5
  You rated: 1 / 5 (5 votes cast)
 
[22,652 views]  

Use cron to repair permissions on a regular basis | 38 comments | Create New Account
Click here to return to the 'Use cron to repair permissions on a regular basis' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A simpler way?
Authored by: bcamp1973 on Nov 19, '04 11:42:03AM
Isn't it easier to edit the /etc/weekly script directly? I just added the following lines to mine and it works fine...
echo ""
echo "Repair Permissions"
echo ""
diskutil repairPermissions /
echo ""
echo "Update Prebinding"
update_prebinding -root /
I also have it update prebinding. The extra echo "" lines are just to space things out if you execute the script manually and view the output.

[ Reply to This | # ]
A simpler way?
Authored by: lpp on Nov 19, '04 12:19:19PM

If you edit /etc/weekly directly it is possible it will be overwritten in the future by an OS update. /etc/weekly.local is intended to include customized operations to be performed and should be safe from future OS updates.



[ Reply to This | # ]
A simpler way?
Authored by: ataraxia on Nov 19, '04 12:29:44PM
Yes, that's much easier, but you lose it if Apple updates that file. /etc/weekly.local is reserved for your use and guaranteed safe to edit.

[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: daybrother on Nov 19, '04 11:42:44AM
Nice tip. As far as MacJanitor goes, I like onyx myself. Easy GUI lots of extra features and free.

[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: treck on Nov 19, '04 12:17:51PM

A simpler method is to use Cronnix, the GUI interface to Cron. Create a new Cron entry with the following command:

diskutil repairPermissions / >> /Users/UserName/PermissionsLog.txt

The second half dumps the result of the repairPermissions command into a text file, in this case, PermissionsLog.txt. You can of course change the path where the file is to be saved.

If you leave this text file in place, cron will append to it on each run, giving you a history.

If you delete the text file, either manually or through an rm cron job, (rm /Users/UserName/PermissionsLog.txt) it will create a new file when run.

I even created this as a system cron job, which atuomatically gives it a higher priority, and it fires off everyday at 7 AM.

---
treck



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: Mac112 on Nov 19, '04 12:19:46PM
If You, as I, wonder why Your Mac suddently slows down and disk activity goes up when the script is run, use the say command to tell what's going on: In the beginning of the weekly script, add say "now running weekly maintainance" and at the end say "weekly maintainance has finished. have a nice day" You can even specify the voice with the -v opton: say -v Fred "hello"

[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: TvE on Nov 20, '04 08:52:10AM

And you can also have a lot of fun if you SSH into a remote Mac and fire off a bunch of say commands like "hey! take you ugly fingers of my keyboard... yes it IS you I am talking to..."

;-)



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: landis on Nov 19, '04 12:25:13PM
Since I have no clue really what I'm doing while playing with the Terminal, here's to hoping that this hint is good and won't break anything! Thanks, I've been looking for a way to do this without regularly running Cocktail or MacJanitor.

One quick correction to the above hint (I think) is that the last command should be
sudo chmod 555 /etc/weekly.local and not
sudo chmod 555 weekly.local

[ Reply to This | # ]

Use cron to repair permissions on a regular basis
Authored by: Shawn Parr on Nov 19, '04 12:31:32PM
You are correct. When I stated
sudo chmod 555
I assumed you would be in the /etc directory.

Since I had previously stated

sudo pico /etc/weekly.local
that assumption is most likely false.

[ Reply to This | # ]
For Server . . .
Authored by: Shawn Parr on Nov 19, '04 12:37:36PM
If you use OS X server you can actually do this in a different way, that is slightly better.
/etc/periodic
Allows you to put in multiple scripts starting with a number to prioritize them.

As an example on my server systems I put this same script in the following location:

/etc/periodic/weekly/900.weekly.repairpermissions
So that it runs weekly, and is the last script run.

The periodic folder appears in OS X Client, but when I tried using it the scripts there never ran.

[ Reply to This | # ]

For Server . . .
Authored by: gneagle on Nov 19, '04 12:48:11PM

Periodic works fine on OS X client as well - there must have been another problem.
Make sure the script has the executable bit set, or periodic will silently skip it.



[ Reply to This | # ]
For Client . . .
Authored by: subscriber3 on Nov 19, '04 01:31:33PM

in OS X client the default system crontab does not use the weekly folder; it uses an alias named weekly which points to the default weekly job contained in the folder. to use the weekly folder you have to edit the crontab.



[ Reply to This | # ]
For Client . . .
Authored by: adrianm on Nov 20, '04 02:42:31AM
You sure you have to edit the crontab? my 'system' crontab for root is empty but /etc/crontab contains

15      3       *       *       *       root    periodic daily
30      4       *       *       6       root    periodic weekly
30      5       1       *       *       root    periodic monthly
The /etc/weekly symlink does indeed point to periodic/weekly/500.weekly, but it doesn't seem to have any effect on the periodic program.

Just put a script in the appropriate directory, make it executable and check your script return code (it is important). As always RTFM; in this case, man periodoc.

[ Reply to This | # ]

Use cron to repair permissions on a regular basis
Authored by: tji on Nov 19, '04 01:37:40PM

I've seen quite a few tips on this site about repairing permissions. It seems like many people do this compulsively.

Why the need to do this so frequently? Are you guys concerned about security, and want to make sure the file permissions are locked down, or what?



[ Reply to This | # ]
repair permissions on a regular basis
Authored by: subscriber3 on Nov 19, '04 01:56:57PM

incorrect permissions can interfere with software installation, causing system and application problems.



[ Reply to This | # ]
repair permissions on a regular basis
Authored by: tji on Nov 20, '04 09:50:20PM

Yes, incorrect permissions can screw up many things. But, is there some reason to believe that the permissions are going to be constantly reset to incorrect values?

Why would one want/need to constantly do this?

In my 12+ years with Unix, and 2 years with MacOS X, I have not found this to be a major problem.



[ Reply to This | # ]
repair permissions on a regular basis
Authored by: werikblack on Nov 21, '04 01:17:06PM

The problem, though, is that if a developer has an installer or application that goofs up permissions, you're much more likely to see this on Mac OS X than you would on UNIX, IMHO. Consider the source of many of the applications you buy. With UNIX, you're typically buying from enterprise developers. On Mac OS X, there's a good chance you're buying apps from a 22-year-old developer sitting in his underwear coding for extra beer money. Definitely a difference in terms of bug checking.



[ Reply to This | # ]
Re: repair permissions on a regular basis
Authored by: Uncle Asad on Nov 22, '04 03:02:53PM

The Apple Installer / PackageMaker tools make it perhaps easier than it should be to create a package which will install and mess up permissions. It *looks* easy enough to create an installer package--hey, just fill in these fields!--but there are a lot of gotchas that aren't apparent through that esay interface. There are a number of good tutorials on the web outlining these gotchas, and Apple's documentation looks very thorough--but it seems so easy that many may not read the docs or search for the tutorials.

I've also had Backup once fubar the permissions on /tmp 2/3 of the way through a 7 CD backup and die, so applications (or perhaps OS bugs) can sometimes mess things up, too, but predominantly it seems to be poorly-created installer packages.

Bottom line, if you install software from vendors other than Apple, you should be running repair permissions--and running permissions before and after OS updates seems to help them work properly, too!



[ Reply to This | # ]
Use the run-parts script
Authored by: Schamschula on Nov 19, '04 02:44:50PM
In order to prevent Apple from overwriting things, and to add additional functionality, I use a script borrowed from Debian Linux: run-parts. This script is fired off using entries in crontab, but executes any scripts placed in a folder, e.g. /etc/cron.daily and so forth. I have been using this method to run my repair permissions script once a week for about a year and a half. See my HowTo at www.hmug.org for details.

[ Reply to This | # ]
Use the run-parts script
Authored by: adrianm on Nov 20, '04 02:56:22AM
No need. Just put your own scripts in /etc/periodic/weekly|daily|monthly.

If you don't want to use that directory, provide a /etc/periodic.conf with overriden local_periodic setting...

(Or provide a local /etc/periodic.conf.local with overriden local_periodic setting...)

Or put scripts in your own weekly|daily|monthly directories in /usr/local/etc/periodic/ (create this directory - it doesn't exist by default)...

Or many other standard ways.

As always, don't make things hard for yourself. man periodic and man periodic.conf. RTFM.

[ Reply to This | # ]

Use cron to repair permissions on a regular basis
Authored by: Numbski on Nov 19, '04 03:05:09PM

Bear in mind that if you have Sendmail installed, every time you run this you'll kill sendmail (why oh why won't apple use sane permissions???)

Add to your scripts the following:

chmod go-w / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue
chown root / /etc /etc/mail /usr /var /var/spool /var/spool/mqueue

That or you'll have to edit your custom sendmail.cf to "Not Blame Sendmail". I just choose to manage the permissions in hopes that one day Apple will get their collective heads on straight.



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: murali1080 on Nov 19, '04 05:07:42PM

Panther has replaced Sendmail with Postfix and hence this should not be a problem unless you run Jaguar or older OS X.



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: Numbski on Nov 19, '04 08:53:35PM

I intentionally killed off Postfix and re-installed sendmail so I could run spamassassin milter, and a custom spamassassin quarantine application.

So yes, it is an issue if you have sendmail installed. :P



[ Reply to This | # ]
sendmail permissions
Authored by: sjk on Nov 19, '04 06:07:20PM

That's only an issue on pre-Panther since Postfix replaces sendmail on Panther.



[ Reply to This | # ]
Sorry, no, it won't work.
Authored by: Chas on Nov 19, '04 11:28:32PM

I regret to inform you that this procedure will not work correctly. You cannot repair permissions on the boot drive. You cannot run diskutil or Disk Utilities.app on the drive you are repairing. It will appear to work but it does not.
The correct procedure is to boot from some other volume (like the Install CD) and run the app from there, applying the repairs to the target (nonbooted) volume.



[ Reply to This | # ]
Sorry, no, it won't work.
Authored by: mastige on Nov 19, '04 11:55:51PM

It is possible to repair permissions on the boot drive. Disk utility will not repair the disk on the boot drive.



[ Reply to This | # ]
Sorry, no, it won't work.
Authored by: nite77 on Nov 20, '04 05:58:26PM

Have you even tried it before telling all yor ultimate truth? I guess not, since, yes it works. There's even a GUI app that can do that (cocktail).

Check your facts.

---
/Nite - "can't rain all the time"
[ http://www.nitesade.net ]



[ Reply to This | # ]
Sorry, no, it won't work.
Authored by: TimBonnici on Nov 28, '04 04:31:48PM

Actually this is not only wrong but counter-productive. You MUST repair permissions from the boot drive because the boot drive contains the latest details of what the permissions should be. If you have installed any software updates a 'Receipt" is left on the computer which details what the correct permissions now are. If you repair from a boot CD the information contained in the receipts is not acknowledged and therefore permissions maybe incorrectly set.



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: hocevar on Nov 20, '04 01:26:38AM

Great hint for those like me that manually ran Disk Utility.

However, is it necessary to set the two vars and export PATH?
I seemed to have run it without OK (since my default tcsh choked
on them, since then changed script to sh)
And what purpose do they serve? I see that the other replies just show
running diskutil alone in script.



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: adrianm on Nov 20, '04 03:08:04AM
You are right, it is not necessary. Nor is the host= line. Looks like a bit of "copy/paste without really understanding what you're doing" from the author - a bit dangerous for someone providing a hint involving changing root-owned files/directories....

As the only useful command in there is diskutil, it would probably better simply to express the script:


echo "Repairing Permissions
/usr/sbin/diskutil repairPermissions /


[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: Shawn Parr on Nov 20, '04 09:01:34PM

I was not aware that this would work without adding the path, however in many *nix systems if you do not do this then diskutil will not be able to be found.

For instance on many linux systems making a script like this without declaring the path would give you a non-functioning script.

I also kept the host declaration in as it is possible that some apps, including diskutil may require it, and depending on how the system sets up its environment variables you may have to declare it per script much like the PATH reason above.

In SuSE there is an rc.common that the startup scripts can call that includes most of this information. I didn't see such a script for OS X.



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: DanFrakes on Nov 20, '04 12:17:42PM
As treck noted, the easiest way to do this (besides using an automated utility like Macaroni) is to use CronniX to edit the system crontab; I wrote an article on how to do this for Macworld a while back:

Macworld article (the first half of the article, "Schedule Repair Permissions")

Macaroni

[ Reply to This | # ]

Does anybody know?
Authored by: syko on Nov 21, '04 03:07:45PM

Does anybody know if the /etc/crontab can be modified back to its original settings after an OS update? (for server or client?)

I modified /etc/crontab to run backups and was wondering if anyone knew if that file would revert in any future updates.

thanks



[ Reply to This | # ]
Does anybody know?
Authored by: Shawn Parr on Nov 22, '04 01:09:26PM

No one knows for sure, however I personally expect that Apple will occasionally 'tweak' things and crontab being reset/changed is part of that.

That is why I suggest using weekly.local (a file that should never be changed during a system update) or periodic.



[ Reply to This | # ]
Re: Does anybody know?
Authored by: Uncle Asad on Nov 22, '04 02:49:53PM

In my experience, OS updates return the crontab to the default state at least some of the time. I had been using the CroniX method and after a few times of having to reset task times and re-add the repair permissions task, I switched to anacron (to run the tasks when the PB wakes up, if it was asleep) and weekly.local for the repair permissions task.



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: Herschel on Dec 01, '04 10:31:29AM

I'm hoping Shawn might read this, because I tried his script but can't get it to run! I'm admittedly a UNIX novice, but I copied everything down meticulously and followed all the instructions. However on running /etc/weekly I kept getting:

/etc/weekly.local: line 4: unexpected EOF while looking for matching ``'
/etc/weekly.local: line 8: syntax error: unexpected end of file

What have I done wrong - I'm certain its my cock-up. Please help because this little script could really help me out.



[ Reply to This | # ]
Use cron to repair permissions on a regular basis
Authored by: d1taylor on Dec 02, '04 12:49:01AM
That's always a problem with mismatched quotes. Unix is pretty picky when it comes to closing your quotes with the same ones you opened it with, so something like

echo 'this is a test"

will generate an error exactly like what you saw. Check through for matching quotes on each line and I bet you'll figure out the problem. If not, pop over to my Ask Dave Taylor site and you can see (tomorrow, at least) how I solve this same problem with a script... :-)

[ Reply to This | # ]

Thanks Dave
Authored by: Herschel on Dec 02, '04 10:40:16AM

Thanks for that - I wasn't as accurate as I thought - using human grammar :D
Well got it to run except... now I get:

Repairing Permissions on System Drive
/etc/weekly.local: line 6: diskutil: command not found

This has got me very vexxed. "diskutil" is a perfectly acceptable command so why is it refusing to obey?



[ Reply to This | # ]