After upgrading to Leopard, I found I was unable to mount any of the shares on my Linux file server, getting the following error:
The operation cannot be completed because one or more required items cannot be found.
(Error code -43)
At first I thought this was because of the security configuration I was using on the file server, or perhaps because Leopard had changed the type of authentication method it was expecing from an SMB file server (NTLMv2 for example). It turns out it was a lot simpler -- it was because all of the shares on the file server were set as non-browseable (Browseable = No in /etc/smb.conf. Changing at least one share to be browseable corrected the issue and let me connect to the file server and mount the shares available, regardless of if they were set as Browseable or not.
It should be noted that if you connect to any windows servers, then you will not notice this issue as the default shares for drives (c$, d$, etc) are browseable, but most SMB client implementations will 'hide' them from the end user.
I had been having some problems dealing with Leopard's Screen Sharing feature -- I wasn't able to remotely connect, no matter which ports I opened or prefs I turned on, using a machine from my job running 10.4.
I was attempting to connect with Chicken of the VNC (CotVNC), and according to a few articles across the web, it should have worked flawlessly. It certainly did on my network at home, so I wasn't sure what I was doing wrong. I even DMZ'd my machine at home -- still, nada.
Then I was playing around with the Profiles options in CotVNC, and there's a setting where you can change the resolution of the window on the client's end. The choices are 256 colors, Thousands, Millions, and Let Server Decide. I always had it set to 256 at work, because I was more interested in speed than how pretty my desktop looked from afar. However, I checked out my settings at home and I had the Let Server Decide option selected.
Aha -- I was on to something. I got to work this morning, changed the resolution in the profile settings to Thousands, and sure enough, CotVNC works like a charm again. It also worked fine with Let Server Decide. 256 colors worked perfectly with Tiger, but I'm guessing there's something with Leopard's built-in screen sharing that's not allowing a VNC client to connect at that low of a resolution. Just thought I'd share my findings for anyone possibly having the same difficulties.
For .mac users, the iDisk is fantastic for keeping a folder synchronized between multiple computers. One can turn on local syncing of the iDisk to have hard drive speed access to this folder shared between multiple machines, which is great. I do almost all my document editing on the iDisk and it is the same everywhere I go. For those who do a lot of document editing, doing some form of version control would be great. Time Machine is perfect for this, as subversion is kind of overkill for documents and small projects.
However, there is a problem with using Time Machine on the iDisk in Leopard: the iDisk in Leopard is not locally synchronized on a file to file basis. The local copy exists as a .sparsebundle file in ~/Library/FileSync. This is done so that the local copy only occupies the same amount of space as the files you currently have in your iDisk. Tiger on the other hand would just take up the full 10GB on your hard drive if that is how much space was allocated for your iDisk. This .sparsebundle looks like one giant file, but it is actually a package which contains a whole bunch of 8MB bands.
Time machine does not let you look at your iDisk back in time, but this sparsebundle is backed up, so in principal one could go back in time and recover a previous iDisk. But one could only recover the entire previous contents of the iDisk rather than individual files on the iDisk. (Note here that if you change an individual file on the iDisk, Time Machine will only backup the bands which have changed, which are at most 8MB, rather than the entire iDisk).
However, this does not help with recovering a single file from the past from the iDisk. There is a hack to do this however.
My iMac G4 800 MHz Flatpanel does not have an original (and now practically unobtainable) AirPort card. Even if you find one for 100 euro or more, and it turtns out not to be a scam, you still only have 802.11b, not g, wireless. That is a problem! Here's the fix. I purchased a Belkin Wireless G Gaming adapter (F5D7330). The adapter is hooked up to the UTP ethernet port and it draws power from a USB cable (of which it has two, but one is enough). So you do not need the power adapter, and there are no net cables involved.
This has allowed me to connect to my AirPort Express router. It feels great making an 802.11g connection with a machine that is deemed not AirPort Extreme Ready.
Of course, I want to secure my network. I can set up my Base Station using the AirPort Assistant, but how do I setup the adapter correspondingly? AirPort software only works with the original unobtainable AirPort card. After I tried everything else, I read the manual. Go to System Preferences » Network » Configure and switch to manual IPv4 (or set it up as a new location). Type 192.168.2.220 for the IP address, etc. Follow the instructions in the manual which are intended for Windows. Use the reset buttons on your Base Station and adapter in case things do not work out; even unplugging the USB may be required. Success!
[robg adds: Note that this is not really a portable solution in terms of size; it's more like a typical wireless router, not a cardbus solution.]
OS X 10.5's screen sharing feature works nicely on local networks. But to control your computer over an internet connection is easy, too.
Use SSH to establish a tunnel to the computer you want to control. Be sure to use a local port other than 5900 -- otherwise the screen sharing app will complain about controlling the local screen is not possible. A good example is:
ssh -L 1202/192.168.10.10/5900
...where 1202 is the local port, and 192.168.10.10:5900 the remote destination.
Go into Safari and type in the URL vnc://localhost:1202, if you're using the local port 1202 as in the above example.
Now drag the URL to your desktop to create a link to this URL
Rename and/or change the icon for the URL link with the Get Info window.
If the tunnel is established and you click the generated link, the screen sharing app will start and show your remote computer.
[robg adds: A comment on the queue site notes "To ensure this is secure, you should ssh to the target host and forward to localhost. e.g: ssh -L 1202:localhost:5900."]
There have been several hints in the past about the contents of ARD and the networksetup command line utility. It is a very nice tool, and in OS X 10.4, it was found in /System » Library » CoreServices » Remotemanagement » ARDAgent » Contents » Support » networksetup. It is no longer there, but now instead, it is stored in /usr/sbin/networksetup.
So, if any of you were using scripts to push out network settings via ARD or a third party app like Casper, you should adjust your scripts accordingly. This change is only in Leopard, so all previoius versions of OS X can use the contents of the ARDAgent package.
So I updated our little network to 10.5, and the ability to share volumes and foelders is just great. However, I had a problem with how to enable a given group's read - write - delete - execute access to a given shared volumes: for all files that exist in that folder today, and for all files that might be created in the future. There are some hints on this problem, including cron jobs and default permission flags (umask), but none of them really worked out, especially in 10.5.
The answer lies in the advanced Access Control Entries (ACE) handling of file permissions. This involves Terminal, but Michael Watson has coded a front end for this. I asked him, and he will update the code for Leopard as soon as he finds a minute. Thus, we have to use the Terminal for now.
I've just upgraded my son's Mac Mini to 10.5, and turned on the Screen Sharing and ssh server after the initial install. In 10.4, I had long ago configured the "hidden" ARD VNC server, though alas I now find I've forgotten the password I set at that time. My son's gone to bed, but I want to play on his Mac -- what to do?
It seems that the "new" screen sharing feature is basically the same as 10.4's, and the VNC password is in the same place: /Library » Preferences » com.apple.VNCSettings.txt. The password is obfuscated by XORing it with a fixed key, so you need a little perl magic to view / set it.
[robg adds: Read on for the how-to. Please note that this isn't a security concern, as it assumes you've got ssh access to the machine in question, as well as the ability to execute root privileges on that meachine -- and if you've got both of those things, well, you've pretty much got the machine anyway.]
In 10.4, if you had a custom firewall config running, the built-in firewall configuration was greyed out in the System Preferences. Now in Leopard this is not the case ... I haven't worked out what happens when you use both configurations, built-in and custom, but here's how you get your custom firewall back:
Set the firewall option in the Security System Preferences panel to "Allow All Incoming Connections," just to make sure that the built-in settings don't conflict / interfere with your custom settings.
Create an entry in /Library/LaunchDaemons, mine is called ipfw_firewall.plist, and it looks like this. Customize to meet your needs.
If you, like me, want your separate firewall log file in /var/log, then you need to modify /etc/syslog.conf like this:
With those changes, you get your firewall logs in /var/log/ipfw.log.
The actual scripts and firewall rules here are the result of research I did on ipfw on OS X and BSD, and are the result of other people's work, for instance, Dru Lavigne. I just used their stuff and modified it to fit my requirements.
This one will definitely fall into the "the answer was so simple I'm glad nobody knows I was having the problem" category. I've read many of the posts about the disappearing WINS settings, and the inability to find Windows shares on a LAN. Here's how I got it to work.
First, your workgroup info is now in the Networking pane of System Preferences, which is most likely where it should have been in the first place. Second, if you have the default setup and attempt to change your WINS info, it will revert to default. It seems that in 10.5, the 'Automatic' location has a rigid template for WINS that cannot be changed.
So, the painfully simple solution. Make a new template, then change your WINS information so that your NetBios name is something more fitting than Macintosh, and your workgroup is ... well, your workgroup. Apply, save changes, etc. Voila!