Like this:

I had one of my customers report a problem today after applying software updates to his Mac. His Mac had been able to automount certain network shares via NFS before the updates, but was unable to access those shares following the updates.

I connected remotely to the Mac and verified that I was unable to manually mount the NFS mounts.

When I tried to run the showmount command to get a list of the available NFS mounts on the server, I also received a timeout message:

I was about to send this on to the team that handled our NFS shares, when I remembered I hadn’t verified that I could access the server. Sure enough, I couldn’t:

I could ping Yahoo however, so I could contact the internet.

So I couldn’t access an internal network resource, but I could access the internet. What made this puzzling was that I was connecting remotely to the Mac via the IP address associated with this person’s Ethernet address. This IP address should not have had issues accessing internal network resources. What had happened? For more, see below the jump.

Like this:

While working on some documentation, I noticed a behavioral change in macOS Sierra’s sudo tool that was different from how sudo behaves on OS X El Capitan.

El Capitan

if you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you won’t be prompted for your password in either Terminal session until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:

Sierra

If you run sudo in one Terminal session and authenticate with your password, then open another Terminal session and run sudo, you’ll get asked for your password in the second Terminal session too. Meanwhile, in the first Terminal session, you won’t get prompted again until the normal sudo authentication timeout. To see what this behavior looks like, please see the video below:

The difference is that Apple has compiled sudo on Sierra to include the tty_tickets option, which ensures that users need to authenticate on a per-Terminal session basis.

Like this:

While working with different versions of Mac OS X and macOS, it’s often been useful to me to be able to export the contents of a particular command line utility’s Unix man page to a plain text file. Man pages are the built-in documentation method available in Unix-based systems, so Apple documents how to use the various command line tools used by the operating system using this documentation method.

Exporting to a plain text file allows me to compare macOS Sierra’s man page for a particular command line utilty to a exported copy of the same utility’s man page from OS X El Capitan and see where changes to the man page have been made. This comparison is made by using diff, or other file comparison tools like Kaleidoscope, which helps me quickly spot where Apple has made changes to their documentation.

To export man pages to a plain text file, I use the col command line utility to read the contents of the man page in using stdin, then export out to a plain text file using stdout As an example, here’s how to use col to export the diskutil man page to a new plain text file named diskutil.txt:

man diskutil | col -bx > /path/to/diskutil.txt

In this case, col‘s -b and -x functions are used to make sure that the formatting for the diskutil man page remains intact when exported to the plain text file.

Like this:

In some environments, it may be desirable to give users admin rights while restricting those users from being able to run commands with root privileges while using the command line.

A way to achieve this “admin user in the GUI, standard user on the command line” method is to edit the /etc/sudoers file. This is the configuration file referenced by the sudo command line tool, which allows a user with the correct sudo rights to execute a command with root privileges, or using another user account’s privileges.

By default, all user accounts with admin rights on both OS X and macOS have full rights to use the sudo tool. By removing those accounts’ rights for sudo from the /etc/sudoers file, user accounts with admin rights will not be able to run commands with root privileges using the sudo tool. For more details, see below the jump.