Weird file access problem running a script that accesses a file in my home folder.
Error is
Script Error
System Events got an error: Can't get disk item
The weird thing is the path it’s trying to access, which has stuck a “.nofollow” in the path:
"System:System:Volumes:Data:.nofollow:
Users:applesource:Desktop:blahblahblah"
Anyone know why the .nofollow is there?
Your path is so weird. Is the name of the disk “System” or “Data”?
applesource,
I had the same question before, and asked Mr. Howard at The Eclectic Light Company about it.
He gave me the following reply regarding the replacement with nofollow:
– Quote begins
This appears to be a change in recent macOS, made as a mitigation of a security vulnerability. It’s apparently to stop symbolic links from following the path. Although it seems an odd behaviour, I don’t know of any way of fixing – given that it’s to address a vulnerability, that is perhaps to be expected.
– Quote ends
I can’t say anything for certain, but it seems to be triggered when the target path carries the extended attribute:
com.apple.provenance
You can easily check for the presence of this attribute using Mr. Howard’s tool:
xattred
Hope this may be of some help.
Thanks for that.
This error appears intermittently for me. Mostly, the script works normally and creates a viable path.
I’m guessing the reason I get the “System:System” part is because of the way APFS structures the drive. Here’s a screenshot of diskutil on my internal SSD
After that, I found a way to restore a folder that gets isolated under /.nofollow,
so I’m adding the details here.
This depends on your environment and system settings.
This issue does not occur on every macOS installation.
If SIP is disabled, this does not apply.
Create Folder A and Folder B.
Then move Folder A inside Folder B.
When you do this, Folder A gets isolated under /.nofollow.
Because of that, opening Folder A from Finder will actually open /.nofollow,
and you can no longer access Folder A directly.
Reproduction scrip (macOS26.1)
use AppleScript version "2.8"
use scripting additions
set aliasTempDirPath to (POSIX file "/private/tmp") as alias
#Make DIR A
tell application "Finder"
set aliasDirA to (make new folder at aliasTempDirPath with properties {name:"AAAAA", owner privileges:"read write", group privileges:"read write", everyones privileges:"read write", comment:"You can delete this folder.", description:"It's a folder generated by the script. It's okay to delete it.", label index:3}) as alias
end tell
#Make DIR B
tell application "Finder"
set aliasDirB to (make new folder at aliasTempDirPath with properties {name:"BBBBB", owner privileges:"read write", group privileges:"read write", everyones privileges:"read write", comment:"You can delete this folder.", description:"It's a folder generated by the script. It's okay to delete it.", label index:3}) as alias
end tell
#Move Folder
tell application "Finder"
move folder aliasDirA to folder aliasDirB
set aliasMoveDirA to (folder "AAAAA" of folder aliasDirB) as alias
end tell
tell application "Finder"
open folder aliasMoveDirA
end tell
-->OPEN /.nofollow
This behavior only affects Finder’s view, which treats the folder as if it were isolated under /.nofollow.
In reality, the folder still exists in its proper location.
Run touch on the folder that was isolated.
(There are probably other methods as well.)
I should also mention that I don’t fully understand every behavior related to /.nofollow. What I’ve learned is that isolation under /.nofollow is tied to application behavior.
In this particular case, a folder that was moved using Finder functions from within an AppleScript was isolated under /.nofollow for security reasons. I’m sure other applications can trigger similar behavior, and the details will vary case by case.
It just so happened that, for this specific situation, running touch on the folder was enough to restore it.
It might just be something that happens only on my system,
but if this information helps anyone, I’m happy.
