The Console.app found in the Application -> Utilities folder (or Other folder in Launchpad) gives you access to the logs for the machine.
Under /var/log, the file named install.log (and any variants named install.log.x.bz2) will give you the information about the last install.
Note the files named install.log.x.bz2 are older versions of the same file created duting a process called rolled over when the file size of the current install.log file reaches 1000K
You need to search your install.log for the string "OSXUpd10.8.2Supp.pkg" which will give you an idea of what happened during your install.
Update: From your log file, it would appear that your have a Kernel Extension that is causing this issue. Either it has a permissions problem, or is somehow causing this annoying issue.
can you paste this line into Terminal, and post the results?
kextstat -kl | awk ' !/apple/ { print $6 $7 } '
Update 2: This would appear to be at least a trial and error solution. There are multiple threads on the Apple Support forums, from installing 10.8.2 to installing Xcode. Each one has different people each having issues with different kernel extensions that when removed resolved their issues.
I'm afraid I don't have any way to determine which of your kernel extensions is the cause; someone else may be able to shed more light. I would however expect the Virtual Box and Parallels extensions to be fine, not the least since I have them both also, but that this issue would be more widespread if they were the issue.
Finally: the manual for kextcache advises that using the touch
command on /System/Library/Extensions/
forces the kext cache to be rebuilt. You could use this as a method to determine which kext is causing the issue by uninstaling each in turn, performing the cache update and checking the logs to see if the cache was updated successfully.
In your configuration, you have unix extensions = no
which is fine, but that is why symbolic links on the server are showing up as folders and not aliases. In this mode the server resolves the symbolic links and the client never sees them. If the client tries to create a symbolic link, the server actually generates an alias file, not a host-OS symbolic link. Reasons for this include security (preventing someone from getting access to /etc/passwd
on the server by creating a symbolic link to it) and client compatibility, as OS X and Windows and Unix have slightly different ideas about what constitutes a symbolic link but they pretty much agree on what is a directory or a file.
Permissions issues with SAMBA are complex, so it's not clear that you do not have a permissions issue. Likewise symbolic like resolving is complex, so it is not clear that what you are doing should, in theory work, and there's always the possibility of a bug (most likely in the SAMBA server).
When accessing a SAMBA server from a Mac, these identities and permissions are involved:
- The Mac User you are logged into the Mac as
- The SAMBA user you are logged into the SAMBA server as
- The SMABA server host OS user you get converted to
- Unix-style file permissions
- For NTFS and HFS+, associated file-system ACLs
So even though you have provided a lot of information, it's still not clear that you are not having permissions problems. The fact that you can mv
and cp
on the server (using what account?) does not mean you do not have a permissions problem preventing you from doing it on the client (using what accounts and with what effective account on the server?).
If the server is supporting ACLs and since you have options like inherit permissions = yes
and inherit acls = yes
set there could be some kind of ACL problem that is only allowing read access to directories accessed via symbolic links. There are several other avenues of investigation based on the server configuration.
I would really expect you should be able to find more information in the SAMBA server logs than you have communicated. They should give you a much better sense of exactly what is being denied.
For what it is worth, I tried to duplicate your setup using an Ubuntu 12.04 host as the SAMBA server and could not reproduce your problem. Symbolic links worked for me as expected.
Best Answer
Most of these codes are defined in the
MacErrors.h
header file. It might be that you need Xcode installed to have that header file on your system, so you can look it up online here:https://opensource.apple.com/source/CarbonHeaders/CarbonHeaders-18.1/MacErrors.h
It lists a huge number of error codes with a short explanation.
Some error codes are not defined in this header file, but instead in other, similar header files for various subsystems. For example
AppKitErrors.h
,FoundationErrors.h
,CoreDataErrors.h
, etc.Unfortunately your error code
-8058
is not defined inMacErrors.h
.