Verify file server name and zone name. See if anyone else can see it in the Chooser (may be network problems). Verify that the Web & File server is running. Verify port selected in AppleTalk control panel on both server and client.
User "guest" does not have file service enabled at Web & File server. Server administrator must allow guests to log into the file server.
If the volumes that appear in the File Server's volume list in the Chooser appear disabled or grayed out, it indicates that the user does not have any "read" privileges to the share point. Server administrator must allow users to at least "read" at the share point level, for users to mount the volume.
AppleShare IP servers with AFP over TCP enabled will attempt an IP connection whenever the client and the server are configured for TCP/IP. Occasionally, although both client and server are configured for IP, there is no IP connectivity between them. (This might happen is there were no IP router between the client's network and the server's network.). In these cases, try to force an AppleTalk connection, instead of allowing the software to attempt an IP connection. See next step for details.
AppleShare client software 3.7 and above will attempt to make an IP connection to the AppleShare IP server whenever this feature has been enabled at the server, and the client is also configured for TCP/IP. To prevent this, and force an AppleTalk connection:
Open Chooser. Select AT zone of file server (if on a zoned network) Select AppleShare Client icon in upper-left quadrant of the Chooser. Hold down the Option-Key when selecting the file server's name in the upper-right quadrant of the Chooser.
Try this whenever you see a "server not responding" message, as indicated in the question above.
If the client's connection is made via AppleTalk instead of TCP/IP (this should be done behind the scenes if everything is set up right), check the following:
This problem is currently under investigation at Apple. The symptom is that the client stops responding when attempting to log into the server, just at the point where the server volumes are expected to mount. Force-quitting the Chooser sometimes allows the client to continue. Many have reported that this issue does not affect the administrator user, only other registered users.
Workaround: Disable the "Remember Recent" feature of Apple Menu Options control panel. (Changing values to "0" is not sufficient, the feature must be turned off).
Whenever clients report issues accessing IP services, it's good practice to verify IP connectivity at the client and at the server. Even if the client connected successfully in the past, many different things could cause unsuccessful attempts at any time, such as:
Testing IP connectivity is often done using utilities that send ping packets. Ping packets are simply small packets from one host to another, that request a response from the recipient. Many ping utilities are available for free download on the Internet. One favorite is MacTCP Watcher. Some sort of ping utility is invaluable when troubleshooting IP connections, and the following suggestions are assuming that some ping utility is available.
If no ping utility is available, then use whatever IP applications are at hand, the simpler the better. Remember that the device you're attempting to contact has to support the service that the client software is trying to reach. For example, you may be able to use a Web browser to test a connection with another computer that has Personal Web Sharing enabled, but you can't use it to test a connection to your router.
Here's a suggested troubleshooting path for isolating issues with a client trying to connect to the host.
2. Ping device on local subnet using IP address.
Pinging a device on your same subnet using its IP address does not require routers or DNS servers to be successful, so it verifies that each machine is able to communicate, at least on its own subnet, using TCP/IP.
Note: Be sure that the workstation you are attempting to ping has its IP stack (i.e., protocol set) initialized. Most Macintosh computers do not initialize the IP stack until an application that uses IP is launched. On the computer you'll be pinging, launch an IP application, such as the Web browser or a ping utility, to initialize the stack before attempting the ping.
You can determine which other devices are on the same subnet by checking the physical connections (are they connected to the same hub? or same bus?) or by checking their IP addresses (are the network portions of the IP addresses identical? You have to consider the IP address AND the subnet mask to determine this).
If pinging a device on the same subnet is successful, you've verified that the computer's IP connections are working, but there still may be some issue with external network devices, such as routers, DNS servers. Continue on with the next step.
If pinging a device on the same subnet fails, then you need to check carefully the local software and hardware configurations. Here's some tips on how to do that:
3. See if any other device on same subnet can ping other devices. This will let you know if the local network is functioning, and if basically the IP addresses have been set up correctly.
4. If server addressing is being used, see if you can test with a manual address, to see if problem is with communications between the client and address server.
5. Check TCP/IP configurations carefully; compare them with that of a computer that is working properly: verify link being used, IP address, subnet mask, and router information, whether "802.3" is checked (Advanced mode).
6. Check network connections to make sure they're not loose.
7. Swap out non-working hardware with a working machine to test AppleTalk on the same link if possible.