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!
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):
First, do the initial set up and configuration with a Windows PC, as directed in the included quick start manual.
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.
Open up the Printer Setup Utility (/Applications/Utilities/Printer Setup Utility).
Hold down the Option key while clicking on More Printers...
In the next dialog box, under Device, choose LPD/LPR Host or Printer.
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.
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.
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.