I have a perpetually recurring error with KM. I create and run macros that use scripts, and work fine. Then at a certain point, running (any) one of these scripts will throws up an error along these lines:
2017-03-03 11:02:13.328 osascript[20102:173258841] kCFURLVolumeIsAutomountedKey missing for file:///Volumes/Users/: Error Domain=NSCocoaErrorDomain Code=257 “The file “Users” couldn’t be opened because you don’t have permission to view it.” UserInfo={NSURL=file:///Volumes/Users/, NSFilePath=/Volumes/Users, NSUnderlyingError=0x7f9533d07870 {Error Domain=NSPOSIXErrorDomain Code=13 “Permission denied”}}
I think the /Volumes/Users path may appear when my backup script runs, and then disappear again, but I don't understand what that has to do with KM running scripts. I have to restart to get the error to go away, and then after a while it returns.
If you Google “osascript kCFURLVolumeIsAutomountedKey” you get a couple of pages telling you to install or update the XCode CLI tools. That is not the solution here; I have done so (and restarted) and it doesn't help.
Also, please try to narrow down, and be precise, about "at a certain point" when the script fails. Try to describe the environment (what apps/tools/etc are running) when it fails. You may need to run the macOS Activity Monitor when it fails to identify these.
I had this a while back and can't for the life of me remember what the cause was and how I fixed it.
I am pretty sure it was nothing to do with KM, I only got errors when it tried to run applescript and the macros had all been fine the day before and were unchanged.
It might have been to do with an external volume having issues, do you have any external drives plugged in? If you do then unmount them, try a macro and see if the error recurs.
I will keep trying to remember and have a search to see if I made any notes!
Open a new finder window, press command + shift + G, type in /Volumes then press return. Look for anything that isn't a disk. If you refer to a disk that isn't there then osx may well create a folder in /Volumes. Worth a look.
The OP is speaking of “/Volumes/Users” that may appear when his backup script runs. So, probably he is using a faulty backup script (with /Volumes/Users instead of /Users) and the created “fake” volume is causing trouble (perhaps conflicting mount points).
But this is speculation, as long as he doesn’t tell us more about the affected macros/scripts…
I still can’t remember the details, BUT, I do recall that the error message was nothing to do with KM and also NONE of my macros had any connection to the path thrown up in the error message.
The problem was something to do with the way that AS initialises and something upsetting it.
I seem to think that it was either, a duff folder in /Volumes, bad permissions or a problem on an external drive.
I would suggest, checking and cleaning up /Volumes, doing a ‘Get Info’ on each drive and checking the users and permissions in there, running Disk Utility (and DiskWarrior if available), ejecting and unplugging all external drives, then trying to replicate the problem. If it’s still there then it must be something else. If it isn’t then re-add the external drives one by one and retest after each. If the problem comes back then you have found the problem device.
Hopefully that will help, it happened to me back at the end of January and I fixed it but can only find the screenshot I posted, I don’t seem to have made any notes so it can’t have taken me long to sort out.
I have very vague recollections that it was an external drive issue, maybe something will come back to me or more info here will trigger something, or, with any luck the steps above will prove successful!
Many thanks for all the help – sincerely appreciated.
The error occurs with any macros that use scripts at all. None of them are doing anything relating to file access. I can try to post them but for the reasons below I don’t think the problem is in the macros.
I should have been clearer about what happens: the macro as a whole doesn’t “fail”, but the variables it uses scripts to assign values to get filled with the error messages.
peternlewis’s suggestion of using osascript to run a minimal Finder script was brilliant. For reasons I don’t really understand, it (a) produced the same error, but then (b) cleared the problem so when I reran the same command the error did not occur, and the macro worked again.
/Volumes/Users is not, I think, a “fake” volume. The backup is done by Carbon Copy Cloner, not my own script. But it mounts it as private. I think sudo umount’ing it (when the backup was over) also worked, but I’ll need to check when the error recurs.
So – to make sure I understand it correctly – you have a volume “Users” (probably on an external disk) which gets mounted by CCC when it starts its backup and is unmounted by CCC when the backup is finished?
And the errors occur from after the volume has been unmounted until you restart the computer?
If it is like that (or similar), I would try this:
Mount and unmount the volume manually via Disk Utility and see if the same script errors appear.
When CCC has unmounted the volume, do you see it still listed when you type ls /Volumes in the Terminal?
If the volume is on an external disk: try to connect the disk differently (e.g. without hub, with another cable, etc.)
In Disk Utility run First Aid on the volume, and also on the disk (for the partition map).
For what it’s worth, I’m seeing exactly the same error when Time Machine has a volume mounted. I think it has to do with some new fangled permissions defaults in Sierra. Either way, it seems that, for reasons beyond my imagination, osascript tries to access (maybe list) the contents of everything in /Volumes, even if nothign in your script does so. (Mine certainly doesn’t touch the file system at all.)
In my mind, this is yet another bug introduced by Sierra, and Apple’s increasingly palpable apathy for Mac OS X Quality.
