The information on this page applies only to Snow Leopard, for Lion the permissions are the same but prelinked kernel caches are used instead of Extensions.mkext files.
Additionally the “pfix” utility is now deprecated, I have replaced it with the myfix utility instead, Please consult the downloads page for a link to the latest version of myfix.
I have written the following utility which simplifies and automates the process of repairing permissions and rebuilding kext caches. It will test for and prevent a number of common errors that may arise if the manual method (Which I have discussed further below) is used incorrectly. I personally suggest that you use this utility (instead of doing this manually) to reduce or eliminate the potential for user error & to save time.
Further documentation and how to do this manually:
One of the most common problems with Snow Leopard on PC’s is incorrect permissions and improperly built kext caches. While it may not always be necessary it is a good idea to correct permissions and rebuild kext caches anytime you modify your extensions or install software which adds new kexts to your system.
To do this manually open a terminal and enter the following commands to repair the permissions on your “/Extra” directory:
$ sudo chown -R 0:0 /Extra
$ sudo chmod -R 755 /Extra
You may also need to repair the permissions on your “/System/Library/Extensions” directory:
$ sudo chown -R 0:0 /System/Library/Extensions
$ sudo chmod -R 755 /System/Library/Extensions
Now build the Extensions.mkext for /Extra/Extensions in /Extra with the following command.
$ sudo kextcache -v 1 -a i386 -a x86_64 -m /Extra/Extensions.mkext /Extra/Extensions
You may also need to rebuild the Extensions.mkext for the “/System/Library/Extensions” directory:
$ sudo kextcache -v 1 -a i386 -a x86_64 -m /System/Library/Caches/com.apple.kext.caches/Startup/Extensions.mkext /System/Library/Extensions
Then you may reboot your system. Please note that the above examples are assuming you want to repair permissions on your root volume ( / ) if you are repairing the permissions on another volume in your system make sure to adjust the path accordingly.
IMPORTANT NOTE: If running these commands from Tiger it is necessary to delete all kext caches instead of rebuilding them. The kextcache utility on Tiger is unable to build Snow Leopard compatible kext caches and as a result any Snow Leopard system which has these incompatible kext caches will fail to boot. The pfix utility (v2.0) detects the OS X version and will apply these changes automatically.
NOTE: I was originally using the find command to set directories to 755 and files to 644 instead of just chmod -R 755. While that method actually sets the correct permissions for your extensions according to the “OS X Standards” there were some failures reported due to a few kexts containing non-standard binaries that required executable privileges. You will find that the majority of vanilla kexts inside /S/L/E have their directories set to 755 and the files inside of them are 644. Thus this is the ‘proper’ method to use when correcting permissions for most of them. The few that have executable binaries inside of them however, make it impractical to achieve perfection. While this is not absolutely required for them to ‘work’ it is a good practice to learn how to handle unix permissions properly and to not have files set to executable (755) unless absolutely required for their operation.
With that said I am now advising everyone to use the chmod -R 755 method I have posted above and to use diskutil to repair the permissions on your snow leopard installation once you get it up and running. More information can be found on the pfix2.0 release page linked above and in the comments on this page.
Thanks for your help. I now have a fully functioning SnowLeopard System!
I also ran into an issue with the “load_smbfs” file set to 644, not 755. I couldn’t figure out why I couldn’t mount any SMB shares, and some searching led me to this page. I actually have been using pfix v2.6, and still ran into this issue. Now that I know what causes it, it’s not a big issue.
Thanks for the utilities (and the myhack installer), as I was able to upgrade my hackintosh to Snow Leopard (w/ the chocolate kernel) on my old P4 3.0GHz box.
Hi Conti,
Thanks for your suggestion. I have finally resolved the issue.
Basically I deleted my kexts (as I suspect the NVEnabler 64.kext that I have installed to be cause of the error) and rebuilt the kext cache :)
Cheers
bryan
Hi Conti,
Thanks to your guide (after innumerous searches on the internet), I have been able to successfully set up a dual boot system for Leopard and Win 7 on my P55/Intel Core i5 system.
What baffles me is everytime I start up my pc and selects Leopard as the system to boot, the pc will immediately cease to send signals to my monitor after the “Taking iSuck out of..”/spinning wheel screen. The hard disk LED continues to blink, indicating that there is hard disk activity but nothing happens on my monitor. Only after a second boot will Leopard load successfully after the spinning wheel screen. This happens all the time.
Any idea what went wrong ??
Regards
Bryan
bryan: My first impression is that this sounds like you need to setup GraphicsEnabler and ensure that it is using the correct pci root.
I wrote a nearly identical script myself and debated for awhile over file permissions for kexts. Indeed I also noticed the Apple provided defaults.
Ultimately I decided that kext developers should be trusted to package their releases correctly. For paranoia reasons I do an ownership check and `chmod -R go-rw`on /Extra but that’s it.
If you really want to idiot proof kext installation, another idea is to use magic numbers to set Mach executables to +x and any other type of file to 644. The risk here is that you’re trying to outsmart the distributor of the .kext who may have set a file executable intentionally.
Directories should always be safe to `find ${extra} -type d -exec chmod 755 {} +`
Pingback: mattgadient.com » Snow Leopard on the MSI X58 Pro-E
Conti,
Thank you for your response. I will make sure to post comments following your guidelines from now on. I downloaded your pfix v2.1.1 and ran it but got the same kernel panic as before. My hardware is listed below. I know this is probably not the right place to ask questions pertaining to things other than permissions. But perhaps i can explain my situation and you can redirect me. I’ve successfully installed SL using a guide posted on lifehacker.com. However I have not been able to achieve full functionality out of my graphics card. I suspect that i need to customize my com.apple.boot.plist and smbios.plist but am uncertain how to do this. Some people have told me that PC EFI 10.5 should do this for me but Im not sure if im doing what i am supposed to. If you have any advice I would greatly appreciate it.
thanks,
spenceju
GIGABYTE GA-EP45-UD3P Intel P45 ATX Intel Motherboard
Intel Core 2 Quad 3.0GHz LGA 775 95W Quad-Core Processor
VGA GIGABYTE|GV-R489OC-1GD 4890 RT Graphics Card
Intel X25-M Mainstream 2.5″ 80GB SATA II MLC Internal Solid state disk
G.SKILL 8GB (4 x 2GB) 240-Pin DDR2 SDRAM DDR2 800
Pioneer CD/DVD Burner Black SATA Model
10/ 100/ 1000/ 2000Mbps PCI Copper Gigabit Network Adapter
Justin: As I stated in the Installer documentation I am not personally well versed in the subtle nuances of getting ATI graphics working in OS X. I am an NVidia man myself. But I do suspect this is your issue. If the posts regarding PC EFI and ATI on netkas blog do not help you I’d suggest you see the IRC channel I mentioned on the home page as there are some other people there using ATI that may be able to help you. Additionally there is a #radeonhd channel on that network for ATI specific questions, it is not as active as the snow leopard channel but someone may be able to help you there.
Good luck, please reply back with a solution when you find one :)
Pingback: Fixing Broken Snow Leopard | Prasys' Blog
When I followed your instructions for fixing the permissions in my S/L/E folder i got a kernel panic at the starting screen. Could you offer any suggestions? I can’t read all of it because of the restart message but this is most of what it says,
panic(cpu 0 caller 0xffffff7f8066320f): “i386_pmGetDeadline: NULL pointer\n”@/SourceCache/A;;leIntelCPUPowerManagement/AppleIntelCPUPowerManagement-90/pmDispatch.c:114
Debugger called:
Backtrace (CPU 0), Frame : Return Address
0xffffff800010be00 : 0xffffff8000204ae6
0xffffff800010bf00 : 0xfffffff7f8066320f
0xffffff800010bf20 : 0xffffff80002c0104
0xffffff800010bf50 : 0xffffff80002d1bc8
0xffffff800010bf80 : 0xffffff80002cb211
0xffffff800010bfd0 : 0xffffff80002dded2
0xffffff80a7fe3d80 : 0xffffff7f8067a4b9
and it continues on like this…Could you please help? I’ve been trying to get this to work for several weeks but so far I can’t figure it out. Any help would be greatly appreciated.
thanks,
Justin
Justin: Looks like NullCPUPowerManagement.kext is not loading properly did you ensure to correct permissions on the files in /Extra and to build a new kext cache? I suggest you run the new pfix v2.0 that I released yesterday as it will ensure that everything has been done correctly and provide you with some feedback in the form of a log file to aid in debugging these potential problems and more. In the future please use pastebin.org for pasting blocks of text for debugging purposes. Also when asking for help it is important to provide me with a summery of what hardware you are attempting to install on as there are some known issues with various hardware configurations.
pfix 2.0 is out and resolves all of these problems and adds features which add considerable functionality and prevent or correct issues that have not even been mentioned on here. Updated original post with new information and link to pfix 2.0 release page.
Cheers
Would it be possible to do your advised repair from leopard, then “sudo diskutil repairPermissions /” from inside snow after install.
I don’t understand these commands completely yet so I’m not sure.
Yes, I intend to actually rewrite pfix a bit fairly soon here but for now my suggested usage is to run pfix or use the manual commands from leopard and then once you have booted snow leopard go into disk utility and repair permissions, or use the diskutil repairPermissions command from the terminal.
Despite my desire to be a perfectionist and adhere to OS X standards as closely as possible it is clear that some kexts are not adhering to those very same standards so I believe my next revision of pfix and this guide will go back to the chmod -R 755 method, it does provide too many permissions to a large number of files and due to my GNU/Linux background it makes me uncomfortable due to the potential security issues that may arise from granting too many permissions to files should not have them. But I think it is better to have things that way and use disk utility to repair them than to not grant enough permissions to some files that need them which can result in failures like the one reported by Britney here.
Maybe something like sudo diskutil repairPermissions / at the end of pfix would be useful if the recommendation is to run repair permissions anyway. Then the recommendation wouldn’t even be necessary. Or maybe just running the diskutil command would replace two SYSTEM_KEXT permissions commands? Just a couple of ideas.
Britney
The trouble with that is diskutil on leopard or tiger is unable to repair permissions on a snow leopard installation afaik… I could perform a test to ensure this is done whenever pfix is running under a 10.x kernel but it isn’t a 100% ‘foolproof’ solution.
Thanks for the great tool Conti.
I understand your reasoning for using 644 on the files inside of the kexts but in some cases I believe the files really do need to be 755. One example is the S/L/E/smbfs.kext/Contents/Resources/load_smbfs. When this is set to 644 connecting to SMB shares never happens and the console says that is because permission is denied. Once I change load_smbfs to 755 I can connect to SMB shares.
I also ran Disk Utility repair permissions after pfix and found that load_smbfs is one of the 80+ errors you mentioned you saw. I also noticed that all of the other ones listed are individual files. I am thinking that some of these errors might cause an error similar to what I see with SMB.
Disk Utility’s database of permission might not be entirely accurate but it seem that it is for the SMB kext.
I am not sure if this is something you could address for pfix but I thought I would let you know what I am seeing.
Thanks,
Britney
I was afraid something like this would eventually come up though this is the first report I have seen.
I thank you for your detailed analysis it is quite helpful. As to the future of pfix I have debated if I should try to integrate some sort of ‘blacklist’ to prevent potential failures like the one you have mentioned or even attempting to find a way to tie it into the disk utility’s permissions database somehow. So far nothing ‘critical’ has happened which prevented a system from booting or caused a kernel panic so I am inclined, at least for now, to leave things as they are and I would simply suggest that everyone should run Disk Utility after any major filesystem changes to ensure that all the permissions are as accurate as possible, just like we would on a real MAC.
There is also the possibility of including an internal md5 database for all the kexts in S/L/E so that the pfix utility only repairs permissions on files which it detects changes in – of course this option does not carry over very well with OS X software updates and thus would require frequent updates to the pfix md5 database to maintain as much accuracy as possible.
I haven’t decided where I should go from here but I am always open to suggestions.
Again thank you for your input,
-Conti
Hey Conti !
great tool… helped me lot .. thanks for the good work… :)
Thanks a lot Conti for the response :) now my tiny brain when it comes to OSX86 became a bit bigger haha.
BTW im subscribe to your blog via Mail RSS so keep the OSX86 related news and fixes coming.
re: #2 YES, that’s what i did because that’s what i saw in a few tutorials floating around (including projectsnow) and it seem to work right of the bat on first boot w/o kernel panic on 32/64. It generated a 30.5MB extensions.mkext in /Extra. Thanks for the very clear explanation :)
Thanks conti, it’s now clear except for #2..
that’s working, im using that method before i stumbled upon your blog :) , it will create a 30MB+ extensions mkext in /Extra
actually my question should be if there’s no difference between those 2 in /Extra (30mb mkext and 11kb+ mkext)?
also another question, tried using your automatic and manual script but after the mkext created, rebooted and tried running disk utility but i got lot’s of permission repaired mostly in /S/L/E.
I think I understand what you are asking in #2 better now. I believe what you did before was generate an mkext of everything in /S/L/E & E and put that all in /E – which is not nessisary. The mkext in /E should only contain the cached contents of /Extra/CustomExtensions. The kextcache for /S/L/E belongs in /System/Library/Caches as listed in my example above.
Regarding your question with disk utility I took a deeper look into this. There are roughly 80 errors (according to disk utility) with the syntax I have used. But there are roughly 2200 errors with the -R 755 syntax. I was just going to say to ignore disk utility because it is often inaccurate and everything I know about kernel extensions tells me that the syntax I have used is accurate and that 755 is the wrong syntax to use for files inside of kexts but I am a bit of a perfectionist so I dug into it further after reading your comment.
After digging into this a bit further myself I asked one of our resident experts in #snowleopard (Thanks Galaxy) just to be sure. He reassured me that indeed the kernel wants to see the files inside the kexts as 644 and to ignore the permissions verification script inside disk utility because it often bitches about things that are not really a problem. It uses a permissions database and that database is not always entirely accurate.
thanks for the script, works well here.
some clarification please, hope you can can reply coz im confuse looking at different guide:
1: im seeing kextcache commands using 0:0 and root:wheel? im seeing you use 0:0 but what’s the difference?
2: also tried creating an mkext using this command ” kextcache -v 1 -m /Volumes/NAME/Extra/Extensions.mkext /Volumes/NAME/Extra/Extensions /Volumes/NAME/System/Library/Extensions ” so the mkext created was about 30MB place in extra but on your’s it’s just a few KB?
3: what does the letter means? -a 1 t etc..
Thank’s a lot for the reply in advance. my system is working in either your script or the ones posted above but i really wanna understand what does it mean that’s all.. :)
I’d be happy to help to clarify for you :)
1: It’s actually a chown command that is assigning file ownership to a user and group (in this case root user, wheel group) not the kextcache command… But to answer your question regarding the difference between 0:0 and root:wheel – there is none. If you take a look at the chown man page
“The owner may be either a numeric user ID or a user name. If a user name is also a numeric user ID, the operand is used as a user name. The group may be either a numeric group ID or a group name. If a group name is also a numeric group ID, the operand is used as a group name.”
In my example I have used the numeric user ID and numeric group ID rather than the user name and group name for two reasons.
1) It is quicker to type.
2) I believe it is harder to accidentally type incorrectly.
2: I’m not quite sure I completely understand what you did here (that syntax you have pasted wouldn’t work right at all) but I believe you are asking why the Extensions.mkext for /Extra is so much smaller than the one for /System/Library/Extensions?
If that is what you are wondering the answer is simple. There should only be a few Extensions in /Extra/CustomExtensions but there are many in /System/Library/Extensions. Therefore the cache for /Extra/CustomExtesnsions is going to be much smaller, because there is much less information to add to it.
3: If you take a look at the kextcache man page you will see what these flags mean but I will list them here as well:
-v is for -verbose, -v 1 is the lowest level of verbosity (other than silent)
“1 (or none) Print basic information about program operation.”
-a is for -arch, -a i386 is i38 arch, -a x86_64 arch, this is required because on older operating systems like leopard or tiger will actually build either only i386 or i386 & ppc but fail to include the x86_64 parts of the extensions in the mkext (cache) file. NOTE: In snow leopard it will build i386+x86_64 by default so this would not be absolutely required unless running the commands on an earlier version of OS X.
Hope that clears things up for you, if you have any additional questions don’t hesitate to ask.
Nice, though you neglected to mention where the original script you based this off of was from ;)
Any similarities to your old script were purely co-incidental.
Though I had used a different syntax for the kextcache command in my original script and changed to this when I saw yours (I’m not sure the syntax I used before would have worked outside of snow leopard) & I should let everyone know that Apocolipse is the one who suggested that I add the prompt for destination volume to the script rather than require the users to place the script in the root of the target volume – which was a superb idea!
Really nice guide. Had a question though, i tend to stick away from find on *nix because its different on every system. Is the type flag common to linux too?
Alternatively you could just do something like (this should work with any bash):
find | while read i; do if [ -d $i ]; then chmod 755 $i; else chmod 644 $i; fi; done
(Haven’t tested that code tho ;) just came to mind…)
D.
russo: I appreciate your feedback and I see what you are trying to suggest here…
There are a few reasons I didn’t go that route.
For one thing the code you have posted is invalid syntax and will not work…
The primary reason though is I wanted people who may not have much experience working with bash to really understand what is going on in this code. While I could have easily reduced the commands to ‘one liners’ I believe it is easier to understand the examples with the syntax I have used. If you are looking for a one line command to achieve all of this – the script I have posted is the way to go.
Gr8! J0b!