After upgrading to Leopard, whenever I would try to mount SMB shares on my company's network, the Finder would hang interminably on the "Connecting to Server" progress dialog (the network is Active Directory-based).
My password, like many that of many people, contains some extended characters. Today I tried URI-escaping the password, and it worked! I was able to connect immediately to all shares. To URI escape a password, try the following:
When you select a server or shared computer in a 10.5 Finder window, a button appears saying Connect as. This allows you to enter a username and password for the server you are trying connect to. Under 10.4, in the case of Windows servers, this dialog also has a text field that allows you to enter the domain your username belongs to. Under 10.5, this text field is missing.
The solution is simple: enter the domain as part of the username, just as you would in the comparable Windows dialog, separating the domain from the username with a back slash ('\').
Leopard includes a fast VNC viewer for its Screen Sharing feature. You can browse other Leopard machines in the Finder and click "Screen Share..." to see their screens. You can also connect to Windows and Linux VNC servers with "Connection, New" and entering the host address.
But on Lin
ux you can go one step further. Install the Avahi software (avahi-daemon package under Debian) and create a service file in /etc/avahi/services/vnc.service, with these contents:
Earlier today, while testing another 10.5 hint (not yet published), I ran into something that's quite disconcerting, and could potentially lead to some lost data, if not just a lot of confusion. In a nutshell, here's the problem, which I've verified in both 10.4 and 10.5...
Say you've got Mac1 and Mac2, and you've connected to Mac2 from Mac1. There's a folder on Mac2 that you use regularly, so you make an alias to it in your Hot Stuff folder in Mac1's Documents folder. To make accessing it easier, you then do the obvious thing, and drag it into your sidebar. But you want to know that folder's on your remote Mac, so you control-click on it in the sidebar and choose the Rename option from the pop-up menu. You rename Projects to Projects - Mac2. When you do that, you've just renamed the actualProjects folder on Mac2 to Projects - Mac2!
The entry in the sidebar is, basically, a direct connection to the remote folder, not a representation of the local alias you created. And while my example is relatively harmless, consider if I had instead created an alias to my user's Library folder on the other Mac; rename that, and you'll find all your settings missing on Mac2 (as the system will create a new Library folder for you as soon as it needs to work with it again). They haven't been deleted, but you'll be quite confused for a while, to say the least.
I made a (somewhat confusing) movie of this process, just to demonstrate how it works. Basically, what you'll see is the creation (on the desktop) of an alias from a folder on another Mac, the renaming of that alias folder on the desktop (which works as expected), and then what happens when that folder is moved to the sidebar and (again) renamed.
In short, the sidebar does not treat local aliases properly at all. As soon as you move the alias to the sidebar, it seems as though OS X resolves the path to the original object. From that point on, any changes you make to the filename of the folder are actually made to the original file. This is not at all what I would expect to happen, and it's not what happens with the alias in the Finder. When you rename an alias in the Finder, that name change is local; the parent folder on the remote Mac isn't touched. A local alias in the sidebar shouldn't behave any differently than a local alias in a Finder window. (Things are a bit different if you create an entry directly in the sidebar, by dragging from the remote volume to the sidebar -- I'm not sure how that should work.)
So be aware, if you're using the sidebar to store local aliases of networked folders, do not try to rename those folders in the sidebar (unless you really want the original folder renamed).
NetInfo Manager disappeared in OS X 10.5, along with all my automount SMB shares from my Buffalo Linkstation. After poking around the net for documentation on the unix automounter, I came up with this solution to get my automounts going again:
According to /etc/auto_master, the /etc/fstab file is now used to dynamically mount shares under /Network/Servers. So you basically just need to transfer the stuff you used to have under Mounts in NetInfo Manager to your /etc/fstab file; mine looks like this:
excalibur:/music x url net,automounted,url==cifs://guest:@excalibur/music 0 0
excalibur:/photos x url net,automounted,url==cifs://guest:@excalibur/photos 0 0
excalibur:/videos x url net,automounted,url==cifs://guest:@excalibur/videos 0 0
Translating, the above shows that I have three Samba shares called music, photos, and videos. They are all on a server called excalibur, and i'm accessing them using the username guest with no password. The second item in the command is x for each line. That's generally the mount point, but because of the way the automounter is configured, that entry is ignored. The mounts will always be placed in /Network/Servers.
Leopard's screen sharing uses the standard VNC protocol, and so it is possible to use it to share screens with other non-Leopard systems. I run the VINE Server on my older 10.4 Mac, and it appears in my Finder under Shared, allowing me to click the Share Screen button to bring up its screen.
This may only work with the VINE Server because it supports Bonjour. It would be interesting to know if there's a way to get Windows PCs running a VNC server to show up.
The Windows workgroup that the mac uses is now set in the Network System Preferences pane by clicking the pop-up menu next to the Location combo-box and selecting Edit Locations. You can then add a new location with the name of your desired workgroup.
Once this is done, click the Advanced button and then select the WINS tab. From here, you can now select your workgroup from the drop-down menu.
Option-clicking on certain icons on the right side of the menu bar provides additional technical information.
As noted in this hint, for example, you can easily see more detailed Bluetooth information. What's new in 10.5, though, is detailed information in the AirPort menu item. Clicking on the AirPort signal icon in the menu bar normally shows only the network name and whether it's secure or not.
By Option-clicking, you can also see the AirPort's MAC address, channel, signal strength (RSSI), and transmit rate, as seen in the image at right. With this new feature, the AirPort signal menu bar icon is useful when setting up or troubleshooting a wireless connection.
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.]