With Apple’s server app going the way of the dodo bird, I have been on the lookout for a free software package to run a DNS server on macOS. With the help of Xcode tools and Homebrew, I've found a great solution in dnsmasq.

To set this up, first, install the free Xcode command line tools by running the following command from the Terminal app:

xcode-select —install

And this should prompt you to do the download and install. Then, you can install homebrew by opening a terminal and running the following:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”

Then install dnsmasq by running:

brew install dnsmasq

The dnsmasq config file will be installed at "/usr/local/etc/dnsmasq.conf”

By default, dnsmasq consults the contents of the “/etc/hosts” file for DNS records, but I’d suggest creating your own separate file(s) to keep your DNS host records. To do this, you need to add a line to the config file (for each file you want to use -- you can have more than one) that contains the path to the file where you’ll keep your records, like so:

addn-hosts=/Path/To/Hosts/File/hosts.txt

And then create the text file, with the path and name you specified above, and add DNS records to the file as follows:

192.168.100.1    host1.domain.test
192.168.100.2    host2.domain.test

With each line containing an IP address, a space (or tab), and then the hostname. In this case, a lookup for host1.domain.test would resolve to 192.168.100.1 for a machine using our dnsmasq DNS server.

To make sure dnsmasq starts automatically at reboot, do the following:

sudo cp /usr/local/opt/dnsmasq/homebrew.mxcl.dnsmasq.plist /Library/LaunchDaemons/
sudo chown root:wheel /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
sudo chmod 644 /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

Then you can start dnsmasq with this command:
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

And stop it with this one:
sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

In this configuration, dnsmasq will answer dns requests for any records you've created, but will pass requests for machines it doesn't know about up to whatever DNS servers are listed in your Mac network prefs.
​
Good luck!

Getting Windows clients to connect to macOS servers is usually fairly straightforward, but there are a number of issues that can cause problems, and can be tricky to track down. For such scenarios, I’ve put together this list of things to try when you're troubleshooting this kind of situation.

First of all, just having the proper URL to connect to the server is important. So if your server is called “MY-SERVER” and has an IP address of 192.168.1.1, and your share is called “MyShare,” you can format the URL in either of the two following ways:

\\192.168.1.10\MyShare
\\MY-SERVER\MyShare

When you try this and your Windows clients can’t connect to the Mac server, here are a few things you can try:


1. Enable NTLM authentication on your macOS server:

Enable NTLM with:
sudo serveradmin settings smb:ntlm auth = "yes"

If you’re using a very old Windows client version, can also try adding Lanman support, as below:
sudo serveradmin settings smb:lanman auth = “yes”

And you can confirm that the change worked by running:
sudo serveradmin settings smb


2. Add server NetBIOS / workgroup name to authentication credentials:

Depending on the version of Windows you’re using on the client machine, you may need to include the server NetBIOS name (or workgroup name) before the username, separated by a backslash (“\”), as part of the login credentials.

So for username "dave" with NetBios name “MY-SERVER, the full "name" in the login window would look like:

MY-SERVER\dave

You can check the NetBios name of your server with the "serveradmin settings smb” command, and look for the "smb:NetBIOSName” parameter in the output.


3. Allow both NTLM v1 and v2 authentication on your macOS server:

The versions of the NTLM protocol that a Mac server will allow are specified in the following file:

com.apple.GSS.NTLM.plist

Which is located in "/Library/Preferences.”

However, this file doesn't exist by default in a new installation. So in order to enforce this authentication parameter, you need to create the file in that location, with the following contents:
 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
      <key>NTLMv1</key>
      <true/>
      <key>NTLMv2</key>
      <true/>
</dict>
</plist>

Give the machine a reboot, and this will allow Mac OS Server to accept both NTLMv1 and NTLMv2 authentication.


4. Enable ACL support:

One other handy tip when you’re connecting Windows clients to a Mac server (this time related to authorization and not authentication) is to enable ACL support for the SMB service (as I mentioned earlier this year in this post), which can ameliorate all kinds of permissions issues that plague only Windows machines. You can do this as follows:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool YES

Disabling ACL’s again (should you need to) can be done like so:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool NO

After doing either one, I’d suggest restarting the SMB service on your server, as follows:

sudo serveradmin stop smb
sudo serveradmin start smb

After running either of the above, you can re-issue the “sudo serveradmin settings smb” command to make sure the changes took.

Sometimes it can be really handy to have the Xcode command line tools installed on your Mac without having to download and install the entire Xcode package from the Apple App Store first. For example, if you want to use a package management system, such as HomeBrew or MacPorts, you'll need the Xcode command line tools (which is only about 100 MB as of this writing), but there's no need for the entire 4.5 GB Xcode package.

