Restore Failure: An error (32) occurred while copying. (Broken pipe)

The problem

If you are Cloning an image using Thunderbolt and Disk Utility (or even using Firewire instead of Thunderbolt), you may come across this error message:

I've actually never experienced that with Thunderbolt (not saying it can't happen), but I've had it happen twice using Firewire. At first I thought it was the cable ("broken pipe" would indicate to me a patchy physical connection of some kind), so I switched out the cable, and that didn't help. In another situation, I knew the cable was good, because I'd used it several times.

A possible solution

Try switching the direction. So if Mac A is in target disk mode and Mac B is in recovery mode, make it so Mac A is in recovery mode and Mac B is in target disk mode.


I don't know that this is the official workaround/fix or that this will always work, but I've gotten this error twice, and this workaround/fix worked in both cases.

iPad Gmail Mail “password missing” error

This randomly happened after we set up a slew of iPads with the same email account (Gmail on Mail), and sending messages put the outgoing message into the Outbox with an error that the password is missing, with the options to Cancel or go to Settings. Going to Settings, though, offers no option to input a password.

You can see here other users frustrated with this problem:
GMAIL Accounts unusable after 8.3 update!

Some workarounds offered are to use the Gmail app or to add Gmail as an Exchange account (if you're using Google Apps and not a regular home Gmail account).

The workaround we employed was to double-click the home button, swipe away the Mail application, and then launch it up again. After a minute or so, there would be an error about the missing password again. This time, though, the prompt for Settings would take you to a screen to enter the password.

Very odd issue.

Munki error “ERROR: Adobe Setup error: 79: Unknown error”

I prepared a nice little Adobe Acrobat Pro package for Munki, and I tried to install it and got this error (ERROR: Adobe Setup error: 79: Unknown error).

Turns out, that isn't a Munki error at all:
Re: [munki-dev] CS6 package wont install > Adobe Setup Error: 79

It has to do with some processes running in the background that prevent the installation from going through. I rebooted my computer (didn't launch up any other programs), ran it again, and all was good.

sudo managedsoftwareupdate --installonly
Managed Software Update Tool
Copyright 2010-2014 The Munki Project

Performing preflight tasks...
Installing Adobe Acrobat X Pro (1 of 1)...
Mounting disk image Adobe Acrobat Professional X_Install-10.1.1.dmg...
Starting Adobe installer...
Completed payload 1 of 4 - Suite Shared Configuration CS6...
Completed payload 2 of 4 - Acrobat X Pro...
Completed payload 3 of 4 - CS6 Master Collection...
Completed payload 4 of 4 - Acrobat X Pro...
Performing postflight tasks...
I hope that helps someone out there.

Google Maps’ “an error occurred, your last action was reverted” import error

If you're importing a .csv (or .xlsx) file into a Google Maps map, you may have seen an error like an error occurred, your last action was reverted.

Unfortunately, there doesn't seem to be official word on all the situations under which that happens and what the estimated timeframe is for a full fix (even if the functionality isn't fixed, a more informative error message would certainly help).

Here are a couple of threads on the matter:
Creating New Layer in My Maps "An error occurred, your last action was reverted"
Error Importing Spreadsheet: "An Error occurred, your last action was reverted."

I don't know that this will work for all or even most situations, but we had this come up here once, and the issue was selecting too many address/location fields.

So, if you've had experience checking all the fields and it working, sometimes it does appear to work. Other times, if you check all the fields... importtogooglemaps01
... you may later get this error before the import finishes... importtogooglemaps02

In our particular situation, checking only the box with the location/address appeared to make the error go away (and make the import successful).

Enabling https for Apache server on Yosemite

I found a bunch of different instructions, but these are the instructions that actually worked for me (regular Mac running Apache server) to get https working (self-signed certificate, so you will get the certificate warning from your web browser):

Step 1

Self-signed SSL Certificate on Mac Yosemite

Step 2

Enable HTTPS in Apache on Mac Yosemite

Step 3

Step 2 gave me an error (AH00526: Syntax error on line 73 of /private/etc/apache2/extra/httpd-ssl.conf: SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).), so I edited the /private/etc/apache2/httpd-conf and followed these instructions.

Prevent a partition from mounting at boot time

Cheating a bit here, because I'm just linking to an excellent blog post on the procedure:
OS X Tip: Prevent a Volume From Mounting at Startup

It's very helpful if you've set up a Boot Camp dual-boot with Windows, and you don't want to have the Windows partition automatically mount when you boot into Mac OS X.

One working fix for “filter failed” printer message on a Mac

There seem to be several "working" (your mileage may vary) fixes for the "filter failed" message when you try to print on a Mac (may happen in Linux, too, since Mac uses CUPS for printing), and they all seem driver-related:
'Filter' failed error when printing from EPSON
Yosemite and a printer driver that broke

The one that fixed it for me was checking on another computer that's working fine with that printer and going to System Information > Printers to find out what the exact driver is that's used, and then deleting the printer from the computer having issues, and then re-adding it manually (not with a script) and manually selecting the correct driver.

Manually adding icons to Munki-imported packages

As with all Munki tutorials, this one assumes you already know some Munki basics. If you don't, you might want to start with Absolute beginner's guide to setting up Munki (not monkey).

When you use munkiimport to import software packages, it will either find icons automatically or prompt you to try to extract icons from the package. In some cases, the extraction doesn't work, and you may have to create an icon manually.

First, go into your munki_repo and then within the pkgsinfo subdirectory, find your package info. As an example, we'll use Inkscape. Open it up in a text editor (e.g., TextWrangler).

What we want from this is the name of the package (which may be different from the display name). The name here is Inkscape, so that's what we're going to call the .png file we create.

Alternate Method to Find Names: If you run

sudo managedsoftwareupdate -vvv
on your server on a client machine, you can see all the names of the .png files that did not download because of a 404 (not found) message. This may be quicker, actually.

Mac software packages usually have a .icns file for the icon, but Munki is looking for a .png, so we'll do a conversion.

On a computer that has installed the program you want (in this case, Inkscape), you want to run something like the following command:

sips -s format png /Applications/ --out /Users/Shared/munki_repo/icons/Inkscape.png
If Inkscape is not installed on your Munki repository server, you can just output it to somewhere else temporarily and then put it in the munki_repo's icons folder later.

Then, if a user launches up Managed Software Center, she should see the new icon associated with the software package, instead of the generic placeholder.

Troubleshooting Suggestion: If your icons still aren't showing up, and you're 100% certain the name matches, the permissions may be wrong. I thought 644 on the icons directory content would be a enough (read/write for owner, read for everyone else), but I had to change it to 755 recursively to get all the icons to work, for some reason.

More details at the Munki Google Code page about icon guidelines.

Creating an installation package for a scheduled Adobe Remote Update Manager

This is kind of a dual-purpose Mac tutorial—how to automate Adobe Remote Update Manager and how to create an installation package using a point-and-click graphical interface.

Automating Adobe Remote Update Manager

You can find the Adobe Remote Update Manager on Adobe's Creative Suite Enterprise Deployment page. Just scroll down a bit until you find it.

When you launch up what appears to be an installer, it's not an installer at all. It's just a folder with a bunch of files in it.

For our purposes here, the only file that matters is RemoteUpdateManager. That is the actual executable binary that initiates the updates. You don't really need to install the RUM man(ual) page. If you want to find the update options (including how to use a proxy instead of getting updates directly from Adobe), you can find those on Adobe's website.

Remember where the RemoteUpdateManager file is. We'll need that file later.

Then create a text file called local.rum.plist and put in the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
<plist version="1.0">
<!-- <key>Day</key>
<integer>0</integer> -->
<!-- <key>Month</key>
<integer>0</integer> -->
You'll see that day, month, and weekday are commented out. You can uncomment those and pick a particular recurrence. Right now it's also set to run every day at 18:15 (or 6:15pm), but you can change those values as well.

The text file you just created is the launch daemon that will run the Adobe Remote Update Manager (RUM) once a day at 18:15 (or with whatever frequency you set up).

Creating the distributable package

If there are multiple machines you want to set this up for, you don't want to be manually copying files to two different locations on each computer. We're going to set it up so you can install a .pkg file on each computer, or distribute the .pkg file to each computer using something like Munki.

Apple provides its own official documentation on how to build a .pkg file. If you can use those instructions, good on you.

I found it much easier to use a program called Packages to do it the point-and-click way.

When you go to the Packages website, click the Download link.

Once you open the download, double-click Install Packages.pkg.

Click Continue.

After you read the agreement, click Continue again.

Click Agree.

Click Install.

Authenticate and then click Install Software.

Click Close.

Now that it's installed, go ahead and launch up the Packages program.

For this situation (Adobe RUM), we're just going to select Raw Package and then click Next.

Name your project accordingly.

By default, the project will be a subdirectory of your /Users/username folder, so you may want to pick a different directory. If you're fine with the default, just go with it.

In Settings you can change the Identifier to represent your actual company/school/organization instead.

Click on Payload and then select LaunchDaemons (under Library) and the plus sign below it to add to that folder (sorry—I accidentally cropped the plus sign out of this screenshot).

Then go find the RemoteUpdateManager binary you downloaded from Adobe earlier.

Click Add.

The default permissions should be fine here (644 or -rw-r--r--).

Click on Scripts (under /Library) and the plus sign below.

Then select your local.rum.plist file you created earlier.

Click Add.

These permissions should be fine. It just means any user will be able to run RemoteUpdateManager, which is fine. Only the script will probably run it, but there's no harm in the users being able to invoke it manually, too, if they want.

Go ahead and save the project.

Then click Build and select Build.

The project should build successfully (and fairly quickly).

Then you'll see your installer file in the directory you should earlier, under the subdirectory build. If you're using Munki to distribute, then you can do a munkiimport directly on this .pkg file.