One of the differences between Tiger and Leopard is that the former had an Options action in the login pane that allowed users to choose to connect to AFP shares with clear text (unencrypted) passwords. This option is missing from the Leopard AFP connection pane.
Unfortunately, many Appleshare servers only support clear text passwords -- for instance, the Qnap TS-109 NAS, which has an implementation of netatalk built in to it. Luckily, until the server supports connections with encrypted passwords, it is possible to configure Leopard to support clear text passwords.
To do so, disconnect from any AFP shares you are using, then navigate to ~/Library » Preferences » com.apple.AppleShareClient.plist. Double-click on the file to open the Property List Editor, which is part of the Developer Tools (the editor from the 10.4 tools works fine). Then just change the values of the keys afp_cleartext_allow and afp_cleartext_warn to Yes from their default value of No. Close the file, restart, and the next time you connect to an Appleshare server that only supports unencrypted passwords, you'll be able to do so.
It is also possible to edit these keys using the defaults system. The commands to do that, in Terminal, are:
If you're tired of typing in the same computer name over and over in the Finder's Screen Sharing window, create a shortcut. The easiest way I found was start Safari, type vnc://servername, and then drag the shortcut to your desktop or wherever. Add the server to your keychain, and you have a one-step screen sharing session.
Final tidbit: Screen Sharing will connect to machines that have been shared via Apple Remote Desktop sessions.
[robg adds: This hint is a sort-of corollary to this one.]
Setting up NFS exports under Leopard is insanely easy: just add an entry to (or more usually, create) /etc/exports, and it gets picked up automatically. This file survives reboots, as well; pretty cool.
Here's an example:
muse:~ root# cat /etc/exports
/Volumes/BigDisk/Panic -maproot=netroot 10.0.1.1
muse:~ root# showmount -e
Exports list on localhost:
When you connect to another Mac (or other device) using AFP, did you know you can control what shows up in the Name field? By default, OS X will populate your full user name, but you can change this via some hidden preferences.
For instance, to make the dialog show your short username instead, do this in Terminal:
Last weekend I had to connect via VNC/Apple Remote Desktop to the MacBook that manages my mother's business from a PC. This was complicated by the fact that we were both behind NAT routers in different regions of the country.
This hint provided a good start. Unfortunately, I did not have the luxury of advanced setup and all of my machines run Windows XP. These instructions require a slight short-term reduction in the security of your PC; use at your own risk. These steps are quick-and-dirty, some refinements are certainly possible.
I've got my mini hooked up in one room to a TV. It doesn't really have easy access to a keyboard and mouse, but it is connected to a huge external hard drive that I store all sorts of files on. So sometimes, when the mini is asleep I need at the files. Searching on Google for "wake mac on lan" took me to this older hint, which hasn't had much action lately.
After trying the hints on that page, the problem was that after waking the mini, I would still have a terminal window open. Now there may be away around that, but I couldn't find one. So I took the information I learned there and plugged it into an Automator workflow, using the Automator: Run Shell Script action. The Shell should be /usr/bin/python, the Pass input should be to stdin, and the body of the script should be:
You will have to replace the 00, 11, 22, 33, 44, 5a with your own mac address, of course -- you can find this in the Network System Preferences panel.
Then save the Automator action as an application or a Finder plug-in. When it is run, there is no Terminal window. (I saved mine as an application, changed the icon to a picture of a mini, and now I have an icon in my dock that, when clicked, wakes my mini in the other room).
I was playing around with making SSH access to a remote machine as easy as possible for my other half. Initially, I generated a key pair using ssh-keygen and installed the public key on the server as usual, put the private key in a folder with a .command (double-clickable shell script for Finder) script like the following:
# chimpy.command - Logs user bob into chimpy using private
# key bob.dsa
ssh -i ./bob.dsa email@example.com
Alas, that did not work as the .command file sets the current working directory to the user's home directory, not the directory it was executed from. Annoying. But then I realized that as the key is actually a text file, so why not make the key itself an executable script?
Disclaimer: The following is a highly technical hint.
Summary: This hint is for Network Engineers who want their firewalls to accept VPN connections from standard OS X L2TP / IPSec clients (should also work for Windows and Linux clients). If you are not a network engineer, but are having trouble connecting to one of these devices, you can also forward this tip to your company's "firewall person," so that they can fix it.
Problem: A Cisco ASA or PIX firewall can be a VPN server, but a basic VPN configuration will not allow the default OS X L2TP/IPSec client to connect, even though the Cisco client will. It may not be convenient to distribute the Cisco VPN clients, or your users may not wish to use them.
Recently, my company implemented a new Exchange 2007 server for our email. No special changes or accommodations were made to support OS X. After a bit of searching and trial and error, I figured out the settings for Entourage to work when connected to the corporate network: email, contacts, and calendar all work.
I started with version 11.3.6 (070618) of Entourage, and added a new Exchange email account. I then tried the automatic setup, but it failed so I went into manual mode. During the setup, i found two fields that require surprising entries:
Under the Account Settings tab, the Exchange Server field. Here is what works for me:
Many users have problems mounting shares from Windows 2003 Servers from OS X Tiger (10.4 - 10.4.10) clients. The following solution has been tested in our enterprise where we have W2K3 servers, physical as well as virtual, and some within a SAN.
Problem: From the network view in OS X, we could browse to the servers, but when we tried to connect, we would get the Delete/Fix Alias error. When connecting from the Finder with Command-K (either with smb://servername, smb://ip.address, smb://servername.fqdn, cifs://servername, etc.), we would get the dreaded Error -36 and the Console would show:
mount_smbfs: session setup failed (extended security lookup2): syserr = Socket is not connected
mount_smbfs: could not login to server SERVERNAME: syserr = Socket is not connected
Using smbclient from the terminal would work fine.
Solution: After making sure that there are no Local or Domain policies interfering (NETBIOS, WINS, Kerberos, Firewalls, IRPStackSize problems, etc.), try the following.
On the server in question, in Control Panel » Network Connections, select the NIC, click on Properties, then on "File and Printer Sharing for Microsoft Networks," click on Properties and check the option for either Maximize Throughput for File Sharing or Maximize Throughput for Network Applications (depending on the use of the server). This changes the value of the REG-DWORD "Size" at HKEY_LOCAL_MACHINESYSTEM » CurrentControlSetServices » lanmanserverparameters from 1 or 2 to 3. From the command line or Services.msc, restart the "Server" service or reboot the machine. Thanks to Joel Ayala for the expert Windows perspective.