Trouble unmounting nfs mounted network drive

I have a Mac Mini 2014 running High Sierra. I am able to mount a nfs network drive (hosted on Linux). I have the following in /etc/fstab on the Mac:


ohprsstorage:/mnt/RAID/Backups /mnt nfs noauto,user,resvport,rw 0 0


However, I have 2 problems.


1) I cannot seem to unmount this drive 'umount /mnt' does not return an error, but the directory is still there when I do 'ls'. What can I do to unmount this drive (I've also tried 'umount -f /mnt')


2) the option "user" is apparently not supported in macos' mount command. I want a 'normal' (not root) user to be able to mount this directory. What is the Mac-way of permitting this?

Mac mini 2018 or later

Posted on Dec 22, 2018 10:10 AM

Reply
26 replies

Jan 3, 2019 3:17 PM in response to etresoft

etresoft: I've used autofs on this Mac successfully, but I don't really want to use that as the 'normal' user. And, my usage of autofs also was implemented using nfs. For root, autofs and SMB won't work because the file server requires Active Directory user authentication and root is not an AD user. For normal users (or root mounting as a normal user), mounting SMB requires the user ID and password, and cifs and smbfs either want the password in the connection string, or it has to be entered from the keyboard. I've looked at Library/Preferences/nsmb.conf, but I find no provisions in that config for user/password. Since this is supposed to be a scheduled background job, the entering from the keyboard option is out. If the password contains special characters, e.g. '%', it cannot be entered in the connection string. I've tried every way I can think of to escape the special character without success. Plus, since the user is required to change his domain password every 90 days, hardcoding in the connection string becomes a bit of a pain to maintain. Nor does 'mount_smbfs -N' with the domain specifier (which *should* use AD authentication) seem to work at all. In short smbfs and cifs are not usable, and are probably not usable in a strict Mac environment with passwords containing special characters.


With nfs the authorization is handled by the server, so no worries about authentication from the client side. If Apple intends to eventually drop support for nfs, that would mean one more step by Apple to distance itself from working in an office environment. Too bad if they head in that direction because I think Apple is poised to make tremendous inroads into the business world because of its superior, Unix-like, OS security versus Windows, especially in light of state actors getting into the hacking business. That, in fact, is the main reason our office is experimenting with Macs. If they continue shutting of access to our enterprise servers we'll have to back off the Mac idea and sadly continue taking our chances with Windows.

Jan 3, 2019 4:48 PM in response to markfoley

I’m sorry, but you seem to be mixing up about half a dozen different things. That makes it very difficult to understand what you are saying and what specifically, you have tried.


NFS is designed for Solaris circa 1997. If that is what you are trying to connect to, then have your IT setup the automounts via autofs.


If you are in an AD domain, then you can use still use autofs with SMB. You would only need root to setup the autofs config files. The actual mounts will happen via user accounts. You would not, and should not, hardcode any passwords. Only a traditional NFS configuration and SMB with AD can do automounts without hard-coded passwords. Everything else, including AFP, needs some kind of crude hack.


If you save passwords in the keychain, then (true) aliases to network volumes can be a viable solution.


I should warn you, however, that even at its best, autofs, and Mac networking in general, is quite flaky. I used the year 1997 because I think that was the one and only time our Solaris NFS network went down. My Mac autofs network configuration would usually need a restart at least once a day. Linux is somewhat between the two. Circa 2013, our Linux network would go down every few months or so.


I don’t know what you mean about "state actors getting into the hacking business”. That is some kind of international espionage thing. If you are sincerely worried about that, and looking for help on Apple Support Communities, then I would respectfully suggest that your worries are misplaced. I suggest paying less attention to security snake oil salesmen.

Jan 4, 2019 10:30 AM in response to markfoley

Well, to comment. I don't see that I am "mixing up about half a dozen different things" at all. I have tried half a dozen different things, at least, most without success.

In a web forum context, you are going to have to take things one step at a time, slowly.


I *am* the IT person at this State Pension Fund administrator and responsible for network security. Organizations like ours are high-priority targets for hackers, including state sponsored actors. We have over 4,000 attempted break-ins to our system monthly. Security is one of our top priorities. I am well versed in the vulnerabilities of Windows and we routinely have a US Military cybersecurity team test our network -- internal and perimeter -- for penetration vulnerability. This same team recommended Mac workstations for a better level of OS security, which is why we are experimenting with Macs. Security in today's world is a *very* serious matter, hardly "snake oil".

Security is very serious, but most security being sold these days is a little more than snake oil. Any server on the Internet is going to have many hacking attempts. That doesn't necessarily mean that they are from state sponsored actors. The US military has some very good cyber security people, but those people do not offer their services for hire. Any successful security snake oil salesman is going to tout his military experience. That doesn't mean it was good experience, or even that it happened.


Apple’s products have a very good level of device security, but they are not appropriate for servers. This sounds like a mismatch between the security being sought and the risks that you face.


These forums are Apple's free, consumer level technical support service. That does not seem appropriate for a state pension fund. There are only a few people in this forum you have any real enterprise admin experience and I am not one of them. I don't know my kerberos from a hole in the ground. Why don't you just call you your Apple rep and get some on site Apple engineering help for this issue?

I said I had successfully used nfs with autofs on Mac, but do not want to use autofs as the mechanism to backup up to network drives. I did not say cifs or smbfs did not work with autofs -- I did not try those, but given my experiences trying those mechanism with password issues I don't know that I could get that to work.

That's why this is confusing. You said you tried NFS I don't want to use autofs because it mounts as root. That's how it works, but fair enough. Then you said you didn't try SMB, because when you tried it it didn't work. That makes no sense.

If you know of the correct syntax for specifying a SMB mount with AD without password, please share that. I've experimented every way I can think of (pretty much all attempts posted in this thread), and done hours of searching and have been unable to accomplish that.

I am no longer working for the organization where I did those autofs mounts. I don't remember it being very difficult. With a Mac bound to the Active Directory domain, automount entries worked pretty well with no password required. I don't know if this type of network connection is appropriate for your use. While the auto mounting itself worked pretty well, other parts of macOS are pretty flaky where networking is concerned. My official recommendation would be to start a new thread and describe what you really want to achieve with these Mac workstations, at a high level. At this point, I think you are getting stuck in the details of one particular rabbit hole. But regardless, here's what I found:


Here is a bootleg link to Apple's old autofs documentation. Grab this link while you can because if any Apple moderator sees it, they might remove it. https://loga.us/wp-content/uploads/2014/09/Autofs.pdf

(I have been actively complain to Apple about their annoying habit of deleting documentation.)


Here are an old thread of mine from back when I did have the autofs working.

autofs not working properly now! - Apple Community

I thought there were a couple of other threads like this, but I can't find them. The forum software was recently rewritten and searching is a bit of a challenge right now.


Someone once posted a link to this page, which was surprisingly accurate: http://blog.grapii.com/2015/06/keep-network-drives-mounted-on-mac-os-x-using-autofs/


And finally, someone once posted a link to this app which might help: ‎AutoMounter on the Mac App Store



This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Trouble unmounting nfs mounted network drive

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.