Installing the Xcode command line tools by itself is actually very easy to do, by running the following command in the Terminal app:

xcode-select --install

When you run this command, you should see a Finder dialogue asking if you'd like to download and install the Xcode command line tools. Just follow the prompt and voila! No need to install the hefty Xcode package first.

In macOS version 10.11.x (El Capitan) and later, Apple has removed the "repairPermissions" and "verify" switches from the "diskutil" terminal command. There are still ways to run these two functions, but they are no longer called from within the diskutil command. You can run the "verify" function on a volume with the following command:

sudo /usr/libexec/repair_packages --verify --standard-pkgs /

And you can repair permissions with this one:

sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /


​ 

This is a quick and easy tip, but also a super handy one, as the macOS is often less than graceful in the way it's able to unmount volumes (or give you useful information when it's not able to!)

To force a volume to unmount, you can open the Terminal application and run this command (of course, you want to replace "Volume_Name" below with your actual volume name:

diskutil unmountDisk force /Volumes/Volume_Name

By default, SMB ACL’s are disabled on Mac OS X Server, and there are many situations where it can be helpful to enable them. To see whether SMB ACL’s are already enabled on your server, you can issue the following terminal command (as always, be sure to make a full backup of your server before making any changes):

sudo serveradmin settings smb

If SMB ACL’s are enabled, you’ll see a line that contains “AclsEnabled = yes” as part of the output. If they’re not enabled, you’ll either 1) not see a line starting with “AclsEnabled” or 2) you’ll see a line that contains “AclsEnabled = no.”

To enable ACL’s you can issue the following command (I’ve tested this on Yosemite 10.10.x running Server app v. 5.0.x, and El Capitan 10.11.x running Server app v. 5.2.x):

To enable ACL’s:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool YES

To disable ACL’s:

sudo defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server AclsEnabled -bool NO

After doing either one, I’d suggest restarting the SMB service on your server, as follows:

sudo serveradmin stop smb
sudo serveradmin start smb

After running either of the above, you can re-issue the “sudo serveradmin settings smb” command to make sure the changes took.

Some applications require an older version of the Java runtime environment than the one that ships with Mac OS 10.10.x (Yosemite) and later.

Downloading and installing Java SE 6 runtime (a version that is commonly needed by these older Mac Java apps)  is easy. Apple has left the installer online, which is available for download here:

https://support.apple.com/kb/DL1572?locale=en_US

The LDAP (lightweight directory access protocol) database is an essential part of a Mac Server Open Directory environment. As with any database, it is prone to corruption if the LDAP database server isn’t closed properly, which often happens with system power loss, a disk, process or application crash, or any other kind of improper shutdown.

If you’re seeing the following errors in your Mac server slapd logs, that may be an indication that you need to recover the LDAP database:

PANIC: “fatal region error detected; run recovery”
DB_RUNRECOVERY: Fatal error, run database recovery (-30974)

If you see this error, you can issue the following commands from the Terminal App to recover from the last Open Directory backup (I have tested this on Mavericks 10.9.x, Yosemite 10.10.x, and El Capitan 10.11.x server systems - be sure to choose only one of the two disk permissions repair options below) as with trying anything, be sure to completely backup your system before trying this!)


sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
(10.10.x and earlier:) diskutil repairPermissions /
(10.11.x and later:) sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /
sudo db_recover -cv -h /var/db/openldap/openldap-data/
sudo db_recover -cv -h /var/db/openldap/authdata/
sudo /usr/libexec/slapd -Tt
sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

My goal here was to take an existing local Mac account on my laptop, and convert it to an Open Directory mobile account that had home folder syncing capabilities with my Open Directory server. I’ve found the mobile account syncing features on Mac server to be fairly unreliable and flaky, so I just wanted to bind my machine, and then do manual syncs of selected folders (as opposed to having automated syncs happen at login/logout, and syncing my entire home folder and preferences, which I’ve never found to be very stable or reliable).
 
This was tested on a Mac running Server version 5.1.7, and El Capitan 10.11.6, and a desktop client running Mac OS X El Capitan 10.11.6.

