While we make every attempt to ensure a trouble-free experience with NoMAD there are times when your environment isn’t what NoMAD is expecting, or when NoMAD has a bug.
When you do encounter these moments, here’s a few tips and tricks to get things back on the straight and narrow.
The first step in any troubleshooting process is to run NoMAD from the command line and put it into verbose mode. It’s perfectly acceptable to do this while other copies of NoMAD are running, you’ll just have multiple icons in the menu bar.
To launch NoMAD in verbose, open up a Terminal window and put the full path to the NoMAD binary, not just the application bundle with -v. For example, if NoMAD is installed in the Applications folder you’d use this in Terminal.
This will launch NoMAD and put all logs directly into that terminal window that’s already open. This makes it very simple to gather just the NoMAD logs and see events happen in real time.
Most issues are at least identifiable in the logs. Some things may jump out, as verbose logging should log a lot of events and information as NoMAD works. The other issue that’s typically encountered is an “illegal instruction 4” error. This typically represents a variable in the code that was expected to have a value, but is empty. NoMAD has a number of checks for these, but there’s always the chance that we’ve left something out, or you have a setting that we’ve never seen not have a value before.
Additional CLI options
There are some other flags you can use when launching from the CLI as well:
- “-prefs” – On version 1.1.4 and newer this will print out all preferences as NoMAD sees them including if they are being forced via a configuration profile or not.
- “-rawLDAP” – This will list all LDAP queries and responses as NoMAD works. You’ll get to see the actual ldapsearch syntax being used and the full LDIF response from the LDAP server.
- “-shares” – This will list all file shares as seen by NoMAD and give you more verbose output specific to the file shares menu.
All of these options can be used together or individually when launching NoMAD from the CLI.
First of all… the vast majority of issues we see with organizations using NoMAD are because of configuration issues. The vast majority of the configuration issues are from malformed configuration profiles, scripting defaults instead of using a configuration profiles, or managing preference keys that aren’t meant to be managed.
The simplest way to test for this is to pull the configuration and see if the problem persists. If the problem is with the configuration itself, the next easiest step is to attempt to validate the XML, if you’re using a configuration profile.
Also, a good rule of thumb when dealing with configurations in general is to manage only as much as you absolutely need to. For example, you generally shouldn’t have any settings in NoMAD that are set to a blank value.
Network and AD
After configuration issues, the next most common trouble is with either the network or the AD configuration that’s in use. By now NoMAD is rather resilient to any network outages and other issues. More common are more “exotic” AD configurations. While we’ve seen a lot of these, and generally have work arounds for most… there’s always new ones.
If you’re a support customer, please use the support email and we’ll get to work on figuring out what’s going on for you. In addition, or if you don’t have a support contract, you can file an issue on the NoMAD GitLab page or hop into the #nomad Slack channel at macadmins.slack.com.