The main idea behind this hint would be to run servers that accept secure encrypted logins, but if you are not in the position to change the server environment, and have hundreds of Macs that you wish to disable the Connect to Server clear text warning on, this hint should work as expected. Use Apple Remote Deskto or other methods for multiple machines -- it's the 'getting around the UI' bit that counts in this case.
I believe this also serves to detail the proper way to edit nested dict keys using defaults write (man defaults in Terminal.app if you have further interest). Here's the long (one-line!) command:
Clicking on the Startup Drive, a folder, or trying to empty the trash brings up a Connect to Server... dialog, sometimes with nothing but a gray background. The Spinning Rainbow Ball spins and spins, but whatever you clicked on does not open up (or in the case of the Trash, does not empty).
Interestingly, I found that I could run any program that was in the Dock, including making email connections and internet connections. I believe this is because the three actions that it would not do involve accessing the LAN due to the sidebar at the left of the window (in the case of folders), and checking network trashes (in the case of emptying the trash).
Disconnect your network cable & reboot.
Throw out aliases in the Recent Servers folder.
Go to your Keychain Access (in the Utilities folder) and toss out all references to the phantom server.
Go to Connect to Server... (Command+K) and remove any references to the phantom server there.
Plug your network cable back in and reboot your computer.
Go to Connect to Server... (Command+K).
Now connect to a server that you know is there.
When that server comes up, click on your own drive in the Task Bar at left. It should open now. All other folder functions should now be restored as well.
What Didn't Work:
Zapping the PRAM
Booting into single user mode (Command+S at startup) and running a file system check (/sbin/fsck -fy)
Running Norton (although it did "fix major errors")
Booting off installer CD and fixing permissions (using Disk Utility)
I hope that this has been helpful, and that it saves you some of the time and heartache it took me to fix the same problem -- this happened on three of our Mac workstations in one week. You can also download an illustrated version of this hint if you wish...
For those of us (foolhardily?) brave enough to upgrade to Tiger via Archive & Install, one of the annoying consequences can be the inability to select anything other than "A specific network" in the Network settings panel to join by default. The new "Preferred Networks" setting is also AWOL. (Another annoying consequence of an Archive & Install: Volume Logic doesn't move to the new installation ... drat!)
While this hint discusses general tips for cleaning out the Airport known/preferred network list, the solution for this problem is much simpler: delete and recreate the network locations that use Airport (Location menu -> Edit Locations... -> Delete). Voila! The Automatic & Preferred Network choices now show up.
It seems to be a common problem that, when connecting with Mac OS X VPN client to a VPN server, you end up with getting a default route to that server. But in some cases, you'll still want to use your original internet connection by default, and only have the routes for the remote VPN pointing to the VPN server.
I found some solutions on the net (most of them involved making a wrapper around pppd or hacking some of the system scripts), but they are neither a proper nor one-size-fits-all solution. The right way to do it is as simple as this...
Put the keyword nodefaultrouter into the file /etc/ppp/peers/your-vpn-name. Then create a script called /etc/ppp/ip-up with the following contents:
route add 10.0.0.0/8 -interface ppp0
Replace 10.0.0.0/8 with the network address of your VPN. I hope this helps.
After digging around on the Internet for quite some time, I came across this hint on a German website. I used an online translation site to translate the text to a rough English version. Wish Cisco could be as helpful as the Germans...
You will need to use the Terminal to perform this modification. What you need to do is replace the cvpnd file in /opt/cisco-vpnclient/bin with an extracted version from the installer disk image. Once you have replaced the cvpnd file, you should verify the proper permissions have been set on the file once it has been replaced. Here is a cleaned up version for your digestion.
After upgrading to Tiger (fresh install), I could no longer use my TiBook to print over the network to my Samsung ML-1710 laser printer, which is connected via USB to my linux server "beigeg3" (running CUPS) in my home office. Even worse, once the network printer was selected in the Tiger print dialog, I couldn't do any kind of printing task -- not even Save to PDF for transferring to the linux server. All attempts ended with the unhelpful error message "Error while printing". I haven't been able to find any reference to this problem on the net, but the fix is so simple, I think it's worth sharing.
Using the CUPS http interface (http://localhost:631) to try to print test pages gave me useful error messages: apparently Tiger reported the Linux server hostname to cups as "beigeg3," but CUPS didn't know where to find that host (no DNS server runs on the LAN). Adding this line:
to the /etc/hosts file on the TiBook let CUPS know where to look fixed the problem. Of course you'd want to use the IP address and name of your own print server there. This seems like a bug to me (shouldn't CUPS be able to access NetInfo to get this address?).
Here's a workaround for a somewhat obscure file sharing bug. If you have an external drive on a Panther machine you are sharing, do NOT check the Ignore Ownership box in the Get Info window. If you do, there is a bug in the Tiger client such that it can no longer write to that drive -- reading is fine.
I called Apple's tech support and was able to get their tech to reproduce the problem. He seemed quite surprised that this was such a simple bug to reproduce. I have not confirmed if this problem occurs when sharing drives between Tiger and Tiger.
I turned this checkbox on as I have a very simple network and want people to read/write anywhere on this drive and not get ownership headaches. Unix in a nice OS, but its file permissions, while very powerful, are not well suited for a home network where security is a very low priority.
[robg adds: I can't confirm this one, as I no longer have a Panther machine available. But it's apparently been verified by Apple, so hopefully, a fix is coming soon...]
If any of you are interested in streaming your own video or audio handywork over the internet to your cell phone (be it a 2.5G phone or 3G phone), I've put together a little site with all you need to know. It's aimed at education, but there is nothing stopping you having a go yourself at home, if your Mac can be seen by the outside world -- that is, your home computer has an outside IP address on a broadband connection.
I kind of stumbled accross this by accident. You can move your Saved Searches folders from the directory ~/Library/Saved Searches to your Desktop (which I think is pretty obvious); but I hadn't really thought about dragging them to my iDisk ... but you can.
Of course, you're only synching the query terms from the .savedsearch file that is the "smart folder," but the nice part is that complicated queries dont't have to re-created repeatedly (along with all the usual benefits of synchronization).
As some readers of Mac OS X Hints have noticed, Apple has removed the set-hostname file (in /System: Library: SystemConfiguration: Kicker.bundle: Contents: Resources) necessary for modifying the routing table when connecting to a VPN.
Instead of using this file as a hook for implementing split routing (as per a previous hint), Tiger has built-in support for split routing, as described in this recent hint.
If you still need to modify your routing tables after VPN connections are established, you can do so by creating the file /etc/ppp/ip-up (with executable permissions), and entering something similar to the following inside:
/sbin/route add xx.yy.zz/24 aa.bb.cc.dd
Replace xx.yy.zz/24 with your destination network and aa.bb.cc.dd with your VPN gateway. Note that you might be able to re-use the fix_vpn_routing.sh script from the equivalent hint for Panther.