This article assumes you have a functioning Open Directory environment, including a properly configured local DNS server with forward and reverse records for the servers and clients involved. Also, you’ll need a share set up on the server that’s configured to share home folders over AFP over the network (you can set this up under the "Filesharing” section of the Server.app).

Lastly, if you’re going to try these steps, make sure to back up all your data first, just in case anything goes wrong in the process!

The steps I used are as follows:

1. Back up all the data on the client machine that contains the user account you’re converting from local to network mobile.

2. Create an open directory account on your server, and choose the user network share as the home folder location. In my case, I just shared the local “/Users” folder on my OD server machine. Also, it will be simpler if the short name of the network account you create matches the short name of the local account on your client machine that you're going to convert, and it will be even simpler still if the passwords match, although this isn’t necessary.

3. Log into your server Profile Manager (http://your.server.name/profilemanager), select the “Users” icon on the left, choose the new user you created, then click “Settings > Edit,” then scroll down to “Mobility” on the left.

4. Under the “Account Creation” tab, check the “Create mobile account when user logs in…” box. I chose to also check the “Require confirmation” box, set “Create home using:” to “local home template,” and left the FileVault option de-selected. Choose “on startup volume” for “Home folder location."

5. Then click the “Rules” tab, and de-select *all* the Sync options under the “Preference Sync,” and “Home Sync” tabs (for now). Click the “Options” tab, and set “Sync in the background” to “Manually” for now, and check the “Show status in menu bar.” Be sure you’ve saved all your changes.

6. On your client machine, log in as an admin user that’s not the same as the user account you’re going to convert. Then go into the "Users & Groups” system preferences pane, and delete the local account you’re going to convert (did you back up your data?!?). When prompted, choose the “Don’t change the home folder” option. You’ll notice when this is done (it may take some time), that your user folder has been re-named with “(Deleted)” appended to your username. Leave that as-is for now.

7. Still in the "Users & Groups” pane, click the “Login Options” icon on the bottom left, then click the “Join” button to right of “Network Account Server, and bind your client machine to the Open Directory server, and then reboot your client machine.

8. Log back into the client machine as the new Open Directory user account you’ve created. You’ll be prompted to create a new mobile account, and a new home folder will be created, with default dock and desktop settings. After the sync completes, make a backup copy of the following files, which should all be located in:

"/Users/<your_user_name>/Library/Preferences/“ :

com.apple.MCX.plist
com.apple.homeSync.plist
com.apple.mcxMenuExtras.plist

9. Log out of your new mobile account, and log back into your client machine as another machine admin. Go into the users folder, and you should see the newly created home folder for your mobile account. Re-name that folder (i.e “johnsmith” to “johnsmith-old” or something like that), 

10. In the “/Users” folder, re-name your original user data folder to match the network account name you created — it’s important to re-name it so it matches the short name of the new mobile account you created on the server (i.e. from “johnsmith (Deleted)" back to “johnsmith”). This will be your new mobile account user folder. This will, again, require a machine admin name and password.

11. Take these three backed up files (from above):

com.apple.MCX.plist
com.apple.homeSync.plist
com.apple.mcxMenuExtras.plist

and copy them into the Preferences folder inside your new mobile account user folder, located at (i.e.):

"/Users/johnsmith/Library/Preferences/“

12. Open the “Terminal” app, and change permissions for your new mobile account folder, using the following command (replacing “johnsmith” with your actual user short name). You’ll be prompted for your admin password.

sudo chown -R johnsmith:staff /Users/johnsmith

13. When this is done, reboot your machine and log in with your new mobile account credentials, and then go back into the “Users & Groups” system preferences pane, click your user account name, and then click the “Settings” button to the right of “Mobile account.”

14. For my purposes, I made sure “Sync” was set to manually (which it should be, based on the steps listed above), and I made sure that the "at login" and "at logout" boxes were both unchecked. I then chose the “Only selected folders" radio button, and only selected the folders below that I wanted to sync, and checked the “Show status in menu bar” checkbox."

15. At this point, you should be able to pull down the home sync Mac menubar item, and choose a manual sync of all the folders you selected in step 14.

Good luck, and would love to hear how this works if you want get in touch with some feedback! 

For years, finding a TCP/IP router that has VPN Server functionality that works well with Mac and Windows remote clients (without 3rd party client software) has been tricky.

The easiest and most compatible option has been to use the PPTP protocol, but the encryption used by PPTP was broken years ago, and the protocol is being deprecated, and support for it is slowly but surely being removed from both routers and operating systems.

Another much more robust and secure option has been to use the L2TP/IPsec protocol, but implementing and configuring this in many of the popular SMB routers is complex and difficult.

Another option has been to use free or paid 3rd party software, such as VPN Tracker or IPSecuritas, but this also adds another level of complexity to the VPN mix.

In August 2015, Peplink released a firmware update, version 6.2.2, to their “Balance” line of routers.

http://www.peplink.com/support/downloads/balance-firmware-and-user-manual-6-2-2/

With this release, you can easily set up an L2TP/IPsec VPN server, and remote Mac and Windows clients can connect to it without 3rd party software. I’ve tested it with a few customers, and it works well, and so Peplink is my new go-to for my SMB consulting clients.