In Tiger, if Bluetooth was switched on and your devices were properly paired, you could send files in both directions quickly and easily unless you had disabled it.

In Leopard, this is not the case. File transfers are disabled by default, despite a successful pairing of devices. Worse still, the preference that controls this isn't even in the Bluetooth pane. To re-enable Bluetooth file transfers, visit the Sharing pane in System Preferences, and enable Bluetooth Sharing. Different privileges are available for security purposes.

[robg adds: Although this is fairly obvious, given how different this is from 10.4, I felt it was worth sharing.]

As a long-time user of FreeBSD, one of the many little things I like about that system is the way in which the automounter daemon is configured by default to allow the creation of dynamic NFS mounts through symlinking. To my delight, I've discovered that Leopard's AutoFS subsystem ships with the same capability enabled by default.

If you have an NFS server called hostname providing a filesystem /path/to/share with permissions such that it's NFS-mountable by your Leopard box, you can simply change directory to /net/hostname/path/to/share on your Mac, and you will auto-magically see the shared filesystem.

To create a permanent pseudo-mount point for this share, just use a symlink: Go to the location where you want your "mount point" to appear and create the link with ln -s /net/hostname/path/to/share. This will create a symbolic link named share, which will now provide easy access to the remote filesystem. (You can, of course, give your link a different name by using a second parameter to ln -s.)

Mounts created in this way by AutoFS are dynamic; they're created when you access them, and are automatically unmounted after a while. Your Mac will be unaffected should the NFS server "go away" for any reason. While the above should "just work" in many cases, some NFS servers (particularly Linux) require you to initiate the NFS connection from a reserved port number. You can configure AutoFS to accomplish this in one of two ways:

• Edit the file /etc/auto_master, and add resvport to the comma-separated list of options at the end of the line that starts with /net. This will affect only automatic mounts under /net.
• Edit the file /etc/autofs.conf and add resvport to the comma-separated list of values for the configuration parameter AUTOMOUNTD_MNTOPTS. This will globally affect all AutoFS mounts.

Finally, note that this only represents the tip of the iceberg as far as AutoFS's capabilities are concerned. Read the relevant manpages for more ideas!

I recently purchased a D-Link DPR 1260 multifunction print server, and I've been able to share print and scan functions with both Windows and Mac computers on my home network. Unfortunately, the Mac documentation for this print server is almost non-existent. Based on bits I found online, I was able to piece together how to get it to work w/ my MacBook (running 10.4.11):

1. First, do the initial set up and configuration with a Windows PC, as directed in the included quick start manual.
2. To make sure your Mac can see the print server, open up your favorite browser, and enter the IP address of your print server, as assigned by DHCP on your router into the URL box. (My router assigned the IP address 192.168.0.100.) On this web page, be sure to note the IP address and LPR queue name.
3. Open up the Printer Setup Utility (/Applications/Utilities/Printer Setup Utility).
4. Hold down the Option key while clicking on More Printers...
5. In the next dialog box, under Device, choose LPD/LPR Host or Printer.
6. In the Device Name field, give your printer any name you want. Since my shared multi-function printer is an HP PSC 2110, I simply named mine PSC2110.
7. In the Device URI field, enter the following: LPD://IP_Address/LPR_queue_name, using the information gathered in step two. For example, mine was LPD://192.168.0.100/PSC2100Series.
8. To be able to use the shared scan features, create a bookmark to http://IP_Address/scan.html (e.g., "http://192.168.0.100/scan.html" for my setup), so you can operate your scanner from a web interface.

[robg adds: As suggested on the queue review site, it would be a good idea to give the print server a fixed IP address, rather than a possibly-changing DHCP address. If the IP address happens to change, you won't be able to print.]

If you've used this hint to enable Time Machine backups to non-supported network drives, this hint is for you. In particular, your backups are in danger. I have received a few hint submissions warning about problems with these disks, where everything seems to work fine at first, but when the SMB drive fills up, Time Machine will quickly destroy all of your backups! This seems to happen because Time Machine can't free the space inside the networked sparse image bundles (or the reported space is incorrect). Whatever the cause, Console will show all of your backups being removed once the networked drive fills up.

I have placed a strong warning on the original hint (as this issue is noted in the comments there, too). However, I felt it worth running on its own for anyone who may be using an unsupported network drive and isn't yet aware of the impending troubles they will have when it fills up. You have been warned; for now, this is not a usable backup solution, it seems. (I don't know if limiting the size of the backup, as per this hint, would solve the problem or not.)

In trying to use our Macbook (with Leopard) wirelessly at the local University library, we encountered a problem. They have a captive portal such that the connection to the wireless system has no password, but you must authenticate via your web browser. The Macbook connected to the wifi system, or at least it claimed it did, but no actual connection was established, and of course, the captive portal was never activated. After some trial and error with the university's IT people (who told me that they had seen this same problem with a few Leopard Macbooks and Macbook Pros, but never with Tiger or with non-Macs), we figured out a workaround.

