Checking if NFS share is mounted on client

Hi
I would like to check on my nfs server if a nfs share is mounted on a client.
If I mount a share it is listed in /proc/fs/nfs/exports on the server, but it looks like it's not updated when the share is unmount; it still contains a line with the clients ip.

It looks like /var/lib/nfs/rmtab is the right file to check

Similar Messages

[SOLVED] NFS share not mounting at boot

Hi All,
I have an NFS share listed in fstab and it doesn't mount at boot; however, when i mount -a, it mounts fine. Any thoughts?
Thanks.
Shawn
Last edited by shawn.abdushakur (2011-05-06 12:21:27)

@damnshock: Good point . Here it is:
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
devpts /dev/pts devpts defaults 0 0
shm /dev/shm tmpfs nodev,nosuid 0 0
#/dev/cdrom /media/cd auto ro,user,noauto,unhide 0 0
#/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0
#/dev/fd0 /media/fl auto user,noauto 0 0
/dev/sda1 swap swap defaults 0 0
LABEL=arch / ext4 defaults 0 1
UUID=c1a8b2e0-bf9e-4382-ac4e-15c2aec65090 /srv/nfs ext3 defaults 0 0
/srv/nfs/shawn/Documents /home/shawn/Documents none bind
/srv/nfs/shawn/Downloads /home/shawn/Downloads none bind
/srv/nfs/shawn/Music /home/shawn/Music none bind
/srv/nfs/shawn/Pictures /home/shawn/Pictures none bind
/srv/nfs/shawn/Videos /home/shawn/Videos none bind
xbmc:/srv/nfs/watch /home/shawn/Downloads/torrents/watch nfs rsize=8192,wsize=8192,timeo=14,intr

Cannot mount NFS shares using the Finder

Hello all!
I have a directory structure on a OpenSuse NFS Server which I like to browse/read using my MAC OSX 10.5.6. It works like a joy when I am mounting the NFS share on the command line using "sudo":
sudo mount -o resvport nfshost:/full/path/NFS/share /My/mount/point
However, this is kind of unconvenient as I need to start Terminal and sudo always asks me for the root password. I would appreciate to mount the NFS share just as I mount afp shares using the Finder. But the NFS share is neither searchable using the Finder nor does it show up in the list of host in the side bar of the Finder.
Does anyone has an idea how to solve that? Thx for your information!

The problem is most likely that your NFS server requires that connections come from reserved ports but you can't connect that way from the Finder GUI.
Your example:
sudo mount -o resvport nfshost:/full/path/NFS/share /My/mount/point
shows that you need to use "-o resvport" and that you need to do the mount as root. (This is because the networking stack requires you to be root to get a reserved port.) When you try to mount it via the Finder, you can't specify any mount options like "-o resvport" and even if you could the mount would fail because the Finder isn't running as root.
My first suggestion would be to change the configuration of your server to not require clients to use reserved ports for the NFS protocol. Unfortunately, Linux chooses to call that option "insecure" even though requiring the use of reserved ports (using "secure") doesn't actually make NFS more secure.
Alternatively, you could configure the mount to be performed by something that does do the mount as root - e.g. automount/autofs. You can do this by configuring the mount on Directory Utility's "Mounts" section... you'll want to add "resvport" to the "Advanced mount options" field.
HTH
--macko

[SOLVED]Unmounting NFS shares before network is brought down

I'm using networkd and I have enabled the network-wait-online service, so at boot-time my NFS shares are mounted after the network becomes available. That all works perfectly.
However, it doesn't work the other way around i.e. when shutting down. The network is brought down, and then systemd attempts to unmount the shares, which obviously doesn't work.
Have I missed a step?
Last edited by tomk (2014-07-04 12:31:47)

