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.
Apple's Remote Desktop client is the only VNC server I've found that could display both of my displays (G4 with dual video output, connected to two 1600x1200 monitors, for an effective 3200x1200 sized desktop). However, ARD client is also the least configurable VNC server that I have found.
One common issue is not being able to change the port it runs on (default is 5900) ... simply put, I have not seen a true way to do this within the client itself. I wanted to move to a non-standard port (partly for security by obscurity, though I realize that's not real security). Other folks have the issue of wanting to connect to multiple Macs inside the same network.
A real hack that came to mind is this: I have an Airport Extreme router (though almost any router should suffice). From outside the local network, you can configure the router to port forward, as shown in this Apple article.
While connected to one Mac from another on my local network via screen sharing in the Finder (not iChat), I tried to use the Edit » Send Clipboard menu item to copy and paste the text from a local Script Editor document into a Script Editor document on the remote Mac. For some reason this did not work -- the text would not arrive in the remote clipboard (still have to figure what is wrong there). So I tried the the next best thing, not really expecting it to work.
I selected all the text in the Script Editor document on the local Mac, and dragged and dropped it over and into the Script Editor document on Remote Mac ... and it worked! (Dragging text also worked from the remote Mac to the local Mac.) So I quickly tested other dragging operations.
It seems most text from various applications will drag over in one form or another to a text area on the other Mac. And does not have to be to or from the same app on local and remote. A couple more quick examples:
You drag text to create text clippings in the Finder.
In Safari, you can drag the URL in the address bar to the remote Safari address bar, and it will load. Or drag it to the desktop as a .webloc file.
Drag a URL that links to a download file straight into the Safari Downloads window to download it.
TextEditor.app text drags to most places.
[robg adds: You can't drag and drop a file, but this is very useful for text.]
After reading my Airtunes hint, several people have asked me to post a script to restart an AirPort Base Station ... so here it is. The script assumes you can at least see the Base Station in AirPort Utility, which is not always the case so YMMV. You can use the launchd utility or Cronnix if you prefer to schedule it. If you have a shell script for this, please share as I think that would be a more elegant solution.
I noticed that Personal Web Sharing was only partially functional when using FileVault. More precisely, accessing the users web pages inside ~/Sites using a URL similar to http://localhost/~username would always fail with a permissions error. The reason for this failure is fairly simple. When the FileVault user logs in, the encrypted disk image /Users/.username/username.sparseimage is mounted as /Users/username. Apple righty decided that a user using FileVault was trying to protect personal data, and so they set the access rights of /Users/username to 700 (rwx------), thus allowing only the user herself to access anything in her $HOME directory.
Unfortunately, this has the side effect of preventing the local Apache server from accessing the contents of /Users/username/Sites/ resulting in the aforementioned error.
A simple but unsafe solution:
A simple solution would be to change the access rights of /Users/username to 701 (rwx-----x). But that would create a fairly big hole in the otherwise good security settings Apple implemented. Read on for a better solution...
[robg adds: We've posted two previous hints (1,2) on this subject; the unsafe version above is similar to those, but read on for a new solution, based on access control lists.]
Many people have noticed that the Xbox and Xbox 360 will not obtain an IP address from a Mac running Internet Sharing using DHCP. (Apparently some other devices have the same problem, but I don't have any of them to test with.) One workaround is to simply set the Xbox to use a static IP, DNS server(s), etc. That will certainly work, but it may be inconvenient and is definitely inelegant.
This hint will allow your Xbox to obtain its IP, DNS info, and so on from the Mac using DHCP. You need to have administrator privileges on the Mac in question, and the procedure is different on 10.4 vs. 10.5. (Presumably older systems were similar to 10.4, but I haven't tested on anything older than 10.4.10.).
Often from my friends in Window's land, I get the paths like this:
When converted to a file URL on the Mac, this will look something like:
Unfortunately, when I mount the volume on OS X using the normal method, the share shows up under /Volumes with a naming scheme not compatible with the file URL above. My workaround involves making a directory and mounting:
Mount the server the normal way (Command-K in Finder).
Check Remember Password option when authenticating.
Unmount the drive in the Finder -- very important!
Make a directory in Terminal with the sever and share name: mkdir -p /SERVER/share.
Mount the server with the command mount_smbfs //`whoami`@SERVER/share/ /SERVER/share. NOTE: if your short Unix username does not match your Windows server login, make it match. If it requires a domain, things like NNN\;bray are perfectly acceptable.
Once this is done, you should test it out and click on the file URL. This should bring up the program in the same application as if you had double-clicked on the file as assigned by Launch Services.
I have four Macs at home: an Intel Core2Duo Mac mini, an iBook G4, un upgraded Power Mac G4 AGP, and an upgraded Bondi Blue iMac. With the first three (two of them running OS X 10.5.1, and one on OS X 10.4.11), I have no problem accessing my AirPort disk (except for the usual Leopard bug-related troubles), while with the last one (running OS X 10.3.9, which is the maximum possible for that machine), there is apparently no support for connecting to an AirDisk.
Well, it turns out to be possible and indeed rather simple, so this hint is almost obvious when one thinks about it later. So, let's begin. I'll assume that your AirDisk is set up with accounts to access it.
In your Mac OS X 10.3.x Panther Mac, open a Finder window and click on the Network icon in the sidebar.
Choose your AirPort base station and connect to it by clicking on the button.
In the dialog that appears, connect as your AirDisk account (the same as your local user account), choose to remember the password in the Keychain (in order to automate further accesses), and select all available volumes.
The AirDisk volumes will now appear in the Finder: mine, for example, are called AirDisk (the main, shared volume) and Sven (the user account volume).
Open System Preferences and click on the Accounts preference pane.
Drag the AirPort Disk volumes to the Login Items (I think it's called so in English, but whatever the name is...) section of the Accounts preferences and optionally choose to hide the items.
Log out and in again: the AirDisk volumes will now mount automatically! (And if you receive a Keychain reminder during this setup, choose to always allow the access, in order to automate the process as much as possible.)
So, even without the AirPort Disk Utility, it is indeed possibile to use an AirDisk in Mac OS X 10.3.x Panther. One could use a similar method to automount an AirDisk in Leopard, at least until the automount issue is fixed by Apple.
[robg adds: I can't confirm either the problem or the solution, having no access to a 10.3.x Mac.]
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!