Before a network volume disconnects -- or prompts you to disconnect -- you're likely to have a period of anywhere from a few seconds to a few minutes where wheels of death start popping in your running applications. At first you think something bad is happening, and then you get the notice that a network volume can no longer be found. I still don't understand why this can't be fixed.
In the meantime, turning off your airport from the menu bar (assuming you're connected wirelessly) speeds up the process dramatically. As soon as you suspect you're having the problem, turn it off. You'll get the disconnect from volume box and then you can turn it right back on and continue.
Not a fix exactly, but it helps!
[robg adds: This used to be really bad in 10.4, but with 10.5, I haven't noticed many problems with disconnected shares causing issues in apps on machines that were connected to those shares.]
Over the years, we've run a numberofhints detailing solutions to a seemingly simple issue: how to set up a Mac as a shared file server for a workgroup, such that multiple users can create, modify, and delete files and folders on that machine. (There are permissions issues related to users modifying files and folders created by other users.) The solutions I've linked to here all solve the problem in one way or another, and do so with some measure of security remaining in place.
Last weekend, though, while browsing the Macworld forums, I came across a post that contained an amazingly easy alternative solution -- one that inspired one of those "D'oh! Why didn't I think of that?" reactions. On the machine that you want to use as the shared file server (it could be a standalone Mac, or even another user's Mac, if the group is small and the workload not too heavy), create a new non-adminstrative account (name it Workgroup or whatever). Login to the new account, and create the folder structure you'd like the users to see, and copy any files to the server that the users will need to access.
As the last step, share the login name and password for that account with the users in the workgroup. Set up each member of the workgroup to connect to the shared Mac using the special shared account, and you won't have any permissions issues at all -- since everyone will be logged in as the same user, everyone will be able to create, delete, and modify files at will.
There are obviously some downsides to this method. There's no ability to see which files and folders were created or modified by which users. If someone leaves the group, you'll probably want to change the account's password, which will require redoing the connections for the other users. You can't implement fine levels of control over which workgroup users can modify which files and folders. I'm sure there are more downsides, but for a workgroup with simple sharing needs, this solution should work just fine. Or have I overlooked some major issue that would prevent this from being a viable simple file server solution?
Due to the fact that both of my laptops (iBook G4, 15" AlBook) will only recognize my Nokia 6120 Classic's HSDPA modem through one of their two USB ports (note 1), and because of an odd technical issue with the other USB port (note 2), I have to unplug my external USB hard drive whenever I want to browse the internet. Seeing as my iTunes library is stored on the external drive, it means cutting off my music.
But then I remembered: my iBook, which I use for travelling, has a full and complete copy of my entire iTunes library. Why don't I share it? The only wireless system in common between my two Macs is Airport Extreme, so I decided to use that.
In the following list, the provided values are settings I use, provided as an example. Modify to suit your needs.
Create a Computer-to-Computer (Ad-Hoc) WiFi Network between the host and client. If you don't know how to do this, search Apple's Help Viewer for the phrase Communicating with other computers wirelessly; I recommend using WEP (at least), with a 128-bit password. I named my network Mac Exchange.
Manually assign a network address to AirPort on the host computer. I used 10.0.0.1 for the IP address, and 255.255.255.0 for the subnet mask.
Manually assign a network address to AirPort on the client computer. I used 10.0.0.2 for the IP address, and 255.255.255.0 for the subnet mask.
Launch iTunes on the host computer and make sure that Share Library is enabled. Given the ubiquity of iTunes these days, and therefore for performance reasons, I password protected the Shared Library on the host side.
Launch iTunes on the client, and make sure it is set to search for shared libraries.
That's it. The Shared Library should appear in iTunes' Sidebar.
Note 1: Due, I'm sure, to a situation confirmed in this ZDnet report (only read the comments if you're unlikely to be incensed by some Mac-bashing, however).
Note 2: For some reason, my powered external hub (through which I connect my external drive) consistently shorts-out the right-side USB port on my AlBook, so I have to use the left-side port -- by Sod's Law, also the only port my phone's modem works through.
I'm using a D-Link DWL-G122 in versions C1 (and own a version B1, a D-Link DWL-122, a Linksys@Home 54g USB, and a Belkin F5D6050 USB -- insert sarcasm here), and have worked with (too) many similar Ralink or Prism-based USB wi-fi adapters on OS X over the last four years or so. One issue I experienced (with all of these adapters) was when the adapter was either under heavy load, or (especially) when using Internet Sharing in OS X, the adapter would randomly disconnect from its wireless network and lose all communication with the driver/config software. To fix things, it would require an unplug/replug to resume operation. With many people reporting this on the net, and having tried every suggestion I could find, I have finally found the answer that has since worked solid for over three weeks (and over 150gb of transfer) now without a single disconnection with any of my adapters!
Just for good measure, I tried (and failed) with these solutions:
A wide selection of Mac OS versions/subversions, Mac hardware, USB ports, etc.
All variations of network encryption options.
Running every version of driver software (D-Link as well as Ralink) I could find.
Many different USB extension cables, as well as without extension cables.
Powered hubs - No luck, although this did make things notedly quicker and is highly recommended especially if you are using a G4 PowerBook as their USB power is pathetically unstable.
Beyond that, I tried probably everything else you can think of, but still, the problem persisted.
This is a hint to avoid a potential security issue caused by a standard system function (or feature). If you connect to a service on a remote server, you will be asked for your login and password. If you say No to the 'Remember this password in my keychain' dialog, you may wonder why you will not be asked for your login and password next time you connect to the service.
In my case, I wanted show a remote service like VNC to a colleague while he was logged in on the local machine. I disconnected from the service and was able to connect to it again without being prompted for my login and password. This can be a security issue for many reasons, e.g. working on someone else's account etc.
Solution: To prevent reconnecting without a password, you need to delete the Kerberos Ticket that was created while connecting to the service the first time. This ticket expires after a certain amount of time (10 hours by default), but I guess a ticket that grants access for 10 hours is not what most people expect when telling the system not to remember their login/password for the service. At the least, I'd expect to see a warning about the 10-hour ticket being created.
To delete the ticket, open Keychain Access (in the Applications » Utilities folder) and choose Keychain Access » Kerberos Ticket Viewer from the menu. (The viewer is a actually a separate application, located in /System » Library » CoreServices.). In the viewer, delete the listed ticket associated with the service. By the way, the Kerberos Ticket Viewer program has many preferences, e.g. to set the default time of 10 hours to less, that you can set in the program's Preferences screen.
MacFUSE is a great addition to the OS X system. One common usage of a FUSE is to mount a remote directory as a local volume, for easy access, and with MacFUSE in conjunction with sshfs (available at the same link), this is really easy to do.
In my situation, however, the remote directory that I wanted to access was on a firewalled server that only allowed access through other machines on the some local network. I had access to various gateway machines, so access as such was not a problem, but it was a pain to have to hop through the gateway each time I need to transfer files to the firewalled server. Also, I could not use local applications to work on directly on files on the server, even if they supported ssh- and sftp-based editing.
I messed around with trying to set up an ssh tunnel, but got nowhere. When I finally turned to MacFUSE as an alterntive, I had everything set up and running within minutes.
Here's a three-step process to create a Time Machine backup on a network-attached storage (NAS) unit.
Create a sparsebundle image on your local system. I'm not sure of the reason why, but I haven't been able to kick Time Machine off just by specifying a network share. It "prepares" for a while, then says it was unable to create the disk image. The solution appears to be to create a sparsebundle image locally. Thankfully, you don't need multiple Macs like another post suggested; you can accomplish this using hdiutil like so:
Where $SIZESPEC is the size of the backup volume, and $MACHINENAME_$MAC_ADRESS is your Mac's name followed by an underscore and then your Mac's MAC Address (otherwise known as its Ethernet ID; visible in the Network System Preferences panel), but without the colons. So if your Mac is named MyMac, and the Network System Preferences panel lists your Ethernet ID as 00:18:b3:11:84:dd, then you would use MyMac_0018b31184dd for the name of the sparsebundle.
The -size parameter can probably be as large as you want, now that Apple has evidently fixed the sparsebundle issues that were causing all but the most recent backup to be dumped. However, you can also specify a smaller size if you (like me) want to create a hard limit for the amount of space your Time Machine backups will take on your network drive. hdiutil does have a -resize option if you need to utilize that later.
Create and set permissions on your network share. Just make sure you have read/write permissions set on whichever SMB/AFP share you're going to dump this to.
Copy the sparsebundle to the network share root. Easy enough. Mount your network share and copy it over. I used this Terminal command after the MyBackup share was mounted: cp -r mymachine_0017f2c8426b.sparsebundle /Volumes/MyBackup/.
By this point, you should be good to go! Make sure you have read/write permissions on the network share, and that you've run the infamous defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1. Now just change your Time Machine disk to that network share, and you're off!
Last night, I was setting up password-free SSH connections (using, basically, the information in this ancient hint) between my machines here in the house -- at some point during all the 10.5 upgrading, I'd broken it between a couple of the boxes. Everything worked fine on the mini and the MacBook Pro, and when connecting from the Mac Pro to the other machines. Connecting to the Mac Pro, however, still required entering my password. I double and triple checked everything with the key files, tried RSA and DSA keys, and ran ssh in triple-debug (-vvv) mode. Nothing was any help at all.
Turning to Google, I (ironically) found the solution right here on our own forum site -- in a thread that had been updated with the solution only a couple days ago. In a nutshell, the problem was that the permissions on my user's folder on the Mac Pro were incorrect (and Repair Permissions in Disk Utility didn't fix them). In Terminal, I ran the first of the three commands shown in the thread (as only my top-level user's folder had incorrect permissions)
Once the permissions were fixed, ssh worked as expected. But the real hint in the forum thread wasn't the actual fix; it was a tidbit on how to diagnose the problem in the first place -- one that may be useful for other sorts of ssh connectivity issues as well.
By default, the AirPort Utility only allows several 802.11n radio mode options as shown in this screenshot -- basically four different 802.11n modes: b/g compatible, 2.4GHz, 802.11a compatible, and 5GHz. To get four more options (b/g/a only, without n), just hold down the Option key while clicking on the Radio Mode drop-down menu in Airport Utility's Wireless tab. You should see a list of options just like this one.
This is documented in Apple's current Designing AirPort Networks PDF, but is somewhat hidden in the middle of the document as a side note! Maybe this is of help for someone trying to create an "n-less" WLAN.
As a system admin, from time to time in Apple Remote Desktop (ARD), I find a system that is no longer showing the correct name (often the name shown is the IP address reversed ie: 22.214.171.124). This can prevent the system from being controlled or running reports for your task server.
To correct this remotely, you'll need to use one of the following two solutions -- I prefer the first method, assuming you've enabled remote login (ssh).
Open Terminal and ssh to the system in question: ssh email@example.com. Enter the admin password, and if prompted to accept the certificate, type YES then press Enter.
Type cd /Library/Prefrences and press Enter.
Type mv com.apple.ARDagent.plist com.apple.ARDagent.plist_bad and press Enter. Repeat this command with com.apple.RemoteDesktop.plist and com.apple.RemoteManagement.plist -- remember to add _bad to the end of each filename when moving it.
Type cd /Users/username/Library/Prefrences; replace username with the affected user's short username.
Type mv com.apple.internetconfig.plist com.apple.internetconfig.plist_bad. Repeat this step for com.apple.internetconfigpriv.plist and com.apple.remotedesktop.plist if they are present (remember to add the _bad bit to the filename).
If the end user is logged in, pick up the phone and call them, ask them in your nice admin voice to save their work and go get a cup of coffee. You will be force restarting the computer.
Once the user has saved his/her work, type sudo shutdown -r now and press Enter. Supply the password as needed for the admin account.
Wait two minutes for the remote system to restart, go back into Apple Remote Desktop, and rescan the IP address for the affected system. If you are still unable to remote control the system, go to the next, less secure method for correction.