Yesterday, the hard drive in my 12" PowerBook G4 (purchased in April, 2004) died a horrible, painful death. After doing some testing on the machine (it typically doesn't hold any critical data, so it's an ideal test platform), it failed to reboot. Long story short, the hard drive was dead. Really dead -- Disk Utility told me "This drive has reported a fatal hardware error to Disk Utility. If the drive has not failed completely, back up as much data as you can and then replace it with a working drive." Thankfully, it then mounted in a partially-usable state, and I was able to retrieve the one bit of non-backed up data on the drive (my wife's Palm Pilot contacts, which contained updates she hadn't yet synched back to the Pilot).
After installing a new drive and reinstalling 10.5.2, I set about copying key files and programs back to the machine. However, my AirPort performance was glacially slow: time estimates to copy 70MB of data were in excess of 45 minutes! Some Google searching told me that I was not alone. Apparently this is a pretty big issue for many people on 10.5.2, but it's not universal -- our MacBook Pro, for instance, sees no such slowdowns.
I haven't marked this hint as 10.5 only (as the solution can be implemented on 10.4, too), but it does seem that the problem is limited to those running 10.5.2, and using AirPort on either Intel or PowerPC machines. Read on for the solution...
In OS X 10.5, Apple added the ability to share individual folders to the Sharing preference panel. However, one needs to be aware of permission problems when attempting to share a particular folder. To illustrate this problem, I will use an example:
Create folder ABC in ~/Documents
Press Command-I and check the Shared Folder checkbox
Click on the Enable button to enable file sharing
Go to the Sharing panel in System Preferences and click on the File Sharing item
Click on the Options button and enable SMB sharing by checking the Share Files and Folders using SMB checkbox (there is no need to enable SMB sharing of accounts, as we will see later)
By this step, you would expect to see folder ABC under your computer's name in Network Neighbourhood in Windows, but it's not there. In fact, you can't even access the share by mapping \computernameABC! However, if you move folder ABC to ~/Public and share it again by unchecking and then checking the Shared Folder checkbox, then ABC will become visible.
This behaviour can be explained by the fact that ~/Documents has the permission rwx------, which means other users can't even browse the contents of that folder. On the other hand, ~/Public has the permission rwxr-xr-x, which allows browsing of the folder content by any user. So in order to successfully share a folder, not only do you have to make sure it's accessible to other users, you also have to make sure its parent folder can be browsed by other users.
Another interesting thing to note is that SMB sharing for a user account is independent of individual folder sharing. Enabling it will share the home folder of the enabled account as it did in Tiger, but it's not necessary for sharing individual folders (so you no longer have to store your password in a less secure way when you enable SMB sharing).
I've recently configured my Mac to tunnel web traffic through my university to take advantage of some free services accessible only from their IPs. I accomplish this using a dynamic port tunnel over SSH with the great SSHKeychain tool (which handles SSH key management as well as tunneling). Enabling the tunnel is just a click in a menu bar drop-down.
Enabling/disabling the global proxy settings is not quite as easy, however. You have to manage everything through a secondary tab in the Network preference pane. So I wrote ToggleProxy (874KB download) to speed up the process. It will toggle the SOCKS proxy on and off automatically (make sure the server and port are already set in the Network preference pane), and display the status with a Growl notification if you have the growlnotify tool installed, or in a native dialog box otherwise.
Make sure to read the ReadMe file, as you may have to make a change to use the tool for Ethernet as opposed to Airport. For those of you who want to expand the tool to implement manual proxy settings or using other proxies, I recommend you look up the networksetup command-line tool. I also use scutil to discover my proxy settings, but that is also possible through networksetup.
Note: I use 10.5.2, and I don't know if networksetup is available in previous versions of OS X. If you do not have networksetup, then ToggleProxy will not function.
[robg adds: I haven't tested this one. If you'd like to see (or change) what it does, you can first view its bundled AppleScript and bash scripts. You can see the script sources by digging into the package -- Control-click on the app icon and pick Show Package Contents from the pop-up menu, then navigate into Contents » Resources » Scripts folder. The networksetup application is available on pre-10.5 systems, as described in this hint, but you'll probably want to copy/link it somewhere else to use it regularly.]
I recently had my MacBook sent in for repair. While I was waiting for it to get back, I booted my backup drive through my Mac Pro so I could continue working. Once I got the MacBook back and I restored from my backup, AirPort refused to turn on.
Eventually I found out that Leopard makes a few changes to network device mapping, and doesn't always clean up after itself. It seems that going from one Ethernet port and one AirPort to no AirPort and two Ethernet ports and back again confused it greatly. This thread on Apple Discussions goes over the same problem, in a lot more detail.
To work around it, I had to delete AirPort in the Network System Preferences pane and recreate it -- making sure to remove the AirPort icon from the menu bar before hitting apply (restoring /Library » Preferences » System Configuration from Time Machine should also work). It also seems I would have had this problem if I booted the MacBook into Target Disk Mode and then booted the Mac Pro off it.
Moral of the story: Be weary of booting different classes of machines off the same drive.
I have been struggling with browsing Windows workgroups in 10.5.x. Hints on these forums fixed the workgroup name sticking, but when trying to connect to the Samba share on my print server, OS X wouldn't display the workgroup name. Although SharePoints no longer works in Leopard, I had used it previously to set an OS X Mac to be the Workgroup Master Browser to reduce the number of elections in a Windows 2000/XP network.
With nothing left to lose, I fired up SharePoints, set the workgroup name (on the SMB Properties tab), and set the Mac to be the master browser. Problem solved.
You are sharing the Internet connection via Airport, but after every reboot, the AirPort icon in the menu bar shows that Internet Sharing is disabled. Looking in the Internet Sharing prefs panel, everything is configured correctly. Disabling and enabling it again, and it works as it should. This happened to me various times with 10.4.11 and it always happens with 10.5.x. I discovered that by killing either the InternetSharing or the bootpd process, launchd restarts them correctly and InternetSharing gets enabled. Since launchd stores the PID of bootpd in /var/run/bootpd.pid, I thought to automate the process of "refreshing" InternetSharing/bootpd at boot time by means of the /etc/rc.local script. (For compatibility reasons, this script still works in Leopard -- see man rc for details. Basically one needs just to issue the following command:
sudo sh -c 'echo kill $(cat /var/run/bootpd.pid) >> /etc/rc.local'
Run that command, then reboot. After logging in, you will notice that the AirPort icon will show a disabled Internet Sharing state that switches automatically to enabled after a slight delay. I also noticed that this workaround fixed a problem I had with Medialink (a program to share media files to the PS3 via UPnP) that did not always recognize my PS3.
Having lost part of a Sunday getting a hardened SSH to work between my various machines, it was a pleasure to recover by writing a Python script to create an /etc/sshd_config file I could actually read. Here's the script, which I've named sshd_config.py, to transform /etc/sshd_config into a more literate form, based on the man page for sshd_config.
To harden SSH on OS X, one modifies /etc/sshd_config. The web abounds with advice on what options to set, some of which are now deprecated. For others, the man page and Apple's /etc/sshd_config disagree on which is the default value. In these cases, /etc/sshd_config appears to be correct, but one cannot be sure.
This script creates a commented copy of the man page for sshd_config, and modifies it by inserting default values from /etc/sshd_config into each option heading, and inserting statements. It also sets each option which is set by /etc/sshd_config. The output file can be used as a more literate /etc/sshd_config, which one can now edit with some hope of understanding what is going on.
Sample use: Move the Python script to a work directory, make it executable, and execute the command line
./sshd_config.py /etc/sshd_config sshd_config
Best practice: Copy Apple's original to a safe place before replacing /etc/sshd_config with a modified copy. Many other hints here cover what your local copy could or should say.
Advice, in case of trouble with SSH: Execute the command sudo grep sshd /var/log/secure.log on each host machine, and believe what you read. One can ssh onto one's local machine as if one is elsewhere, so try all possible (from, to) pairs including self-connections, to see where the problem is: Are you having trouble whenever machine A is involved, or whenever machine B is involved? Whenever machine A is the host? Having four data points really helps isolate what's wrong.
[robg adds: This seemed to work as described when I tested it.]
There are many legitimate reasons why someone would want to spoof a system's MAC address, and I won't go into them here. Long story short: in Tiger, it was extremely easy to spoof the MAC address, as explained in this hint. In Terminal.app, just type:
sudo ifconfig en0 ether 00:00:00:00:00:00
where en0 is the network interface you wish to change the MAC address of, and 00:00:00:00:00:00 is the target MAC address. This code cannot be used in Leopard, but it turns out the solution is extremely simple, and just as straightforward. Again in Terminal, just type:
sudo ifconfig en0 lladdr 00:00:00:00:00:00
That's it; you're done.
[robg adds: Based on the comments to the author's original blog post, it seems this isn't working for everyone on every combination of hardware.]
This is not really a hint, but a happy announcement. Since March 2005, I've been unable to connect to my university's server using SMB via the Finder on Tiger. I'd get a "Mount tree phase error -36," which happened only when connecting thru the Finder -- using the smbclient Terminal command did the trick. I finished my Masters degree, and yet this was still broken in the first release of Leopard.
On reboot or after long periods of inactivity, my client's OS X 10.4.10 Mac would lose its network connection to his home's wireless network, and he'd have to re-select the network name from the AirPort icon in the menu bar. He had set a 40-bit password, and the non-Apple router was configured with the same 40-bit password.
By changing the router password to a 128-bit password, and changing the password on the Mac to the same, it's now able to restart or go to sleep and re-establish its connection to the wireless router without any problems.