Strike0 wrote:I'm not using it, but reading your topic made me associate the "nfs-client.target" mentioned here: https://mailman.archlinux.org/pipermail … 26393.html
I checked this out too, but it has a lot of 'Wants' that I don't really need. Maybe I could fix it up, but I use autofs so I don't have this problem (the real autofs, not the systemd one).
% systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
[Unit]
Description=NFS client services
Before=remote-fs-pre.target
Wants=remote-fs-pre.target
# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
Wants=rpc-gssd.service rpc-svcgssd.service
Wants=nfs-blkmap.service rpc-statd-notify.service
Before=rpc-gssd.service rpc-svcgssd.service nfs-blkmap.service
[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.target
Last edited by WonderWoofy (2014-06-21 01:00:04)

Pcnfsd authetication in NFS share

I have a G5 10.4.8 serving a NFS share. The one client is a Win95 box running NFS Maestro . It has worked before but in rebuilding it, I'm stuck. The client requires pcnfsd authentication but inetd.conf states that (rpc.) pcnfsd is not yet implemented in OS X. NFS Manager has nothing as well. Is there a way to fix this?
G5 Mac OS X (10.4.8) Not OSX Server

This is frustrating!.. I've managed to get that working but i have a different issue now ..here is what i have done in details:
Server: MAC OSX 10.6.8.
Server was standalone and then I bounded to the AD then promoted to Open Directory Master without kerberos realm - as it is the AD is the one that holds the accounts.. that's how it should be correct ?
Disk utility: I mounted the NFS share and in WGM i enabled file sharing on the NFS share via AFP, and now it shows under WGM - Home tab as: afp://xserve.mydomain.com/homes
- for the clients, I bounded them to OD first for MCX and then to AD.
Directory Utility: settings for both "client & server"
*Create mobile account at login - false
*Force local home directory on startup disk - false
*Une UNC path - True with AFP protocol.
Server Admin:
* AFP is enabled on the NFS share "homes" and its auto-mounted.
* Open Directory Master:
- LDAP Server is running
- Password Server is running.
- Kerberos is stopped.
Workgroup Manager:
* I selected the test user "adtest" and assigned the home folder which is:
Home URL: afp://xserve.domain.com/homes/adtest
Full Path: /Network/Servers/xserve.domain.com/homes/adtest
and when i click on Create Home Now, it did create the user home directory under the NFS share which is auto-mounted
Active Directory Server:
under the adtest user - profile tab, i see: \\xserve.domain.com\homes\adtest
Problem:
- when i try to login with adtest user from the client, i get the error message:
"You are unable to login in o the user account "adtest" at this time - logging in to the account failed because an error occurred."
Troubleshooting:
1- logged in with local admin account and typed id adtest in terminal.. it shows all user attributes and groups, which means the machine is bound correctly to both AD & OD
2- when I change the home for the user to the the default "/Users".. i can login just fine with the adtest account.. does that look like its a permissions issue ?
Thanks again for your help.

Launching xcode from nfs share (Ensure that Xcode.app is installed on a volume with ownership enabled)

Hi!
We have mac mini (Yosemite) and NFS server under Ubnuntu 14.04.
Also we have xcode resides on NFS share that mounted to mac.
Problem: When I try launch xcode from nfs share I got error message:
NSLocalizedRecoverySuggestion=Ensure that Xcode.app is installed on a volume with ownership enabled
You can see full error here:
https://gist.github.com/keferoff/fcfd3ea6c13f6ba481fa
The question is:
How I can launch xcode from nfs share? For some reasons I can't use xcode-select or store several xcodes locally.
Thanks in advance!

It's cool answer but I need solution how to accomplish my task. Maybe I can use iSCSI device or NBD device ot maybe there we have some NFS mount options?

Remove redundant Nautilus icons for NFS shares?

I have 3 NFS shares being mounted via x-systemd.automount in fstab. Everything is working fine with the shares except that Nautilus is showing redundant icons. Mounts are appearing under Devices and also Network. I would like to remove one set of icons. Any ideas?

See if anything I said here helps you... I had this problem years ago, but I don't use the NFS methods anymore regarding "Data". I am multi-seated now, so no longer share anything except the pacman stuff to the computer at the TV. I only use that computer to stream TV shows, so no user information is necessary. My conclusion was that as long as the NFS mount was outside the home folder, the "problem" did not exist.

Nautilus NFS shares listed under both Devices and Network

I have several NFS shares from my home server that I mount using fstab. I am running a fully up to date installation of Gnome 3.12. However, as my subject indicates, my NFS shares appear under both Devices and Network in Nautilus. I've done some searching and not found much about this. It is redundant and most importantly space wasting to have two lists of the same entries. Is there a way I can eliminate this duplication? Thanks.
Here is what I'm using in fstab to mount the shares:
nfs noauto,x-systemd.automount,x-systemd.device-timeout=10,rw,rsize=32768,wsize=32768,timeo=14,hard,intr,user 0 0

I indicated that I was trying to mount several NFS shares off my home server. I should have mentioned that these are NOT NFSv4 shares. Originally, I had the mount points inside my home folder. I've since moved them in the /mnt directory and don't have duplicate entries. Well, I don't have any entries under either Network or Devices. I've made links to the directories where the NFS shares are mounted. I was more curious if this was a bug with Nautilus or my own error as having the mount points in my home directory with other file browsers such as Dolphin in KDE did not yield duplicate entries with the same fstab mount options.
I guess the long and short of it is that if you are using Nautilus, have your NFS mount points outside your home folder.
Thanks.

New files and folders on a Linux client mounting a Windows 2012 Server for NFS share do not inherit Owner and Group when SetGID bit set

Problem statement
When I mount a Windows NFS service file share using UUUA and set the Owner and Group, and set the SetGID bit on the parent folder in a hierarchy. New Files and folders inside and underneath the parent folder do not inherit the Owner and Group permissions
of the parent.
I am given to understand from this Microsoft KnowledgeBase article (http://support.microsoft.com/kb/951716/en-gb) the problem is due to the Windows implmentation of NFS Services not supporting the Solaris SystemV or BSD grpid "Semantics"
However the article says the same functionality can acheived by using ACE Inheritance in conjunction with changing the Registry setting for "KeepInheritance" to enable Inheritance propagation of the Permissions by the Windows NFS Services.
1. The Precise location of the "KeepInheritance" DWORD key appears to have "moved" in Windows Server 2012 from a Services path to a Software path, is this documented somewhere? And after enabling it, (or creating it in the previous
location) the feature seems non-functional. Is there a method to file a Bug with Microsoft for this Feature?
2. All of the references on demonstrating how to set an ACE to achieve the same result "currently" either lead to broken links on Microsoft technical websites, or are not explicit they are vague or circumreferential. There are no plain Examples.
Can an Example be provided?
3. Is UUUA compatible with the method of setting ACE to acheive this result, or must the Linux client mount be "Mapped" using an Authentication source. And could that be with the new Flat File passwd and group files in c:\windows\system32\drivers\etc
and is there an Example available.
Scenario:
Windows Server 2012 Standard
File Server (Role)
+- Server for NFS (Role) << -- installed
General --
Folder path: F:\Shares\raid-6-array
Remote path: fs4:/raid-6-array
Protocol: NFS
Authentication --
No server authentication
+- No server authentication (AUTH_SYS)
++- Enable unmapped user access
+++- Allow unmapped user access by UID/GID
Share Permissions --
Name: linux_nfs_client.host.edu
Permissions: Read/Write
Root Access: Allowed
Encoding: ANSI
NTFS Permissions --
Type: Allow
Principal: BUILTIN\Administrators
Access: Full Control
Applies to: This folder only
Type: Allow
Principal: NT AUTHORITY\SYSTEM
Access: Full Control
Applies to: This folder only
-- John Willis, Facebook: John-Willis, Skype: john.willis7416

I'm making some "major" progress on this problem.
1. Apparently the "semantics" issue to honor SGID or grpid in NFS on the server side or the client side has been debated for some time. It also existed as of 2009 between Solaris nfs server and Linux nfs clients. The Linux community defaulted to declaring
it a "Server" side issue to avoid "Race" conditions between simultaneous access users and the local file system daemons. The client would have to "check" for the SGID and reformulate its CREATE request to specify the Secondary group it would have to "notice"
by which time it could have changed on the server. SUN declined to fix it.. even though there were reports it did not behave the same between nfs3 vs nfs4 daemons.. which might be because nfs4 servers have local ACL or ACE entries to process.. and a new local/nfs
"inheritance" scheme to worry about honoring.. that could place it in conflict with remote access.. and push the responsibility "outwards" to the nfs client.. introducing a race condition, necessitating "locking" semantics.
This article covers that discovery and no resolution - http://thr3ads.net/zfs-discuss/2009/10/569334-CR6894234-improved-sgid-directory-compatibility-with-non-Solaris-NFS-clients
2. A much Older Microsoft Knowledge Based article had explicit examples of using Windows ACEs and Inheritance to "mitigate" the issue.. basically the nfs client "cannot" update an ACE to make it "Inheritable" [-but-] a Windows side Admin or Windows User
[-can-] update or promote an existing ACE to "Inheritable"
Here are the pertinent statements -
"In Windows Services for UNIX 2.3, you can use the KeepInheritance registry value to set inheritable ACEs and to make sure that these ACEs apply to newly created files and folders on NFS shares."
"Note About the Permissions That Are Set by NFS Clients
The KeepInheritance option only applies ACEs that have inheritance enabled. Any permissions that are set by an NFS client will
only apply to that file or folder, so the resulting ACEs created by an NFS client will
not have inheritance set."
"So
If you want a folder's permissions to be inherited to new subfolders and files, you must set its permissions from the Windows NFS server because the permissions that are set by NFS clients only apply to the folder itself."
http://support.microsoft.com/default.aspx?scid=kb;en-us;321049
3. I have set up a Windows 2008r2 NFS server and mounted it with a Redhat Enteprise Linux 5 release 10 x86_64 server [Oct 31, 2013] and so far this does appear to be the case.
4. In order to mount and then switch user to a non-root user to create subdirectories and files, I had to mount the NFS share (after enabling Anonymous AUTH_SYS mapping) this is not a good thing, but it was because I have been using UUUA - Unmapped Unix
User Access Mapping, which makes no attempt to "map" a Unix UID/GID set by the NFS client to a Windows User account.
To verify the Inheritance of additional ACEs on new subdirectories and files created by a non-root Unix user, on the Windows NFS server I used the right click properties, security tab context menu, then Advanced to list all the ACEs and looked at the far
Column reflecting if it applied to [This folder only, or This folder and Subdirectories, or This folder and subdirectories and files]
5. All new Subdirectories and files createdby the non-root user had a [Non-Inheritance] ACE created for them.
6. I turned a [Non-Inheritance] ACE into an [Inheritance] ACE by selecting it then clicking [Edit] and using the Drop down to select [This folder, subdirs and files] then I went back to the NFS client and created more subdirs and files. Then back to the
Windows NFS server and checked the new subdirs and folders and they did Inherit the Windows NFS server ACE! - However the UID/GID of the subdirs and folders remained unchanged, they did not reflect the new "Effective" ownership or group membership.
7. I "believe" because I was using UUUA and working "behind" the UID/GID presentation layer for the NFS client, it did not update that presentation layer. It might do that "if" I were using a Mapping mechanism and mapped UID/GID to Windows User SIDs and
Group SIDs. Windows 2008r2 no longer has a "simple" Mapping server, it does not accept flat text files and requires a Schema extension to Active Directory just to MAP a windows account to a UID/GID.. a lot of overhead. Windows Server 2012 accepts flat text
files like /etc/passwd and /etc/group to perform this function and is next on my list of things to see if that will update the UID/GID based on the Windows ACE entries. Since the Local ACE take precedence "over" Inherited ACEs there could be a problem. The
Inheritance appears to be intended [only] to retain Administrative rights over user created subdirs and files by adding an additional ACE at the time of creation.
8. I did verify from the NFS client side in Linux that "Even though" the UID/GID seem to reflect the local non-root user should not have the ability to traverse or create new files, the "phantom" NFS Server ACEs are in place and do permit the function..
reconciling the "view" with "reality" appears problematic, unless the User Mapping will update "effective" rights and ownership in the "view"
-- John Willis, Facebook: John-Willis, Skype: john.willis7416

"Network Error - 53" while trying to mount NFS share in Windows Server 2008 client

CentOS | Windows 2008
I've got a CentOS 5.5 server running nfsd. On the Windows side, I'm running Windows Server 2008 R2 Enterprise. I have the "Files Services" server role enabled and both Client for NFS and Server for NFS are on.
I'm able to successfully connect/mount to the CentOS NFS share from other linux systems but am experiencing errors connecting to it from Windows. When I try to connect, I get the following:
C:\Users\fooadmin>mount -o anon 10.10.10.10:/share/ z:
Network Error - 53
Type 'NET HELPMSG 53' for more information.
(IP and share name have been changed to protect the innocent :-) )
Additional information:
I've verified low-level network connectivity between the Windows client and the NFS server with telnet (to the NFS on TCP/2049) so I know the port is open. I've further confirmed that inbound and outbound firewall ports are present and enabled.
I came across a
Microsoft tech note that suggested changing the "Provider Order" so "NFS Network" is above other items like Microsoft Windows Network. I changed this and restarted the NFS client - no luck.
I've confirmed that the share folder on the NFS server is readable/writable by all (777)
I've tried other variations of the mount command like: mount 10.10.10.10:/share/ z: and
mount 10.10.10.10:/share z: and mount -o anon mtype=hard \\10.10.10.10:/share * No luck.
As per the command output, I tried typing NET HELPMSG 53 but that doesn't tell me much. Just "The network path was not found".
I'm lost on how to proceed with troubleshooting. Any ideas?

There are usully two aspect that come to mind:
1. Syntax of mount command
2. Mismatch of NFS versions
Third reason is here
http://blogs.technet.com/b/sfu/archive/2011/11/21/getting-network-error-53-network-path-not-found-quot.aspx
Rgds
Milos

Can't mount NFS share via GUI

Mac OS X 10.8.2
MacBookPro5,3
Hello,
I've recently upgraded to OS X 10.8.2 and am having great difficulty in mounting my NFS shares via the OSX GUI. This worked fine at OS X 10.6.
My aim is to provide an automount type of setup so that less experienced users don't have to worry about the command line.
Can someone please point me in the right direction here?
This is what I've tried to date.
My NFS service is hosted on my Debian server. It supports NFS v4. The service is working and stable and is used routinely with Ubuntu clients. It has also worked with OS X 10.6 clients in the past, but not with OS X 10.7 clients.
To date I have tried the following options:
Mount via finder: Connect to server option using syntax: nfs://<user>@<server>/<share>
setting up autofs using the instructions from pmbuko
using the command line to mount the share.
The first option failed repeatedly. I did find that it would eventually work, though only after I'd manually mounted the share at the command line.
I have not been able to get the second option to work.
I initiate autofs using the command 'automount -vc' and see that the connection is recognised
when I attempt to cd into a directory below the mount point, I eventually get the message 'Connection Refused'.
when I check my Debian logs, I find that the NFS service had actually received an authenticated mount request from the Mac.
when I check my Mac Console logs, I see an error:kernel: nfs_connect: socket error 61 for <server>/<share>
I was able to get the third option working, but only after using the '-o resvport' option.
'Something' does appear to be broken with OS X 10.8.2 as an NFS client.
Any thoughts?

I have found a work around that meets my imediate needs, though it doesn't allow me to use autofs functionality.
The work around uses the traditional Unix/Linux approach of automatically mounting a file system or NFS share via fstab at boot time. OS X 10.8 still supports fstab, even though the file is not included in the default installation.
Once mounted, the NFS share appears as if it is part of the normal file system.
The following is only intended for people confident in Unix or Linux systems administration and in using a shell environment via the command line. Do not attempt this if you do not have these skills.
To set up for fstab, do the following within a terminal session:
create an empty directory in your file system that you can use as your mount point for your NFS share:
sudo mkdir /data/share
sudo chown root:wheel /data/share
using your favourite editor, create the fstab file (in a terminal type 'man fstab' for details)
sudo vi /etc/fstab
add similar to the following to /etc/fstab and then save and exit, substituting your own values where appropriate
# My NFS share
<your-server>:/<your-share> /data/share nfs resvport,rw,hard,intr 0 0
sudo chown root:wheel /etc/fstab
Please note: you may not need the resvport option in the fstab line above. It will depend on your NFS server's requirements.
Once you have done this, reboot your Mac and your NFS share should be mounted at the mount point that you defined.
If not, check your logs to see what went wrong.

How to PREVENT NFS shares showing on clients?

Folks: Can someone clue me in as to how it is that our server's NFS shares are showing up automatically on Mac clients (under Network..) -- and how to prevent that from happening?
For various reasons of idiosyncratic mix of machines, OSes etc, our server has SMB shares set up for Windows and Mac clients which work just fine, plus some NFS shares for linux and particularly for ancient SGI. We don't want Macs interacting with the server via NFS, yet those shares show up consistently on the clients, and confuse the heck out of users.
How do set the Mac clients to not ever do anything NFS? (On the server I could limit NFS exports' to specific IP addresses, but that's a moving target and likely to cause more grief than help...).
Thanks,
Graham
Many Mac OS X (10.3.9) Many

Jeff: We absolutely do NOT want the Mac users to be using NFS at all for anything. If we get involved in that game then we have to manage assignment of UIDs and GIDs for Mac users, which then impacts on the UIDs and GIDs that they use within their own Mac file systems and things go downhill from there. As it stands, the Mac users apparently have some default UID/GID which happens not to correspond to a UID/GID with privileges beyond RO, hence they can see but can't edit (thank goodness) dirs and files that they think they should be able to. We haven't even investigated whether those default UID/GIDs are even consistent across Macs (which of course is a problem in its own right), or what. Anyhow, it's big hairball that's totally unnecessary and useless.
It appears to me that some apparatus in the Mac is gratuitously detecting, mounting (or automounting) the NFS shares that can be detected on the network. If I could just turn that off, I think we'd be where we want to be. I guess turning off the entire NFS protocol for Macs might be a separate way to go.
Must admit, I'm getting closer to doing this "right" -- limiting NFS access in the server exports to specific client IPs.. but that's going to be a mess also.
Graham

Mounting nfs shares takes much longer since updating to 10.3.9

Hi, first post here. The titles of the forums are vague and I hope "getting online" really is the "networking forum"; apologies if not.
I have two linux machines which I regularly mount nfs shares from onto my powerbook. These machines are on the LAN and have known IP's for netinfod so I don't think the following problem is DNS related.
Since the last 10.3.9 update, mounting these shares (via finder or command line mount_nfs) has become very unreliable. Sometimes they never seem to mount, sometimes almost immediately, and other times they mount eventually even though I might of canceled the dialog box waiting for the mount. The logs show:
mount_nfs: bad MNT RPC: RPC: Timed out
The server side logs show only repeated authentication approvals. The servers have not changed software -- only OSX has been updated.
Independent if I use WiFi or a landline.
Once the shares are mounted, there is no detectable connection problems at all. Was any part of the NFS client updated in 10.3.9? Any ideas what might be wrong. TIA.
12" PowerBook G4 Mac OS X (10.3.9)

Just to bump this, as no one has chimed in, I found the problem and I will post the fix only if someone asks. It's not stupid, and it might help you. I am surprised that no one cares.
I'd still like to know why you can't launch PS from a bootable backup.

Server Shares will not Auto-Mount on Clients

Hi,
When I log onto my network, my server shares do not auto-mount.
Clients are able to log onto network. Connection to server on clients shows a
green light. When I go into finder and try to connect to shares network with
client user name /password it will not open shares. Shares will open with server
password, but I don't want to save server password on the clients.
All other services will setup and work as expected using client username / password.
I'm using Mountain Lion Server 10.8.2 and Mountain Lion Clients 10.8.2.
File sharing is turned on in the MLS Profile. Service access for clients File Sharing is checked.
I have tried restarting server clients.
Any ideas on how to fix this, short of a reinstall?
Thanks,
John

Imagine you want to enter your parents' house. You have a key for your house but it won't work on their locks. They won't give you their key and now you complain you can't get in with your own key. Same thing, server password and client password are two different keys for two different locks.

Mounting an NFS share

Hi,
I'm attempting to mount an NFS share and having no success. Regardless of the settings I try, the Finder still denies me access to the NFS share, even though it mounts fine. I seem to have no read or write access to the share.
I've tried exporting the share (in /etc/exports on the server machine) in two ways: with
/home/REDACTED/share REDACTED/28(rw,sync,all_squash)
And
/home/REDACTED/share REDACTED/28(rw,sync,insecure,all_squash,anonuid=1001,anongid=1001)
In the second example, the anonuid and anongid are those of the shared folder's owner and group. I added "insecure" because a how-to on the web claims that OS X won't work with any shares that don't have this specified.
With either of these settings applied, Disk Utility verifies the existence of the share, and mounts it. However, I can neither read files within, or add files to, the shared folder. The error produced is:
The folder “share” can’t be opened because you don’t have permission to see its contents.
I have tried the following Advanced Mount Parameters, each to no effect:
nodev resvport nolocks locallocks intr soft wsize=32768 rsize=3276
nodev nosuid resvport nolocks locallocks intr soft wsize=32768 rsize=3276 ro
nodev,nosuid,resvport,nolocks,locallocks,intr,soft,wsize=32768,rsize=3276
nodev,nosuid,resvport,nolocks,locallocks,intr,soft,wsize=32768,rsize=3276 ro
resvport,nolocks,locallocks,intr,soft,wsize=32768,rsize=3276
-i,-s,-w=32768,-r32768
-P
I'd rather not employ SAMBA, and the Apple File Sharing package for my server's OS (Ubuntu 11.10) appears to be bugged currently. Besides, NFS would be a far neater solution.
Any helpful advice?
S.

Scotch_Brawth wrote:
I've simply come at NFS as being the most appropriate file-sharing implementation for my needs - it supports automatic mounting at boot using tech native to both my Linux OS and OS X.
That is part of the problem. NFS is designed for environments where all servers are mounted (by root) at boot time and permissions are managed via NIS or LDAP. That is the default setting. If you are using something else, it requires some hacking.
I've had SAMBA working in the past, but I guess a certain air of contamination creeps in when using a Windows protocol to allow interaction between two UNIXy systems.
Plus, you would now have two different 3rd party reverse-engineered reimplementations of a foreign protocol.
AFP would be great, but despite receiving support on the Ubuntu forums and IRC, I failed to get it to work - it may be bugged; which would not be surprising, as 11.10 (with Kernel 3) has proved problematic in several other ways.
Perhaps Ubuntu is targeted more towards desktop rather than server usage. About the time I last played with NFS, I also played with Netatalk - with disastrous results. Supposedly Netatalk is better now. It's authors would be more than happy to sell you a support package.
I did use the default settings - they failed to allow a working NFS share. I then applied the variety of settings as recommended by apparently knowledgeable people. Still no success. I have read that UID/GID settings are an important aspect of NFS, but the issue in this case (as far as I understand it) is that all UID/GIDs below 1000 are privileged in Ubuntu 11.10, whilst on OS X these are below 501. So, the choice is either to give the shared folder owner a privileged UID/GID pair, or change the UID/GID of my Mac users to meet the NFS servers needs - not something I'm happy to do for so small a gain.
You can create a throwaway account on the Mac and just reset the GID/UID to values equal to an account on the Linux machine. That would establish that it is properly working in the default configuration. Then you could edit /etc/idmapd.conf.
For that reason, I use the "all_squash" option, because the share in question is not for anything remotely critical and the data to be transferred and stored is both worthless and transitory.
Since all_squash maps everything to nobody, you would have to hack up the permissions on the server to make everything world writeable. I think it will work with /etc/idmapd.conf and without all_squash.
I know nothing about NFS other than that its capabilities and integration meet my needs.
Just what are your needs? If the data is worthless and not critical then Netatalk might be the best option. If you can't get that to work, you could try MacFUSE on the Mac side and mount over sshfs. That is normally what I do. It isn't all that reliable, but you don't seem to require that.
What information I did find regarding OS X and NFS was that there were peculiarities that required certain settings to be present on the server and the client respectively - for example, OS X apparently requires "insecure" to be set as an option, or it simply won't connect properly. I don't know why, but I have no choice to trust to the advice of others in this case, until I have sufficient grasp to take care of the whole thing myself.
This goes back to the expectation that NFS expects to be always connected and mounted by root. Apple sells very few desktop machines anymore so it assumes a different, user-centered environment. You could use "insecure" on the server side to allow connections from "insecure" ports > 1024 that a regular users can connect with via the Finder. You could use the terminal with "sudo mount_nfs -o resvport" to tell the Mac to use the root user to connect via a secure port instead.
If you genuinely think you're able to help, then I'm happy to hear your advice. What would you recommend?
I appreciate your meeting me halfway. I think all you really need is /etc/idmapd.conf without all_squash. Then you could setup AutoFS and you could use NFS in a modern environment without even bothering to mount it.

Checking if NFS share is mounted on client

Similar Messages

Maybe you are looking for