I was successfully validating audio unit plugins with OSX 10.11 over SSH. On my new machine which runs OSX 10.14 (Mojave) everything works fine until I try to validate a plugin from an SSH connection. I use the same command in the same directory both in local and over SSH.

/usr/bin/auvaltool -v aumf MyPl Loco

The thing is, using SSH, auval do not detect my plugins (/usr/bin/auvaltool -a), but only Apple default ones. When doing the same on the screen sharing, my plugins are in the output.

  • This does not seems to come from $PATH.
  • This does not seems to come from permission (I have tried a chmod 777 on every .component)
  • This does not seems to come from group/user (I have tried to chown it to diferent user)
  • This does not seems to come from administration (I have tried to sudo it)

So my question is, do you know any SSH security limitation that can break my execution of auval and auvaltool ? What can be different on SSH that could make some execution behaviour changes ?


EDIT: How to reproduce ?

  • Install any non-apple AU plugin.
  • Launch a terminal and:
    • "auval -a" will output the previously installed plugin.
    • "ssh localhost" will connect to you machine through SSH
    • "auval -a" will NOT output the previously installed plugin.
  • 1
    If you echo $PATH locally and via SSH, are they the same?
    – Allan
    Mar 5 '19 at 13:28
  • 1
    Yes, the output is '/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin' both in screen sharing and on ssh.
    – MokaT
    Mar 5 '19 at 17:02
  • 1
    Please post the contents of your ~/.bash_profile and ~/bashrc to your original question.
    – Allan
    Mar 5 '19 at 20:26
  • 1
    Done (this is jenkins builder)
    – MokaT
    Mar 6 '19 at 7:49
  • 1
    Which one is that for? Those are different files and read in different instances.
    – Allan
    Mar 6 '19 at 12:19

This is a long shot, but I once had to install tmux with brew install tmux (and I already had https://brew.sh set up and ready to run) so that I could graphically log in and establish a terminal session for the user in question.

With fast user switching, you can then return to the log in screen - leaving that one user console session blessed with full GPU and full graphical console permissions and then ssh in to attach to the existing TMUX sessions.

Hopefully someone has a more direct answer, but after several days of bounties and some great comments trying to back into the answer, I wanted to get on the record that a graphical log in does have higher powers and permissions and you just might need that for now if no-one has a better fix for this.

  • Hi bmike. Unfortunately I ran into a very similar issue just with tmux on my local machine, so I don't think this will help here. If they fix something, you can check it out in my bug report here: github.com/tmux/tmux/issues/1847 Jul 18 '19 at 22:10
  • 1
    That’s disappointing @ChristopherApple - I’m glad you mentioned this and will follow for updates. I would upvote your answer if you want to make the above into one. It might help others find the issue
    – bmike
    Jul 19 '19 at 1:30

I found another workaround which is still not pretty, but less invasive. I implemented a small python-http server which expects the auval arguments as url-get parameters. If this python-server now is started using a non-ssh session, it is possible to validate all plugins using the http-get call. Below is the code for the small server.

from http.server import HTTPServer, BaseHTTPRequestHandler
import subprocess
from urllib.parse import urlparse, parse_qs

import traceback

def run_auval(params):
    arguments = ["auval", "-v", params["type"], params["subtype"], params["manufactor"]]
    print("Running AUVal: {}".format(arguments))
    process_return = subprocess.run(arguments, capture_output=True)
    return process_return.stdout + process_return.stderr, process_return.returncode

class SimpleHTTPRequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        raw_params = parse_qs(urlparse(self.path).query)
        params = {}
        for key, value in raw_params.items():
            params[key] = value[0]

            output, return_code = run_auval(params)


if __name__ == "__main__":
    httpd = HTTPServer(("", 8000), SimpleHTTPRequestHandler)

You can then use wget or an equivalent from an SSH session to get the result of au validation.

With the server running, output goes to auval_log.txt where you can search for FAILURE or SUCCESS:

wget "http://localhost:8000?type=aufx&subtype=Abcd&manufactor=Dlby" -O auval_log.txt

This is equivalent to running

auval -v aufx Abcd Dlby

but without the SSH issues

  • 1
    Pretty neat. Thanks for sharing your workaround Stephan ! It's easier to do than my accepted answer and as you say, less invasive. Awesome.
    – MokaT
    Dec 11 '19 at 15:08
  • Really good stuff here! Definitely implementing it on our build machines Apr 16 '20 at 19:38

There is definitely a bug in OSX 10.14 and higher. Since Apple seems not in the way to fix it, I'll post the workaround as an answer.

The workaround here is to copy the AU components you need to validate through SSH in /System/Library/Components/, and then sudo killall -9 AudioComponentRegistrar in order to force a rescan on the next auval run.

For this, you will need to disable System Integrity Protection which forbid you to change the System directories.

Just for you know, AudioComponentRegistrar is a deamon, but auval is launching it if needed.

Note that you can find some nice information in this gist (it explains a workaround for iTerm2 users too).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .