9

I have FreeBSD (test.local) box configured as NFS server. And I'm trying to mount its NFS sharing form my mac (hhmm.local)

/nfs     hhmm.local

/nfs has 777 permission.

And I checked from mac that it's working,

hhmm:~ Eonil$ showmount -e test.local
Exports list on test.local:
/nfs                           test.local
hhmm:~ Eonil$ 

But when I try to mount it,

hhmm:~ Eonil$ mount_nfs test.local:/nfs ~/nfs
mount_nfs: can't access /nfs: Permission denied
hhmm:~ Eonil$ 

Wow. I cannot figure out why this doesn't work. What should I do?

  • I was seeing permission denied on the AWS storage gateway NFS file share, issue was that my IP was outside the the allowed share access client CIDR range – storm_m2138 Feb 22 at 18:00
5

I had the same issue with mount_nfs: can't access /: Permission denied on OS X 10.6.8 and even with the resvport option it still failed however modifying the nfs server export mount to use the insecure option worked.

2

I solved this problem with this blog post: http://www.cyberciti.biz/faq/apple-mac-osx-nfs-mount-command-tutorial/

Core solution was giving an option resvport on mounting option. NFS volume mounted magically!

  • Was having this same issue; the resvport option works fine if you only plan on mounting via the CLI. If you want to mount via Mac OS X's finder, you need to add the insecure option on the server side, as @Cas mentions. There is no way to specify resvport via finder, and the ability to mount and use advanced options has been removed from "Disk Utility", so it seems as the server side fix is the only viable solution for GUI connecting. – Will Jun 22 '15 at 19:35
2

Assume that host 10.18.14.27 running NFS has shared path-

/home/siddiquim

On your mac, Try:

$ sudo mount -o resvport,rw  -t nfs  10.18.14.27:/home/siddiquim folder_207

Verify that contents are visible:

$ ls -ltr folder_207
0

my problem solved, NFS to mac High Sierra 10.13 Change on server NFS /etc/exports, put your client IP. Ex: ip server:192.168.1.2 client ip:192.168.1.10 on server, sudo vi, /export/www 192.168.1.10(rw,insecure,root_squash,no_subtree_check,async)

  • As long as the server can resolve the client’s hostname (i.e., ping hhmm.local works),  there’s no reason for this to make a difference. – Scott Feb 27 at 5:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.