mac posts

Openrsync issues resolved (I hope)

I think I have finally worked through and fixed the issues caused by Mac OS 15.4 switching from rsync to openrsync. With the switch, many of my backup and other rsync scripts broke, throwing errors and not finishing the sync. As of that last post, I had gotten things mostly working, but had to disable incremental snapshotting and still sometimes had failures that I had to deal with.

Some of the errors I’ve had include:

… copy_file dfd: openat: Too many open files …
… empty link …
… error: unexpected end of file …
… No such file or directory …
… opendir … failed: Interrupted system call …

For Too many open files, I had to reduce the file count in my really gigantic backups. Instead of backup up the entire /Users directory, I made a loop to do each user separately. I also excluded various cache directories and the like that have lots of files that aren’t important for a backup. It took searching and repeated runs to find and add enough such folders to the list. These include:

rsync … \
--exclude '.brew' \
--exclude '.cache' \
--exclude '.node-gyp' \
--exclude '.npm' \
--exclude '.pnpm-store' \
--exclude '.sass-cache' \
--exclude 'node_modules' \
--exclude 'Data/Library/Caches/' \
--exclude '/Library/Application Support/Adobe/Fireworks CS6' \
--exclude '/Library/Application Support/Amazon Music' \
--exclude '/Library/Application Support/Firefox/Profiles/*/storage' \
--exclude '/Library/Application Support/Chromium/*/Service Worker/CacheStorage' \
--exclude '/Library/Metadata/CoreSpotlight' \
--exclude '/Library/Caches' \
--exclude '/Library/Cookies' \
--exclude '/Library/Logs' \
…

For unexpected end of file, I had to add the --inplace option. I think this has some risks to it. The man page mentions possible issues with hard links: Not sure if that relates to the --link-dest option and if it may cause overwrites of previous snapshots or anything like that. But I needed it for the incremental snapshots to work at all.

For Interrupted system call, there were certain folders, mostly in user library folders, that I found I needed to exclude. The error message unfortunately gave no hint to where the error happened in the filesystem, so I had to do a time consuming process to find the problem files. I excluded large folders until things worked and then added back items within those until I had added back what wasn’t causing the error, up to the amount of time I was willing to spend going deeper or when I was dealing with folders whose content didn’t matter for backup. I don’t remember all of them, but I believe they included:

rsync … \
--exclude '/Applications' \
--exclude '/Library/Application Support/iTerm2' \
--exclude '/Library/Containers/com.apple.Safari/Data/Library/Caches' \
--exclude '/Previously Relocated Items*' \
…

As mentioned in the previous post, for empty link, I had to remove or exclude symlinks that weren’t pointing anywhere. Some of those were for stuff that does point to something when shared with a virtual machine, which had to be excluded. Others were simply links whose originals must’ve been removed at some point or whatever, and could be removed without issue.

For many use cases, using the homebrew version of rsync (brew install rsync) will be the normal version and not have these issues. But I don’t want to run homebrew stuff with my root user, and I need to use the root user to broadly back up all of my users’ data at once.

I’m not sure why Apple had to switch to openrsync, and I’m not sure why openrsync has so many troubles that regular rsync doesn’t. It took up a fair amount of my time and frustration to get things fully working again. But I’m glad I seem to have solved the issues.


Looks like my Macbook Air (2020 Intel) will not be supported for the next major MacOS update, Tahoe. I knew that was coming at some point when they switched to ARM architecture. Luckily, Sequoia should still receive security updates into 2026 or 2027, and that’s all I really care about. By that point, I will probably transition to a Linux computer for my main, and if I need a new Mac for other stuff, may just get a refurb Mini.


In Mac OS Sonoma, browsers now require and the OS will ask for the “Local Network” permission to access local websites. I didn’t know why it was asking and didn’t allow it, but then couldn’t access my sites. I had to go to “System Settings”, the “Privacy & Security” pane, select “Local Network” and turn on for my browser(s) to get access again.

If it matters, my local dev setup uses domains set in /etc/hosts pointing to IPs of VMs run by VirtualBox, managed by Vagrant, set up like web.vm.network 'private_network', ip: '192.168.56.1'.


Mac: create app launch keyboard shortcuts

I wanted to create some global keyboard shortcuts for launching apps on MacOS. I used to do this with Quicksilver, but I’ve stopped using that and now just use Spotlight for most of what I used that for. Spotlight, of course, doesn’t have all the features of Quicksilver, including keyboard shortcuts for arbitrary actions. The “Keyboards Shortcuts” pane in System Settings can do a lot, but not specify a specific app to launch. Searching around the web, I found that Automator could be used to add services to it. So a flow to do this for an app would be like:

Continue reading post "Mac: create app launch keyboard shortcuts"

xz backdoor

Reading this weekend about a backdoor introduced to the open source xz project. It doesn’t appear to affect my Ubuntu servers, so I had assumed it wasn’t relevant to me. However, the homebrew version on my Mac was “vulnerable”. It sounds like the exploit would only work on some versions of Linux, but if it does work on Macs, that could be bad. I do a lot of stuff on this computer, including banking, email, coding, etc. They know about it backdooring ssh, but if there’s something they don’t yet know about, it might be a problem.

I have a Fedora install as well. I haven’t checked it yet, but Fedora is usually on the bleeding edge, so if it’s on there, I’ll probably wipe and reinstall. I’ve been considering anyway. Luckily, I don’t do anything important on there.

Even if it didn’t actually do anything bad on the Mac, it may have done something. I had noticed some weeks or months ago (I can’t remember when) that running PHP on the command line was going slow. Running anything would take a minimum of about five seconds, including something simple like php -r 'echo "hello\n";'. I know when I had been making scripts in the past they hadn’t been taking long at all. I did some searches on the web for anybody mentioning something like that and couldn’t find anything. So I kinda just figured maybe it had something to do with the new opcode / whatever cacheing newer versions do or something, like it takes some initial setup that the server can reuse but not the command line. I assumed I was stuck with it and even started moving some scripts to bash partly because of it. When I downgraded xz via homebrew though, I decided to test it. time says the simple php -r line took 0.092 seconds. Nice and snappy. So maybe xz was doing some checks to see if the device was exploitable. It was in the dependency graph of PHP through curl and gd. Can’t say for sure that it just sped up though and if the xz change was what caused it.

I’m glad my scripts finally run quickly again, but hope that nothing was exploited here. I’ll keep an eye on the web to see if anything comes up about Macs being exploitable, and if so I’ll probably reinstall the OS to be safe.

Note: If you have used homewbrew to install PHP, curl, or anything else that might depend on xz, run brew update; brew upgrade to be safe. The dangers of being on the bleeding edge I guess.


git: MacOS default branch now “main”?

At some point recently, git init on my Mac has started to default to the branch name “main”. It did this for a repo I created today, but not for one created August 29th, so maybe Apple made a change in an update sometime between then and now. I haven’t been able to find anything about the change on the web though.

Continue reading post "git: MacOS default branch now “main”?"