My workflow acquires archive files on the download and unpacks them using a specific app. I managed to reduce the possibilities to its inability to act on all folders of my home directory, but one. The workflow and the constituent scripts work when run manually.
I checked the Finder and Unix permissions and saw that it’s not the case. For example, folders A and B share drwxr-xr-x@, but the former is a failure while the latter is a success. The ownership is identical too. As such, this fact won’t pinpoint the exact culprit for why the folder action runs idle except for that good folder.
The Console spits out a heap of Automator Runner messages, of which I was only able to make sense of this one:
Automator Runner: Automator Runner is unable to establish a connection to the delegate.
Does it mean I have no chance, or maybe you have one or two recipes to make it go?
First off I would simply try deleting and recreating the folder and see if that changes anything.
Second, presumably the folders are not really named A and B, so I might see if there is anything notable about the actual folder name. Probably not, but I don’t know the details from the description above, so maybe the failing one has a difference to the other like an accented character or something?
Folder A is ~/Downloads, so I cannot delete and recreate it. Folder B is a test folder I made to try the folder action in different locations. When I put B inside ~/Downloads the folder action is still dozed. When I put B inside ~/Desktop it springs to life. None of ~/Music, ~/Movies, ~/Pictures causes the folder action to operate. The disk permissions made no difference either.
The other posts are worth reading too, but the last has some actions you could try - fundamentally removing and re-adding the action but with some extra validation.