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.
  • @ChristopherApple Unfortunately not. I'll answer my own question when I will make it work.
    – MokaT
    Jun 30, 2019 at 10:52
  • Hey, some interesting info here, I found out my issue was not Mojave related, but an issue using iTerm and tmux. If I ran in just the default Terminal without using tmux it worked as intended. I'm not sure if that helps you, but I'd say try to reduce the complexity of your environment and see if that helps at all, default bash shell, default terminal, no tmux or anything else Jul 18, 2019 at 22:08
  • @ChristopherApple My issue seems Mojave related, I use the default terminal shipped with Mojave. Some guys from Apple confirmed this bug, as a workaround you can copy your plugin's in /System/Library/Components instead of /Library/Audio/Plug-in’s. This works, but for this you need 1) To disable System Integrity Protection 2) to reboot after moving the component's in the system folder. This is not a viable solution for me.
    – MokaT
    Jul 23, 2019 at 7:33

3 Answers 3


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, 2019 at 15:08
  • Really good stuff here! Definitely implementing it on our build machines Apr 16, 2020 at 19:38
  • Hi @Stephan Valentan, first thanks a lot for your solution, it was very helpful. We used it a few months ago and it worked perfectly, but now that our builders have been updated to Big Sur, it doesn't work anymore, even the daemon server can't manage to retrieve the non-Apple components. I'd be curious to know if something similar happened to you. Cheers Dec 8, 2021 at 15:35
  • 1
    I'm glad this could help! After using the python server for a while we actually took a different approach. Since using jenkins, we were able to connect our build nodes to the jenkins server using the java web start option. The slave node connects to the master using a daemon on startup using a dedicated (non-SSH!) connection, which allows us to directly call the auval command without going through the ssh server. We're using this approach on our macOS 11 build nodes. Dec 9, 2021 at 16:13

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, 2019 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, 2019 at 1:30

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 .