Have you ever come across the above dialogue, asking if you’d like to “accept incoming network connections” on your Mac? It’s caused by the Firewall and it’s meant to be helpful. Because if you have an app that needs incoming network connections all the time, you can just add them to the Firewall rules (under System Preferences – Security – Firewall).
But of course, it doesn’t always work. Some apps get updated and this message starts appearing out of the blue, no matter if it hasn’t happened before or if you’ve manually added said app to the Firewall rules a thousand times already. God only knows whatever is upsetting our precious operating system, but it’s driving us all nuts.
Help is at hand: turns out these messages are caused by some certificate issue I genuinely do not care to know about – nor should I have to. Here’s a “relatively easy” way to fix it once and for all. There are other ways which involve more typing, or switching off the Firewall altogether, but the following is by far the quickest option in my opinion:
open a Finder window and navigate to the app in question (usually in Applications, potentially in a subfolder)
open a Terminal Session (under Applications – Utilities – Terminal)
type cd followed by a space
from the Finder window, drag the folder in which your app resides into the Terminal window
hit return (this will put you into the same directory as your app)
type the following scary line of code:
Replace “YourApp.app” with the actual name of the app, including the .app extension. You will be prompted for your password and in a few moments you should see a message such as “replacing existing signature”. With this code your Mac will have created a self-signed ad-hoc certificate, re-signing the app.
Don’t worry if this doesn’t sound English, all it means is that we’re telling the operating system (or rather, Keychain Access) that “the Administrator says it’s OK to trust this app”.
Now launch your app again. Don’t be dismayed when you see that annoying “accept incoming connections” dialogue again – it’ll be the last time. Select “allow” and you’re done with this – hopefully for good. Try it out by closing your app and restart it again. Celebrate about not seeing that message again.
Should this trick not work, leave out the –deep switch, and make sure your file does not have a trailing slash. Oh, and preface any spaces in the file name with a backslash.
Kudos to ahall over on Stack Exchange for this tip! It’s made me a much happier person again 🙂
I passionately *H*A*T*E* the startup chime that my Mac makes when I switch it on. At least on my MacBook, if the volume is turned down before I shutdown, the system restarts silently. I guess it’s somehow linked to the internal speakers.
Sadly on my Mac Mini this approach doesn’t work: due to the lack of “real” internal speakers , the Mini always wakes up with that horrible eighties K-DONNNNNNNNG noise, waking up my wife and large parts of the neighbourhood.
But there’s good news: thanks to the nvram command we can set a firmware value to suppress this sound. Here’s how:
sudo nvram SystemAudioVolume=%80
This will write a value of 128 (or 80 in hex) to the BIOS. Make sure to shutdown your system and then power back on to “hear” the effect on a Mac Mini: simply restarting it will not suppress the sound, but a full shutdown and restart will do the trick from now on. Result!
As much as I dislike the sound, it is there for a reason: it signals the successful completion of a quick self test. I appreciate this – so I may not want to switch K-DONNNNNNNNG off forever.
It’s easy to remove that value again from the BIOS, using the -d parameter of the same command:
There. Now the horror chime is enabled again, ready to annoy more neighbours at 3am.
Windows users have a great free tool called ISO2USB which efficiently transfers ISO images to a USB stick. Mac users don’t have such a luxury – at least I haven’t found one yet.
Instead we can make use of a command line tool named dd which can do this for us. It needs a few parameters though, and in this article we’ll look at what those are. The following will work in both Mavericks and Yosemite, with ISOs from CentOS 6.5 and above. Our operation will result in a bootable USB stick.
First, head over to a CentOS Mirror and download your favourite ISO image. Next, have a USB stick handy and insert it into your Mac. Now open Terminal – it’s under Applications – Utilities, or do a Spotlight search to find it.
For this example I’m assuming that the image file is called centos.iso and that it’s in your Downloads directory. Let’s enter that directory by issuing the following command:
The second command lists all files, and your ISO image should be one of them.
Find out what device your USB stick is
So far so good, we’re in the right location. The dd command needs to know which file you want to copy (see above), and the device corresponding to your USB stick. It’s easy to get confused at this point. Let me explain this:
Devices are things attached to the system, such as hard disk, memory cards and USB sticks. Each device can hold a number of partitions which is where your data is stored. Depending on how many storage devices are attached to your system, you’ll get a specific address for each device. For example, /dev/disk0 is your internal Mac hard disk in which you’ll find three partitions.
Since our ISO image will overwrite all partitions on the USB stick, we need to know what the system knows our USB stick as. Type the following to get a list of what’s attached where:
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
#: TYPE NAME SIZE IDENTIFIER
Looks like I’ve got 5 storage devices on my system. The one at the bottom is my USB stick, an old 4GB model currently formatted with FAT32. Your layout will be different, so keep an eye on the SIZE parameter. If your currently formatted stick is named you can identify it that way too (mine is called C64).
The device I want to use here is /dev/disk4. Note that when we get to work, everything on your USB stick will be erased when we copy the ISO over. The dd command will not warn you before this happens.
Unmount your USB stick
Before we can continue we need to make sure your USB stick isn’t mounted to OS X. If it was formatted with a filesystem that your Mac can read, then you’ll see your stick as an orange icon on the desktop. But since the dd command will do a low level format with a different filesystem, OS X needs to let go of our stick. If we don’t do this, you’ll get a “Resource busy” message in the next step.
To unmount your stick, type the following:
Unmountof all volumes on disk4 was successful
That orange icon should disappear from the desktop, and you will no longer see your USB stick in the Finder either. Leave it attached though – do not eject it.
Copy the ISO image over
Now let’s give the dd command something to do. Since we’re in the correct directory already, type the following (you will be prompted for your password):
Amend /dev/disk4 with your own device. Feel free to specify the direct path to your image file in place of centos.iso (no wildcards I’m afraid).
This step can take a long time, during which you won’t get any feedback whatsoever. That’s normal, even though it looks like your session hangs. It’s all good. As long as you leave the Terminal window open, feel free to do other things with your Mac and leave it running.
In the above example I was copying a 190MB image and it took just over four minutes. I had an abysmally slow USB stick mind you – something to keep in mind when you want to transfer a large “everything ISO” image onto a stick from 10 years ago: you’re not doing yourself a favour, it’ll take hours to copy, and just as long to boot from later.
Should you want to terminate your dd session during this time (and use a faster USB stick for example), simply hit CTRL+C and you’ll be returned to the command line.
If all went well you’ll receive a summary message at the end. Now you’re ready to boot from your stick into the wonderful world of CentOS.
Yesterday I was trying to open an installer which was offered as a .dmg file. That’s a disk image which mounted itself fine, but when I ran the installer contained in the disk image, all I got was an error message: “ZBrush to Keyshot Content Installer is damaged and could not be opened”.
At first I thought perhaps the download had a problem, or perhaps the source file was corrupt. But in such cases the .dmg usually doesn’t even mount – which mine did. Perplexed, I raised a support ticket with the provider of the software.
Thanks to Matthew at Pixologic support I received a very quick solution to this puzzle: there’s nothing wrong with my download, nor with the source file – it’s OS X’s Security Settings that flag up an inappropriate error.
Thank you, Gatekeeper!
Here’s how to fix it:
head over to System Preferences – Security and Privacy
select the General Tab
click the little Lock Icon and enter your password
now select Allow apps downloaded from anywhere
I would have never made the connection between the “corrupt file” error message and Gatekeeper preventing the file from opening properly. Usually when Gatekeeper gets involved it’s very clear that OS X is preventing something from being opened, with a hint of where to tweak those settings. But not in this case.
As soon as you select “Allow from anywhere” a modal window pops up asking you if you’re really sure. It also explains a new Yosemite behaviour that if you decide to go ahead, the setting will revert back in 30 days. So if you think “hey, I’ve tweaked this setting recently”, don’t doubt your sanity.
There’s no need to download the file again either. Now my download opens fine, mounts fine, and most importantly installs fine too.
When you’re trying to open any of the Adobe CS5 or CS6 applications in Yosemite, you’ve likely encountered a friendly message such as this:
This happens because CS5 and CS6 applications were relying on Java 6, and the current version at the time of writing is Java 8. I’m not an expert on Java, but I can only assume that things have changed and backward compatibility wasn’t high on ORACLE’s priority list.
Lucky for us, we can have both Java 6 and Java 8 installed at the same time, the latter is an option offer by Apple.
When you click the More Info button you’ll be taken to an Apple Support site which allows you to download it from the following link:
Apple’s Support Site has a habit of returning empty white pages lately. If this happens to you, try to find this page in Google and click that super tiny green arrow next to the word “support”. This will bring up a dropdown menu from which you can select Cached. I remember in the good old days this option was more prominent, and it will take you to a link similar to this one:
root is the most powerful user in Linux and UNIX systems, from which OS X is derived. The root user can read, write and delete every file on the system and – when placed in the wrong hands – destroy the entire system in a flash. Even power users on a Mac have very little reason to use root – which is why it’s disabled by default.
To enable it, head over to System Preferences – Users and Groups and select Login Options at the bottom left. If any of the following options are greyed out, simply click that little lock icon (and type in your computer password):
Now select Network Account Server – Join… and another scary window appears. Thankfully we won’t have to worry about what it says:
All we’re interested in is the standard menu bar at the top of the screen: select Edit – Enable Root User and hike it out of here. If ever you want to disable root, select Edit – Disable Root User (or change its password). Speaking of which, you’ll have to give the root user a password when prompted. Remember it.
Now click the little Apple Icon at the top left and log yourself out.
When your computer comes back you’ll be able to login as root, using the password you’ve specified. OS X will now start as if you’ve never setup your computer.
Remember to disable the root user again for your own safety when you no longer need it.
Updating to the latest version of OS X is tempting – but there’s always a risk that some of your older apps may stop working. If only there was a way to “rehearse” the update process on a dummy system.
I’m happy to tell you that there is, and it’s neither as expensive as a brand new computer, nor as time consuming as recreating your entire system from a time machine backup. In this article I’ll show you how.
Here are the ingredients you’ll need:
1x external USB drive, bootable (Seagate Backup Plus, WD My Passport, any of those – USB 3 preferred)
1x copy of Shirt Pocket’s SuperDuper (don’t judge them by their name)
1x fresh pot of coffee
patience and 1-2hrs of uninterrupted time
Copying your entire hard drive and isolating every file takes a long time – especially if you don’t have USB 3 (like me). Transferring 500GB or more will take over 24 hours, perhaps longer. No can do.
Enter SuperDuper! It’s a utility with which you can do something even better. I got hold of a copy a few years ago when I replaced my internal MacBook Pro hard disk with an SSD. The free version does a complete clone, but it also has a feature called Sandbox which you can access when you buy the full version.
Sandbox does not copy all files over to an external drive. Instead, it copies user and system files and leaves the rest untouched. It still creates a bootable volume, so all mission critical data is isolated (including Mac apps like Safari, Mail, iMovie, etc). But all your other 3rd party apps, as well as your Documents and Desktop are shared and remain untouched.
When I say shared I mean that after you’ve finished creating the Sandbox on an external drive (or even an internal partition) you’ll be able to choose which system you boot into and access all your data either way.
This is done cleverly by creating symbolic links to your internal drive for everything that the external drive would need to access. It’s like shortcuts in Windows.
Creating the Sandbox Drive
Grab your external drive, plug it in and erase it using Disk Utility (Applications – Utilities – Disk Utility). Make sure your partition is Mac Extended Journaled flavour (not NTFS or anything else).
Next, download a copy of SuperDuper from Shirt Pocket. You need to buy the full version to get access to the Sandbox feature. However, if you’re strapped for cash and have a lot of time on your hands, you can still perform a full clone instead – that’s part of the free version. It just takes a little longer.
Start SuperDuper and you’re presented with a dialogue similar to this:
Under Copy select your current (internal) drive. In the other dropdown select your target (external) drive. You’ll see several options in the third drop down which reads “Sandbox – shared users and applications” in my screenshot. Select this option.
Other options include a full backup, as well as Sandbox – shared users. The latter copies all your 3rd party apps so will take more time, and it’s not necessary for our exercise here. Hit Copy Now and grab a coffee – this could take some time.
SuperDuper will go ahead and erase your volume and will tell you when it’s finished.
Booting into the Sandbox
With your external drive still attached, head over to System Preferences – Startup Disk. Select your external drive here. Hit Restart and your Mac will boot into the external Sandbox. This will take a little longer than usual, simply because the read speed from an external volume is much slower than an internal SATA drive – especially if you’re used to an SSD or Fusion Drive.
Once restarted you may not notice any other differences. Dropbox didn’t want to work for me, but other than that my system looked exactly like I had left it. With one big and important difference of course: under Applications I can now see many of my app icons with a small arrow in the bottom left corner:
That arrow indicates a symbolic link (shown here on Parallels Desktop, Poedit and Sculptris). If I were to launch one of those they would be started from their original location, i.e. my internal hard disk. Other apps like Safari and Photo Booth don’t have an arrow – those are started from my external drive because they’re classed as “system apps” and have been copied over.
If an upgrade like Yosemite comes along it will overwrite all those system apps and other system files – but only on the external drive. If this messes anything up then all I have to do is head over to System Preferences and boot into my internal drive again – still untouched, still running Mavericks and still working fine.
Now you can “test upgrade” to Mavericks on the external drive and see if all is working. Take your time and test everything thoroughly. I found that the older drivers for my Wacom Bamboo 1st Generation are no longer working – my Intros 4 however has a different driver and is still working fine (contrary to what I thought at first when I made the video).
Upgrading the Sandbox to Yosemite
There are probably better guides out there that tell you exactly how you upgrade, so I’ll just give you a few pointers:
open App Store
head over to Updates (or click that massive Yosemite mountain on the front page)
download the installer
Once the 5+GB have downloaded (straight into Applications – Install OS X Yosemite.app) you may want to copy this file to a safe place. This will save you a second download when you decide to install Yosemite for real. This installer will be removed automatically when Yosemite has finished – so now’s your chance to grab it.
And one final tip: you may need to install Java for OS X in case some of your apps don’t start under Yosemite. If that happens OS X will show you a little dialogue box and direct you to the following link when you click More Options: http://support.apple.com/kb/DL1572
Done with Yosemite?
If you want to go back to your previous system, simply head over to System Preferences – Startup Disk again and select your internal drive, then restart. No matter if your sandbox is still plugged in or not, you’ll be back on Mavericks with no system changes.
Updating the internal drive (when you’re ready)
If you’re happy that your system will survive the update, go ahead and update via the installer, or download the installer again from the App Store. This will take some time (again).
If you’re impatient, you’ll be pleased to hear that SuperDuper also offers to copy changes from the Sandbox back to the internal drive. It will tell you all about this in the documentation, under the section “Maintaining a Sandbox”. It’s worth the read.
By default Yosemite doesn’t like users to auto-login when the system starts. Instead you have to select a user, type in the password, and then the system starts to boot. Not necessarily what we want.
To disable this feature you usually head over to
Users and Groups
and pick your default user from that handy drop down menu. Notice however that this is greyed out on Yosemite:
So what gives?
Turns out that this option is not available if you’ve agreed to encrypt your disk via FileVault. And it makes sense too: otherwise your hard disk data could be accessed upon boot without a password, rendering this feature useless.
Hence, to bring back automatic logins, turn off FileVault under
Security and Privacy
According to this system, I can do that in about 32 days…
Notice that if you use your iCloud password as the login password, auto-logins are also disabled. In which case, change your login password to a “separate password”, switch off FileVault and voila – auto logins are back at your disposal.