MacFUSE is a great addition to the OS X system. One common usage of a FUSE is to mount a remote directory as a local volume, for easy access, and with MacFUSE in conjunction with sshfs (available at the same link), this is really easy to do.
In my situation, however, the remote directory that I wanted to access was on a firewalled server that only allowed access through other machines on the some local network. I had access to various gateway machines, so access as such was not a problem, but it was a pain to have to hop through the gateway each time I need to transfer files to the firewalled server. Also, I could not use local applications to work on directly on files on the server, even if they supported ssh- and sftp-based editing.
I messed around with trying to set up an ssh tunnel, but got nowhere. When I finally turned to MacFUSE as an alterntive, I had everything set up and running within minutes.
Here's a three-step process to create a Time Machine backup on a network-attached storage (NAS) unit.
Create a sparsebundle image on your local system. I'm not sure of the reason why, but I haven't been able to kick Time Machine off just by specifying a network share. It "prepares" for a while, then says it was unable to create the disk image. The solution appears to be to create a sparsebundle image locally. Thankfully, you don't need multiple Macs like another post suggested; you can accomplish this using hdiutil like so:
Where $SIZESPEC is the size of the backup volume, and $MACHINENAME_$MAC_ADRESS is your Mac's name followed by an underscore and then your Mac's MAC Address (otherwise known as its Ethernet ID; visible in the Network System Preferences panel), but without the colons. So if your Mac is named MyMac, and the Network System Preferences panel lists your Ethernet ID as 00:18:b3:11:84:dd, then you would use MyMac_0018b31184dd for the name of the sparsebundle.
The -size parameter can probably be as large as you want, now that Apple has evidently fixed the sparsebundle issues that were causing all but the most recent backup to be dumped. However, you can also specify a smaller size if you (like me) want to create a hard limit for the amount of space your Time Machine backups will take on your network drive. hdiutil does have a -resize option if you need to utilize that later.
Create and set permissions on your network share. Just make sure you have read/write permissions set on whichever SMB/AFP share you're going to dump this to.
Copy the sparsebundle to the network share root. Easy enough. Mount your network share and copy it over. I used this Terminal command after the MyBackup share was mounted: cp -r mymachine_0017f2c8426b.sparsebundle /Volumes/MyBackup/.
By this point, you should be good to go! Make sure you have read/write permissions on the network share, and that you've run the infamous defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1. Now just change your Time Machine disk to that network share, and you're off!
Last night, I was setting up password-free SSH connections (using, basically, the information in this ancient hint) between my machines here in the house -- at some point during all the 10.5 upgrading, I'd broken it between a couple of the boxes. Everything worked fine on the mini and the MacBook Pro, and when connecting from the Mac Pro to the other machines. Connecting to the Mac Pro, however, still required entering my password. I double and triple checked everything with the key files, tried RSA and DSA keys, and ran ssh in triple-debug (-vvv) mode. Nothing was any help at all.
Turning to Google, I (ironically) found the solution right here on our own forum site -- in a thread that had been updated with the solution only a couple days ago. In a nutshell, the problem was that the permissions on my user's folder on the Mac Pro were incorrect (and Repair Permissions in Disk Utility didn't fix them). In Terminal, I ran the first of the three commands shown in the thread (as only my top-level user's folder had incorrect permissions)
Once the permissions were fixed, ssh worked as expected. But the real hint in the forum thread wasn't the actual fix; it was a tidbit on how to diagnose the problem in the first place -- one that may be useful for other sorts of ssh connectivity issues as well.
By default, the AirPort Utility only allows several 802.11n radio mode options as shown in this screenshot -- basically four different 802.11n modes: b/g compatible, 2.4GHz, 802.11a compatible, and 5GHz. To get four more options (b/g/a only, without n), just hold down the Option key while clicking on the Radio Mode drop-down menu in Airport Utility's Wireless tab. You should see a list of options just like this one.
This is documented in Apple's current Designing AirPort Networks PDF, but is somewhat hidden in the middle of the document as a side note! Maybe this is of help for someone trying to create an "n-less" WLAN.
As a system admin, from time to time in Apple Remote Desktop (ARD), I find a system that is no longer showing the correct name (often the name shown is the IP address reversed ie: 22.214.171.124). This can prevent the system from being controlled or running reports for your task server.
To correct this remotely, you'll need to use one of the following two solutions -- I prefer the first method, assuming you've enabled remote login (ssh).
Open Terminal and ssh to the system in question: ssh firstname.lastname@example.org. Enter the admin password, and if prompted to accept the certificate, type YES then press Enter.
Type cd /Library/Prefrences and press Enter.
Type mv com.apple.ARDagent.plist com.apple.ARDagent.plist_bad and press Enter. Repeat this command with com.apple.RemoteDesktop.plist and com.apple.RemoteManagement.plist -- remember to add _bad to the end of each filename when moving it.
Type cd /Users/username/Library/Prefrences; replace username with the affected user's short username.
Type mv com.apple.internetconfig.plist com.apple.internetconfig.plist_bad. Repeat this step for com.apple.internetconfigpriv.plist and com.apple.remotedesktop.plist if they are present (remember to add the _bad bit to the filename).
If the end user is logged in, pick up the phone and call them, ask them in your nice admin voice to save their work and go get a cup of coffee. You will be force restarting the computer.
Once the user has saved his/her work, type sudo shutdown -r now and press Enter. Supply the password as needed for the admin account.
Wait two minutes for the remote system to restart, go back into Apple Remote Desktop, and rescan the IP address for the affected system. If you are still unable to remote control the system, go to the next, less secure method for correction.
If you've ever wanted to copy an Apple Remote Desktop setup from one machine to another, you need to move a number of files. Open Terminal, and run the following commands -- modify the username and machinename settings as necessary for your environment. Note that the lines that start with ### are explanatory; don't type those...
A mobile user account can take forever to login if you are at a different location, but have an internet connection. To login a mobile account, OS X will first try to connect the Open Directory server. If you have a domain search list in your network preferences that lists your company's domain, this can cause long timeouts.
To fix this, remove the company's domain from the DNS search list, and ask your company's administrators if they can specify this as a DHCP parameter.
As we all know by now, with the 7.3.1 firmware update to the AirPort Extreme (802.11n) Base Station, we finally get decent read/write performance from attached disks. The pre-7.3.1 firmware was buggy and slow, but the new firmware rocks, and AirDisks are finally ready for prime time (as well as supporting Time Machine -- yay!).
One of the energy/disk saving features of the new base station firmware is that it will spin down attached drives if they have not been accessed in approximately 10 minutes. This is good for saving a couple of watts of power, as well as prolonging the life of a hard drive. If a drive is used as a Time Machine volume, the delay in waiting for the drive to spin up and be accessible is quite acceptable.
However, if the drive is being used as a network share for data (in my case, iTunes media and archival data), the five to ten second delay caused by spinning up is not acceptable (at least to me). And since there's no parameter to disable disk sleeping on the AirPort, I wrote a trivial program and launchd plist file to "tickle" the disk every few minutes to keep it spinning (and just that one disk - I have two other USB disks attached to that basestation that are for Time Machine, and I do want them to spin down).
When mounting an SMB share from a Windows 2003 server, I ran into the problem that after about five minutes, the share would disconnect and I would not be able to reconnect to it at all. My system log would say things like this:
KernelEventAgent24 tid 00000000 received VQ_NOTRESP event (1)
KernelEventAgent24 tid 00000000 type 'smbfs', mounted on '/Volumes/xxxx', from '//xxxx;email@example.com/xxx$', not responding
KernelEventAgent24 tid 00000000 found 1 filesystem(s) with problem(s)
loginwindow23 1 server now unresponsive
kernel smb_iod_reconnect: The reconnect failed to xxx.xxx.xxx.xxx! error = 4
I found a solution, after trying many other things. It is probably due to a bug in the network software of Apple or the server. I use a laptop which normally uses a wired connection with fixed IP as a first choice, but there is wireless connection in the building, too, and my laptop pulls an IP number from the DHCP server at the same time via AirPort.
The Airport connection is (normally) not doing anything, as all the traffic goes over the wired Ethernet connection. Apparently after five minutes of inactivity, the Windows server goes on standby, and when my Mac tries to reconnect, it starts using the wireless connection to talk to the server and then fails to reconnect, as the laptop is still using the wired Ethernet for all its network traffic.
The solution is to turn off AirPort when using a wired ethernet connection. By turning off AirPort, my SMB share stays connected and the problem does not happen. Apparently having an IP address for the wired Ethernet connection plus an IP for AirPort messes up the SMB connection. I just have to remember to turn AirPort back on when the wired connection is not available (like at home or elsewhere in my building). This could probably be automated with a launchd script that disables AirPort when Ethernet is available, and enables AirPort when it's not ... any takers?
Using ext3-formatted disks to create file-based iSCSI targets have one major drawback: They can only be read by another Linux machine with iSCSI. But what about attaching a pre-formatted drive as target?
Take a suitable Linux distro (eg. CentOS 5.1; it needs to have support for the Apple partition type in the kernel!) and install iSCSI Enterprise Linux (latest stable seems to run fine with Leopard). Attach the Mac-formatted drive to the machine, but do not mount it (you may if the distro has HFS+ support, but you don't need to). Let assume it's an external SCSI-RAID (or Firewire, USB) and is /dev/sda. You then create, in ietd.conf, a new target:
Depending on your server's hardware, a Type=fileio may give a better performance; you can simply try both out.
/dev/sda3 is the third Mac partition on the drive; you may have to find out which partition number is the correct one. Depending on the number of drivers (like for OS 9 support), it may vary up to sda5 or higher. Some versions of fdisk on Linux support Apple partition shemes, some not, but it might be a way to find out the right one. If your target is later mounted on the Mac and is unreadable and has only 48k ... then it's the wrong one.
Install an iSCSI initiator (Atto, Small Tree or the free globalSAN from SNS) on your Mac and connect to the target. It mounts fine and can be used just like a local disk. And if the server is down, take it back to any Mac with SCSI -- it's good to have the choice. A backup running on the Linux server itself may not be able to do a local backup -- or you can trust the HFS+ driver and mount the drive read-only.
Beware: iSCSI is quite new and many people had/have problems using it, but a drive shared like this can be used for TimeMachine.