Soon after installing the OS X 10.4.6 update, some of us discovered that some of our server volumes were suddenly locked. And some of the folders in these volumes were write locked for no apparent reason.
It didn't take someone too long to come up with a solution -- solutions can be found in Macintouch's Reader Reports, and in this thread on Apple's Discussions boards. However, those are all command line solutions.
As an alternative, here's a little AppleScript that I wrote to make it a little easier for the not-so-techie-geek-types to handle:
set theFolder to ""
set theFolder2 to ""
set theFolder to ¬
(choose folder with prompt "Select a folder to unlock:")
if theFolder is not "" then
set theFolder2 to POSIX path of theFolder
say "Unlocking selected folder."
do shell script ¬
"sudo chflags -R nouchg '" & theFolder2 ¬
& "'" with administrator privileges
I recently had to purchase a new printer, and so I took time to choose one to network. I chose an HP Deskjet 5940. The box said it was compatable with both OS X and XP, and the documentation inside claimed it could be shared on any network.
But I could not convince the iBook and the XP machine to share the printer with each other. Apple said it was the router (D-Link); D-Link said it was the printer (HP); and they said it was my AirPort!
After several weeks of research, I discovered that a Mac quirk with OS X and XP is that OS X will not recognize printer names that have special characters in them (like spaces, underscores, dashes, etc.). This little piece of information would have saved me hours and hours on the phone to the various tech support groups.
After many hours, phone calls, and profanities, I am printing wirelessly using a Linksys WPS54G Print Server. I am printing from a Powerbook G4 running Mac OSX 10.4.5 to an Epson Stylus Photo R320. Here's what worked for me:
Ensure your existing wireless network is operational, i.e. router connected/functional, and computer AirPort card turned on. Plug the Print Server power adapter into the wall outlet. Attach power input to Print Server and wait for power led to glow. Attach printer USB cable to printer input and opposing cable end to Print Server USB port. Wait for USB led and Wireless led to glow.
On your computer, open your Web browser and log into your Print Server. For this application (WPS54G), in the address bar type 192.168.0.11. A login window will appear. Leave "Log In Name" blank and in the password field, type the word admin
Once inside the Print Server, you may see your Print Server's name. It probably corresponds with the Print Server model number, in this case WPS54G (write down the name of your print server).
I was fooling around with my old Color Stylewriter 4100 printer and some LocalTalk connectors, and found how to make it print from Tiger using AppleTalk PAP (Printer Access Protocol). Presently this printer is connected to my old PowerBook 170 using LocalTalk cabling. The PB 170 is running the Apple LocalTalk Bridge (2.1), and is also on my Ethernet network. This tip should also work with any of the physical LocalTalk/Ethernet bridges (Farallon, Asante) available used on eBay and elsewhere with an AppleTalk-enabled StyleWriter.
First, with the printer and bridge computer (or device) turned on and booted up, and your Tiger machine connected to the same network (Ethernet) with AppleTalk active on Ethernet (System Preferences -> Network), open Terminal on the Tiger machine and type atlookup. Note the printer entry, and AppleTalk zone. If you have a simple network, the AppleTalk zone will probably be *.
I have two LANS, each with their own OS X Server, that need to talk to each other through a low bandwidth, secure, dedicated connection. There are various ways to do this, but I opted for using a pair of EtherBridges, which are devices that bridge over a dialup modem connection. So, each server has three ethernet cards: one for the Internet (en0), one for the LAN (en1), and one for the bridging connection between the LANs (en2). The problem was how to configure a route such that traffic for the "other" LAN goes through en2. Note that I did not want simply to bridge the two LANs into a single subnetwork. I needed each to be its own distinct subnet, but with traffic routed between them.
After a bunch of research on the problem, I concluded that the OS X GUI configuration package simply doesn't understand about any kind of routing except a single default route. The traditional BSD way to deal with this problem is to insert code into rc.local, but if I added a route command there, it had no effect or a bizarre effect. I experimented with LaunchDaemons and StartupItems, but they also had no effect or the wrong effect.
To make a long story (several days) short, the trick here is that you must use an ifconfig command in the rc.local script, even though at a later point in the process, the GUI-specified interface configuration will be done redundantly. If you do not do this, the route command will fail, because there will be no device configured for the bridging subnet.
I need to mount shares when I am connected to the main wireless connection here at home. So I wrote a quick ruby script that will do this based on your network name, and mount the shares you have listed.
Make a file called auto_mount_shares, open in a text editor.
When trying to drag a folder to a Novell File Server from the Mac hard drive, a user received the following message:
Sorry, the operation could not be completed because an unexpected error occured (Error Code -51)
After some digging, the folder was failing once it tried to copy a file that had the # symbol in its name. This was replicated using three different users. Removing the # character fixed the problem and allowed the folder to be copied.
I, like many other users, have had the mysterious "Mac OS X wants to use keychain system" dialog box after each reboot, when AirPort tried to access the wireless network for the first time, that refused to accept any known password. There have been some users out there who solved the problem by simply removing the System.keychain from /Library/Keychains/. Some other users suggested creating a new System.keychain with a known password.
I didnĀ“t feel comfortable using one of those solutions, because I had the feeling that there must be (1) a reason that there is a System.keychain, and (2) that it doesn't have a keyword that is known by the user. Digging a bit deeper into the system (BTW, I'm a designer and no programmer), I found out that the initial installation of 10.4 (and every subsequent update) contains a postflight script that will create this particular keychain. So my solution was quickly found.
You need to have admin-rights on the Mac you want to update using this hint. Then just:
Make a backup copy of your current System.keychain. In Terminal, type:
I've read a dozen hints on related topics, but haven't seen anything that deals with precisely this issue. I have an iMac at work and a PowerBook at home. I wanted to keep the two machines in sync, but without lugging the PowerBook into the office. I also wanted to do this without opening the Terminal.
My criteria meant that the obvious (but not necessarily easy) solution, rsync, was ruled out. Folks suggested rsyncX, psync, and Unison, but I was most convinced by the arguments in favor of Chronosync. Chronosync costs money, but it does exactly what I need it to: it gives me all the power and flexibility of rsync, but with a nice, polished GUI.
But Chronosync has one significant limitation: it can only sync two volumes that one can mount locally. All the Chronosync documentation (which is quite thorough, by the way) presumes that you have two locally-mounted volumes, either over a LAN or through FireWire, etc. But, you'll recall I didn't want to haul the PowerBook into the office.
I thought I'd have to drop my 'no CLI' condition and turn to rsync, but then I read this hint on a related but different topic, and found the suggestion from jctull (scroll down a bit) about how to use SSH Tunnel Manager. Thus, the solution to my problem was to do the following:
Use Tunnel Manager 2.0 to create an ssh tunnel from the PowerBook at home to the iMac at the office.
Set up Tunnel Manager (following jctull's instructions in the above hint's comments) to forward port 10548 on the powerbook to port 548 (afp) on the iMac.
Connect to localhost:10548, which mounts the iMac drive as an AFP volume on my PowerBook.
Launch Chronosync, set up the sync, and go from there!
This all seems simple enough, and is a breeze to use now that it's set up. But I was rather surprised that no one had mapped out any sort of simple instructions to sync two machines not on a LAN without using the command line. My next step would be to automate this process with an AppleScript, but as you can likely tell from above, I'm not much of a programmer. Any suggestions greatly appreciated.
I run a closed WPA2 Airport network (not out of poor neighbourliness, but due to New Zealand's backward broadband situation, with very restrictive and expensive data caps.) This is normally not an issue, my laptop identifies the network and logs on automatically, as it should. To do that, I set the Airport configuration in Network Preferences to "By Default, Join Preferred Networks," and under the Options button, "Automatically add new networks to the preferred networks list."
After recent changes to my system, I could not get it to join the network automatically. Each time, I had to type in the name of the closed network, and the WPA2 password, in order to get access. This is both a nuisance and a slightly increased security risk, so I was keen to get back to the automatic login. Everything in the network settings was apparently as before, the network was at the top of the preferred list, and I began to wonder if a recent Airport or System update (I'm on Mac OS X 10.4.5) had broken the previous functionality.
What turned out to be the problem however, was that I had changed the Airport network while trying to get a USB wireless adapter working with it. The change in the network password to a 13 character one for improved compatibility was not updated in the preferred networks list in the Network Preference Panel. So the automatic connection was still operating on a previous password. Once I manually changed it to the new one, everything operated as before. A minor issue perhaps, but the sort of thing that can be quite infuriating until you track it down.
Two previoustips addressed this issue in terms of the Keychain. This tip identifies the password issue in Network Preferences, and provides the needed fix.