Hello Quinn, thank you as always. I have read and understand the On File System Permissions link. It is very useful, and I'm going to share it around the office. Thanks! I did as suggested and found that I could open a writing file handle, and even write data. However, I noticed that I could not open a reading handle. So I restored the original code but changed the originalItemURL to be hard-coded to a file in my home directory, and the call to fileManager.replaceItemAt succeeded. The problem wasn't writing to /etc/ssh/sshd_config, it was reading from the temporary file location. (So why was the function that called data.write failing? Because it wasn't actually getting called. Due to a bug, we were always calling the replaceItemAt function.) Looking through the code, I found that the URL was created (in Objective-C this time) using [fileManager URLForDirectory:NSItemReplacementDirectory inDomain:NSUserDomainMask appropriateForURL:fileURL create:YES error:&error] which resulted in a path within /private/var/folders/yg/2j4m93b50d7bwj9wd4r8cww00000gn/T/TemporaryItems And, as it turns out, you can't list that path, even with sudo, so your guess about a MAC check appears to be correct. So for some reason, the privileged helper installed using SMJobBless is allowed to access files within TemporaryItems, but the daemon installed using SMAppService.daemon is not. I attempted to send bookmarked URLs, both security-scoped and normal to the daemon, but that did not grant permission for fileManager to move the file. I suspect we can work around the problem by saving the temporary file elsewhere. That's a shame because NSItemReplacementDirectory seems like the "correct" location for the temporary file, but I suppose storing it to the Caches directory is probably a safe option, unless you think there's a more appropriate location. Thanks again.