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.
Are you using PPTP to connect to a Microsoft ISA server for VPN? Do your internal machines on the VPN side of the connection no longer resolve except when you use a fully qualified domain name?
The PPTP VPN settings under 10.5 provide some additional options, which you can reach via the Network System Preferences panel. Go to VPN, and click on Advanced, then view the Options tab. The setting is "Send all traffic over VPN connection." If this is unchecked, you will be unable to resolve internal hostnames without typing the fully qualified domain name. If you check it, you will be able to refer to your internal hostnames by the short name. This occurs no matter whether you have your VPN local DNS search domain typed in there or not.
I think this may in fact be a bug in 10.5, since it presumably should work without have to force all the traffic over the VPN.
One thing that I really miss from Tiger is having a shortcut on my Desktop to my network shared volumes, so I don't have to open a Finder window, click on share, and then select the machine or AirPort Extreme entry, and then the volume I want to access.
Leopard won't let you make an alias of a network shared volume, or create one by dragging it to your desktop. What I found out, however, is that you can drag a shared volume to the dock as a Stack folder, and there it is, a direct link to your shared volume. You have to drag it to the area next to the trash; it won't work in the applications zone of the dock.
It also helps when the Shared option won't even appear, and you don't remember the direct link to get to the volume through finder's Go » Connect to Server option. This happens quite often with AirPort Extreme, and now I just have to click the shortcut on the dock and it will come right up.
[robg adds: As noted in this hint, there seems to be either a bug or a feature in the new Finder: using Column view, you can make aliases from networked volumes via a drag to the desktop (or to the sidebar, as in the previous hint). Using other views, though, you cannot. I can only hope that this is a bug is in the 'other' views, and it's not something that's "fixed" in a future update by breaking the column view behavior! Regardless, putting the network share into the Dock as a Stack is an interesting trick.]
After upgrading to Leopard, I found I was unable to mount any of the shares on my Linux file server, getting the following error:
The operation cannot be completed because one or more required items cannot be found.
(Error code -43)
At first I thought this was because of the security configuration I was using on the file server, or perhaps because Leopard had changed the type of authentication method it was expecing from an SMB file server (NTLMv2 for example). It turns out it was a lot simpler -- it was because all of the shares on the file server were set as non-browseable (Browseable = No in /etc/smb.conf. Changing at least one share to be browseable corrected the issue and let me connect to the file server and mount the shares available, regardless of if they were set as Browseable or not.
It should be noted that if you connect to any windows servers, then you will not notice this issue as the default shares for drives (c$, d$, etc) are browseable, but most SMB client implementations will 'hide' them from the end user.