What you do is create another Location (we called ours "Kludge"), and leave it at the default settings. With that location selected, the airport worked flawlessly, the captive portal activated, and everything was wonderful again.

My suspicion is that the Automatic location can get munged somehow, possibly if third-party network devices are installed. We had installed a Novatel CDMA modem on that machine in the Automatic location. Anyway, once Automatic gets broken, then it could fail in subtle ways such as what I described. Setting up a new location gives the system a tabular rasa to work with, and in this case, it was sufficient to solve the problem.

I have a number of Macs and Red Hat servers running with sshd and kerberos (using an MIT KDC running on Red Hat). I can log onto any of these servers just fine with Tiger, but with Leopard, I cannot. I've set up kerberos on the Leopard client, and I can acquire a ticket. However, when I try to log on to a server, it appears that the client isn't even trying to send the kerberos ticket.

I will not take credit for the following solutions; they come from Apple Support. However, I've tested them both, and they worked for me.

10.5 disables gssapi authentication by default. You have to edit /etc/ssh_config, uncomment the line containing GSSAPIAuthentication and change no to yes. Engineering claims this change was made in 10.4.9 and later, but 10.4.10 and 10.4.11 allow gssapi authentication by default for me.

You can also run ssh server.com -o GSSAPIAuthentication=yes to force GSSAPI authentication.

First, this is just for fun, and has no practical use at all. Second, see the warning below before trying this...

Everyone knows the old fairground trick of infinite mirrors, where opposing mirrors give an image repeating itself into infinity. This was also replicated famously in Queen's Bohemian Rhapsody video. Well, try this...from Mac #1, connect to Mac #2 using screen sharing in the Finder (not iChat). From within the screen sharing window, connect Mac #2 to Mac #1, again using screen sharing. Stand back and wonder what you can use this for!

Warning: I had trouble getting out of this mode once in it. To do so, I put Mac #1 into sleep mode (press and hold the power button), and as soon as I woke it again, was able to quit screen sharing. YVMV, and I have no idea what effect different window sizings or options may have. Fun for the child within though :)

In reality I think this is actually a bug, or at least an oversight by Apple. With my sensible head on, the app should warn you and/or make this impossible.

This is not quite a hint, hack, or anything, but it's still of interest for those who like me were interested in upgrading their 802.11n-capable iMacs to the rank of 802.11n-enabled iMacs.

Well, I happened to decide only now that I would do that update after many months of resistence. (I didn't have the need for it as my router doesn't support 802.11n, but I am actually thinking of changing my router to a better one, so why not get an "n" one?). To my surprise, the Enabler wouldn't install or work on my iMac, even though it is 802.11n capable. So I looked into some Tech Support Docs, namely this one which describes how to tell if your machine is n-enabled or not.

To my surprise, I found out that when I installed Leopard, my iMac's n-mode was activated automatically! So people with those "borderline" iMacs like mine who never enabled your 802.11n, this is one more reason to upgrade to Leopard -- it will save you the $2 cost of the enabler.

Mac OS X Leopard does not discover and automatically mount NFS shares publsihed via Bonjour/ZeroConf as Tiger did. (If you own a Linux based server, you can publish all kinds of Bonjour servers via a daemon called avahi). 10.5 only discovers AFP and SMB Bonjour published shares as far as I am aware.

To work around this temporary bug/missing feature, I wrote a simple Ruby-based daemon which you can install so it starts up every time Leopard boots. This daemon simply continuously browses for and resolves published NFS shares and will mount them automatically if they are not already mounted for your user account. Let's hope Apple will fix this soon so we do not need anymore workarounds like this.

[robg adds: I have mirrored the source [4KB download] here on hints, but if you're reading this at some point in the future, you may wish to check the link above for a newer version.]

This hint will allow you to use T-Mobile's WPA encrypted connection at T-Mobile hotspots. This is an update to this previous hint.

Open Network Preferences, select AirPort, click Advanced. In the Advanced section, click on the 802.1X pane, then click the 'Enable 802.1x Login' box. In Wireless Network, enter tmobile1x; under Authentication, check these: TTLS, PEAP, EAP-FAST, LEAP, and MD5. Now click OK.

Under Network name, select Join Other Network; in Network Name enter tmobile1x, and under Security, select WPA2 Enterprise. Finally, for 802.1X, select TTLS-PAP. For User Name, enter your T-Mobile Hotspot user name (what you'd enter on the login screen). For Password, enter your T-Mobile Hotspot password.

Now click Join, and you'll be connected and able to surf! NOTE: You will not need to login on a web page when you use this method.