Fixing can't print to shared Canon LBP 6000 in Mac OS X

In successfully installed a Canon LBP 6000 on my Mac Mini and was able to print to it.  I then turned on printer sharing and shared it.  I was able to see the shared printer listed on my Macbook Air, but when I tried to print to it over the network it would say processing for a long time, and then switch to paused.  When I checked the printer status on the Mac Mini, there was no sign that the print job had ever been received.

Long story short, it turns out that the problem occurred because I had previously connected the LBP 6000 to the Macbook Air by USB and installed the Canon CAPT driver for the printer, and for some reason this caused the Macbook Air to assume the printer was directly connected when I tried to use the remote printer.  You can see that this is happening by going to Apple->About this Mac->System Report and then looking at Printers, and then looking at the URI entry for the remote printer.  For remote printers the URI should be something sort of like this:

dnssd://LBP6000%2FLBP6018%20%40%20Zihuatanejo._ipp._tcp.local./

If a previous installation of the Canon CAPT driver on the computer you are trying to print from is causing problems the URI will look something like this:

URI: cnbma://localhost:59687

In other words, the system somehow thinks the remote printer is actually directly connected, so it tries to send the job to a local resource and it eventually times out.

What worked to resolve the problem was to delete the Canon CAPT printer driver from the Macbook Air, reboot, and then add the remote printer again.

On the computer that you are having trouble printing remotely from open Finder and select Go > Go to Folder and then type

/Library/Printers/Canon

and press Go. If you see a CUPSCAPT folder it means the Canon driver was previously installed. Delete all the CUPSCAPT folders.

Also, using Go > Go to Folder, type

/Library/Caches/Canon

and press Go. If you see a CUPSCAPT folder, delete it.

Also go to /Library/Printers>PPDs>Contents>Resources and delete all Canon files (don't remember how they are named, but the start with C something).

Then reboot the computer and then add the remote printer again.

For more information, see this forum thread where I found this solution.

Using autofs to fix a number of issues with using AFP network shares in Mac OS X

My wife and I share a Macbook Air with Mac OS X Lion using fast user switching.  We both work with files stored on an AFP network share from our family Mac Mini using the MBA.  We were running into the following issues with this setup:

• The network share ("family-network-share") from the Mac Mini would frequently get dropped and have to be remounted manually. Often the original mount point stealthily persisted in /Volumes (not shown in Finder, but shows up when you do an ls in Terminal) so that when you remounted the share it got the name family-network-share-1 (as shown with ls in Terminal), which broke any applications or scripts that used the share.
• If one of us mounted the network share it would show up under Volumes (and on the desktop) for the other user, but it would be unaccessible to the second user (as indicated by a red circle badge on the mounted share in Finder) because permissions were restricted to the person who originally mounted the share.
• When the second person mounted the share it would show up in Finder and the desktop as a second instance of the share with the same name, but in Terminal it got the name family-network-share-1 because the /Volumes mount point was already taken by the first user.  This made it impossible to have any scripts or applications use the network share because you couldn't be sure what its path would be for a particular user.

After a lot of googling around, I came up with the solution of using autofs to set up separate permanent mounts of the network share for each user in a location other than /Volumes.  What autofs in Mac OS X lets you do is set up virtual folders that automatically connect to the specified network share whenever an application tries to use the folder.  Because the connection is on demand it (so far) never drops.  Because I set up separate autofs mounts for each user the name of the share mount point is reliable and you can point applications and scripts to the share mount point with confidence.

The documentation for autofs can be found here.  It is a little obscure, so here is a quick and dirty tutorial.

Open up the existing system auto_master file using sudo:

sudo nano /etc/auto_master

Then add an entry at the end with the name of your (soon to be created) mount map file

/-        auto_my_mount_map_file

You can apparently name this mount map file anything you want, so don't feel you have to copy the arbitrary name used here.

Then create your mount map file in the /etc folder using sudo nano

sudo nano /etc/auto_my_mount_map_file

And in that file add a line for each network share you want to automount giving the mount point first, followed by the network share path and credentials, like so:

/Users/andy/family_share_mount_point -fstype=afp  afp://username:password@share_local_IP_address/family-network-share

This is all on one line; ignore how Blogger wraps it.

Then load the new mount map file by reloading autofs like so:

sudo automount -vc

The first thing you are going to do is look for the new mount in Finder, and when you do that you will think it didn't work because it won't show up in Finder.  However, it is working, as you can demonstrate by navigating to the new folder in Terminal:

cd /Users/andy/family-network-share 

 ls

After you do that, go back to Finder and voila, now it shows up.  My theory is that autofs doesn't bother to mount the network share until some program tries to use it.  To avoid the problem of the folder not being visible in Finder after a reboot I wrote a two line BASH script to cd to the share folder and then list its contents using ls, and then put that script in each user's login items under System Preferences - Users and Groups.

UPDATE 2016-01-13:

After coming back from a long trip and setting up our network again from scratch, I was having trouble getting this to work.  The specific issue was that one user, or both users, would be locked out of the mount point for the network share because the owner of the mount point was randomly (at least I couldn't detect a consistent pattern) being changed to root by the system. This problem appeared to go away after I took the following steps:
 - I put the mount points one more level down in the directory structure, i.e. instead of /Users/andy/my_mount_point I made it /Users/andy/Famly_shares/my_mount_point.
 - I did not create the mount point manually, I just put it in the auto_my_map_point file.
 - I very excluded the parent folders of both users' mount points from Spotlight (System Preferences -> Spotlight -> Privacy).  It can be confusing because privacy exclusions set by both users seem to show up in both user's Spotlight settings, and it shows only the final folder of the excluded path, but if you hover over the folder name for a few seconds a tooltip shows up with the full path.  My reason for trying this was that autofs creates a mount point when a user tries to access the mount point, so maybe Spotlight indexing activity was causing the share to be mounted as root and locking users out.
 - I reactivated my old login script that changed directory into the mount point (see above) even though under El Capitan the mount point showed up without it.  Once again, my theory was that the first user to access the mount point wins, so the login script to go into the folder hopefully prevents some root process from getting there first.