Escaping the iCloud with the help of a 44-year-old Linux coreutil

I have been slowly moving away from reliance on big tech. I let my iCloud subscription lapse after setting up immich to backup my phone pictures to my zfs storage pool. Today I finally got the warning that iCloud has expired and that I was out of storage space, so I spent my morning cleaning up the iCloud Drive on my phone. Most of the files in the iCloud Drive were from elsewhere, just thrown into this cloud directory so I could access on the go. I haven’t used it in awhile since setting up my own cloud server.

Alas, with this warning, I lost my vital, continuous, in the background iPhone backups. If I ever broke or lost my phone I’d be screwed. Though I’ve moved on to daily driving Linux, I still keep a baseline Mac Mini around for purposes such as this. One caveat, the Mac only has 256GB of storage which is half of my iPhones capacity. At the time of purchase I wasn’t worried about the limited storage because I have about 48TB of space on my new NAS and I really liked the $600 price tag for a shiny new M4 Apple Silicon chip. Though the local storage limitation posed an issue. MacOS hardcodes the backup directory to its local storage at ’~/Library/Application Support/MobileSync/Backup/’ without an apparent way to manually choose the backup directory. I simply had no room to backup my phone locally.

The answer was a simple symlink! I often forget how useful they can be.

Before I show you my solution, the history of symbolic links is pretty interesting, considering how ubiquitous they are now. I did a little research during my problem solving here, and wanted to give a quick history lesson and some basic examples of how they practically hold uses of the OS together at this point.

From Wikipedia:

A symbolic link is an independent file that stores a file system path that, except for special situations, is treated as the file system item to which the path refers: the target. If a symbolic link is deleted, its target is not affected. If the target is moved, renamed or deleted, the symbolic link is not automatically updated or deleted. Its target path would point to nothing and might be described as broken, orphaned, dead, or dangling. The symbolic link differs from the hard link. The latter cannot link to a target on a different volume or file system, but the former can. A hard link always refers to an existing target, whereas a symbolic link might be a path to nothing.

Source: Symbolic Links on Wikipedia

Symbolic links were released in the 4.1a intermediate release of BSD Unix ahead of 4.2 in 1982. Fun fact, this was the same BSD version TCP/IP was released in. Who knew these now fundamental features being released in Unix 44 years ago would still be in use as vital mechanisms underlying modern computing today? Maybe the intelligent folks from Bell Labs knew all along.

Today, symbolic links are used all over the operating systems we know and love in various ways. The two I typically see and use regularly in Linux are for linking /etc/nginx/sites-available/ configs to /etc/nginx/sites-enabled/ where the web server then serves them from. This allows the system administrator to simply remove the symlink instead of deleting or editing the config file.

They’re also used in systemd when enabling a service on boot. Running ‘systemctl enable nginx’ literally just creates a symlink to the unit file like:

ln -s /usr/lib/systemd/system/nginx.service \
      /etc/systemd/system/multi-user.target.wants/nginx.service

Symlinks are a tool so basic and at this point a core part of Linux & Unix based systems. I often forget it’s there and that it can be used to solve simple problems, like for instance, MacOS not letting me choose my own directory for my iPhone backups. Of course symlinks are used elsewhere in a myriad of other ways in the OS by administrators and engineers much smarter than I am to solve their actual, much more difficult problems. My fascination is rudimentary by comparison.

I’m just sad I didn’t realize this solution myself. Kind of a sad testament to my further reliance on external AI tools. I’m sure I would have gotten to the solution eventually, but I find it a bit upsetting that my first instinct is to ask Claude, though I must admit it probably saved me at least an hour of troubleshooting. Or maybe I would have just googled it and gotten my answer from a website blasting me with ads from an SEO farms blog post. It’s tough to say

If you want to use symlinks to get your manual iPhone backups to an external drive, you can follow my steps below, but please be advised that your steps will almost surely differ. I have an external spinning rust hard drive connected via USB-C formatted openZFS on MacOS. You can probably ignore the zfs command. Other steps might differ but the gist, and end result should be the same.

# First, you need to ensure Terminal or iTerm can even create a symlink. Not as simple as just using 'sudo' like in Linux. We need to use the GUI and open up System Settings. Go to Privacy & Security > Full Disk Access and toggle on your preferred terminal application in the menu.

sudo zfs create abraxas/iphone-backups

# since I used sudo (required by zfs unless configured otherwise) to create the dataset I had to ensure my user account owned the directory on the external drive (-R is for recursive ownership)

sudo chown -R phil_admin:staff /Volumes/abraxas/iphone-backups

# ensure any existing iPhone backups exist on the external drive, just in case
mv ~/Library/Application\ Support/MobileSync/Backup /Volumes/abraxas/iphone-backup

# then create the sym link
ln -s /Volumes/abraxas/iphone-backups ~/Library/Application\ Support/MobileSync/Backup

Now my iphone is backed up directly to my zpool, in it’s own dataset, on my own external storage! Take that Apple. I’ll have to manually back up my phone weekly or so like we did back in the days before the cloud, but it’s a small price to pay to remove yet another endless monthly subscription for further digital sovereignty in a day and age where big techs whole business model is to erode it away more and more while siphoning every last bit of our data.