Sure. The question is whether the bug only appears when using the installer, which I presume starts some kind of system service, as opposed to running jenkins.war from a shell. And whether the bug is reproducible (in either or both Jenkins startup modes) when the build is run on a slave—even one on the same Mac system, but using the SSH launcher so that the process hierarchy is rooted at the SSH daemon.
By the way searches for nohup: can't detach from console turn up various hits, all specific to Mac OS X, though not this exact error message. Unfortunately the message fails to specify which file or directory could not be found; as a C app there is no stack trace either. I could not find this error here; perhaps Mac OS X ships with a proprietary version of this tool.
The simplest fix would probably just be to remove the use of nohup, at least when running on Mac OS X, as it may not really be effective anyway (cf. JENKINS-25503): our main concern is preventing SIGTERM on the master or slave process from being applied to child processes, whereas SIGHUP is less likely to be sent to begin with. However before doing that I would like to ascertain how serious of an issue this is, by checking under what conditions it is reproducible.