Mounting subdirectories of an NFS share

I'm an admin from an IRIX/Linux background. I have an existing NFS-based server setup. XServes are creeping into my racks because they are, in many respects, lovely. However, there is a fly in the ointment.
My existing setup relies on this simple fact: in SysV-type NFS implementations if a server exports /Volumes/foo, a client is free to mount just the subdirectory /Volumes/foo/bar.
This plain doesn't work with the OS X NFS implementation.
Or so I thought. Looking at the man page for exports, I discover the "-alldirs" flag. And using nidump and niload, I can change the exports netinfo record from
"name" = ( "/Volumes/xtal/work/scratch" );
"opts" = ( "maproot=nobody" );
to
"name" = ( "/Volumes/xtal/work/scratch" );
"opts" = ( "maproot=nobody", "alldirs" );
With a little fiddling around, I've now convinced my XServe to allow clients to mount subdirectories. Of course, I can't use Workgroup Manager to edit mount details any more.
My question (and thank you if you've managed to get this far) is: Does anyone else do this? Is it really unwise?
---%<---
As a ranty aside: Why do Apple insist on doing this? They have a fully-featured, working NFS implementation under the hood and then give us a GUI with 3 buttons and a dropdown to configure this. I'm a sysadmin, not an idiot (well, not as far as NFS goes, anyway). I can understand the implications of changing NFS configurations. I've been doing it for 15 years.
Yes, I should be using AFP. Yes, NFS is insecure. But we have a lot of old iron that I have to continue to support, and if Apple hardware is going to fit in to our existing setup it should have more configuration options than clicking on a shiny blue button.<br>

Similar Messages

"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

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

[SOLVED] MPD through mounted NFS Share

Hi all. I am using MPD paired with Ncmpcpp, and in my configuration (for both mpd & ncmpcpp) I have the music directory set to /mnt/Shares/Music which is where I am mounting a NFS share located on the local network.
However ncmpcpp seems to be only partially reading the directory. In the server directory I have two subdirectories (mp3 and ogg) but my music player seems to only be reading the mp3 directory. I have tried updating the database through ncmpcpp, restarting the computer, restarting mpd through systemctl, and even tried using symlinks within the directory (and having "follow internal" and "follow external" symlinks set to "yes" in /etc/mpd.conf).
None of these seem to work in making mpd read the ogg directory.
Edit: Mounting through NFS automatically chowns the share to the local user, so not only did I have to sudo chown -R <user>:users the music share directory on the host I also had to reconfigure my MPD settings to run as a local user as well in order to have proper permissions for the NFS share. Prior to that it was running system wide as the MPD user. This has solved the problem completely.
Last edited by felixculpa (2012-12-26 05:24:19)

WonderWoofy wrote:
Awesome, don't forget to mark your thread as [Solved] by editing your first posts. Sorry I couldn't have been of better help to you. Glad you solved it though.
Edit: I did think it kind of odd (and unlikely) that ogg would not be an automatically supported format, but the source told me otherwise... strange.
Thanks. The Arch community is awesome and I appreciate the help I get in the forums. I am currently updating the database but it is taking quiet some time, so I am not 100% I have fixed the problem. After it is done, and if it works I will update the thread as [Solved].
Thanks again.
Edit: I forgot to mention that I was mistaken in the not reading ogg files part. It was reading only some files from both directories; it just wasn't reading the files it didn't have permission for I'm guessing.
Last edited by felixculpa (2012-12-26 03:47:46)

How can a mount a NFS share exported from OpenBSD?

Hello Apple Discussions:
I've been experimenting with NFS in a mixed OS environment, and have been successful exporting nfs share with tigerserver, and mounting it on both a powerpc linux system, and on a powerpc openBSD system.
Likewise, I can export a NFS share from the linux powerpc box, and mount it on the openBSD box and on the tigerserver, although, the latter required using the options (ro,sync,insecure) in my exports file.
However, when I export a share on the OpenBSD box, I can mount it on the linux box, but not on tigerserver.
I would like for the OpenBSD box to export a NFS share securely, with read-write permissions, to the tigerserver.
After reading so many tutorials, that it would be a page of links, just to list them all, I am pulling my hair out. However, I have found one thread that suggests, that perhaps what I'm trying to do is impossible:
http://www.bsdforums.org/forums/showthread.php?t=54308
Here it is suggested that the NFS won't work because tigerserver is not using UTF-8?
I will have to say, that I was somewhat alarmed, that the only times I succeeded in mounting an nfs share exported from linux onto tigerserver, it was when the "insecure" option is used in the /etc/exports file. There doesn't seem to be an equivalent for the linux style exports option "insecure", in the bsd style options of --maproot=user:group1:group2.
But I don't like using any options that say "insecure" anyways, so rather than trying to find out how to make openbsd "insecure", I would rather like to find out if there is a way to get tigerserver using UTF-8, at least when mounting NFS shares, if this is indeed the issue.
Here are the more technical details. I've created a user on all sytems named "fives" with the userid of 5555 and the groupid of 5555. I made the user local user in the local net info domain, but I've tried it with an LDAP user as well. The folders I wish to export and the folders into which to mount them are all owned by user fives and group fives, and have permissions set to 0775. The ip addresses are OpenBSD=192.168.222.111 TigerServer=192.168.222.233 LinuxPPC=192.168.222.253. I've included the relevant NFS setup files and running processes below:
ON THE OPENBSD BOX:
#/etc/exports
/fives -alldirs -network=192.168.222.0 -mask=255.255.255.0
/exports/fives -mapall=fives:fives 192.168.222.233 192.168.222.253
#/etc/hosts.deny
ALL: ALL
#/etc/hosts.allow
ALL: 192.168.222.233 192.168.222.253
#/etc/rc.conf.local
portmap=YES
lockd=YES
nfs_server=YES
#here's proof that the daemons are running on the OpenBSD box;
rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 863 mountd
100005 3 udp 863 mountd
100005 1 tcp 613 mountd
100005 3 tcp 613 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100021 1 udp 895 nlockmgr
100021 3 udp 895 nlockmgr
100021 1 tcp 706 nlockmgr
100021 3 tcp 706 nlockmgr
# actually, I don't see statd, but haven't found the equivalent in openbsd. There's rpc.rstatd, and maybe it should be listed here, but there doesn't seem to be a way to launch it directly. This is a competitor with the UTF-8 theory about why it's not working.
ON THE TIGER SERVER:
# here's proof that tiger server sees the mounts:
showmount -e 192.168.222.111
Exports list on 192.168.222.111:
/fives 192.168.222.0
/exports/fives 192.168.222.233 192.168.222.253
# here's the result of user fives' attempt at mounting a share:
sudo mount -t nfs 192.168.222.111:/exports/fives /imports/fives
mount_nfs: /imports/fives: Permission denied
# yet user fives has no problem mounting same share on linuxppc box.
What is different about OSX server? I thought it was supposed to speak NFS?
---argh... I'm steppin out for a pint.. Hopefully when I'm back it'll just work.

One thing not mentioned is that if you decide on the multiple user approach, you can have your music folder in Shared Documents so you only store the tracks once.
Each user is free to choose which of those tracks they want in their library.
There is an Apple help article on multiple users.
http://docs.info.apple.com/article.html?artnum=300432

[SOLVED]Can´t mount nfs shares!

Hello,
I am trying to get up a fileserver. I installed an old PC with Arch and configerd it over SSH. I followed the wiki over NFS and NFSv4. But everytime I want to mount a share that is in the physical map /home/jozef/shares/downloads, I get the following error:
mount.nfs4: timeout set for Mon Aug 24 14:36:57 2009
mount.nfs4: text-based options: 'clientaddr=192.168.0.100,addr=192.168.0.111'
mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting 192.168.0.111:/shares/downloads
I tried to mount it with the following command:
mount -v -t nfs4 192.168.0.111:/shares/downloads /media/Downloads-Server
Lets call the fileserver fileserver and my workstation Gamepc. Here I will give you some files that I think are needed, from fileserver and Gamepc are there other files you need, I will post them.
/etc/exports on fileserver
# /etc/exports
# List of directories exported to NFS clients. See exports(5).
# Use exportfs -arv to reread.
# Example for NFSv2 and NFSv3:
# /srv/home hostname1(rw,sync) hostname2(ro,sync)
# Example for NFSv4:
# /srv/nfs4 hostname1(rw,sync,fsid=0)
# /srv/nfs4/home hostname1(rw,sync,nohide)
# Using Kerberos and integrity checking:
# /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt)
# /srv/nfs4/home gss/krb5i(rw,sync,nohide)
/shares 192.168.0.12(rw,fsid=0,no_subtree_check,async,no_root_squash)
/shares/downloads 192.168.0.12(rw,no_subtree_check,async,no_root_squash,nohide)
/etc/hosts.allow on fileserver
# /etc/hosts.allow
sshd: 192.168.0.0/255.255.255.0
#nfsd: 192.168.0.0/255.255.255.255
#portmap: 192.168.0.0/255.255.255.255
#mountd: 192.168.0.0/255.255.255.255
nfsd: ALL
portmap: ALL
mountd: ALL
# End of file
/etc/hosts.deny on fileserver
# /etc/hosts.deny
ALL: ALL: DENY
# End of file
/etc/conf.d/nfs-common on fileserver
STATD_OPTS="--no-notify"
/etc/conf.d/nfs-server on fileserver
STATD_OPTS="--no-notify"
/etc/rc.conf on fileserver
# /etc/rc.conf - Main Configuration for Arch Linux
# LOCALIZATION
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
LOCALE="en_US.utf8"
HARDWARECLOCK=""
USEDIRECTISA="no"
TIMEZONE=""
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
# HARDWARE
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=()
# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"
# NETWORKING
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
HOSTNAME="myhost"
# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
# - prefix an entry in INTERFACES with a ! to disable it
# - no hyphens in your interface names - Bash doesn't like it
# DHCP: Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#Static IP example
#eth0="dhcp"
eth0="dhcp"
INTERFACES=(eth0)
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
# - prefix an entry in ROUTES with a ! to disable it
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
# Enable these network profiles at boot-up. These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
# - set to 'menu' to present a menu during boot-up (dialog package required)
# - prefix an entry with a ! to disable it
# Network profiles are found in /etc/network.d
# This now requires the netcfg package
#NETWORKS=(main)
# DAEMONS
# Daemons to start at boot-up (in this order)
# - prefix a daemon with a ! to disable it
# - prefix a daemon with a @ to start it up in the background
DAEMONS=(syslog-ng !network rpcbind nfs-common nfs-server netfs crond !xinetd !samba sshd transmissiond)
/etc/rc.conf on Gamepc
# /etc/rc.conf - Main Configuration for Arch Linux
# LOCALIZATION
# LOCALE: available languages can be listed with the 'locale -a' command
# HARDWARECLOCK: set to "UTC" or "localtime"
# USEDIRECTISA: use direct I/O requests instead of /dev/rtc for hwclock
# TIMEZONE: timezones are found in /usr/share/zoneinfo
# KEYMAP: keymaps are found in /usr/share/kbd/keymaps
# CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US)
# CONSOLEMAP: found in /usr/share/kbd/consoletrans
# USECOLOR: use ANSI color sequences in startup messages
LOCALE="en_US.utf8"
HARDWARECLOCK="localtime"
USEDIRECTISA="no"
TIMEZONE="Europe/Amsterdam"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
# HARDWARE
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed
# MOD_BLACKLIST: Prevent udev from loading these modules
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.
MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=() #deprecated
MODULES=()
# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"
# NETWORKING
# HOSTNAME: Hostname of machine. Should also be put in /etc/hosts
HOSTNAME="GAMEPC"
# Use 'ifconfig -a' or 'ls /sys/class/net/' to see all available interfaces.
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
# - prefix an entry in INTERFACES with a ! to disable it
# - no hyphens in your interface names - Bash doesn't like it
# DHCP: Set your interface to "dhcp" (eth0="dhcp")
# Wireless: See network profiles below
#Static IP example
#eth0="dhcp"
eth0="dhcp"
INTERFACES=(eth0)
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
# - prefix an entry in ROUTES with a ! to disable it
gateway="default gw 192.168.0.1"
ROUTES=(!gateway)
# Enable these network profiles at boot-up. These are only useful
# if you happen to need multiple network configurations (ie, laptop users)
# - set to 'menu' to present a menu during boot-up (dialog package required)
# - prefix an entry with a ! to disable it
# Network profiles are found in /etc/network.d
# This now requires the netcfg package
#NETWORKS=(main)
# DAEMONS
# Daemons to start at boot-up (in this order)
# - prefix a daemon with a ! to disable it
# - prefix a daemon with a @ to start it up in the background
DAEMONS=(syslog-ng !network rpcbind nfs-common @netfs crond @hal @fam @samba @alsa @cups)
/etc/hosts.allow on Gamepc
# /etc/hosts.allow
sshd:ALL
# End of file
/etc/hosts.deny on Gamepc
# /etc/hosts.deny
ALL: ALL: DENY
# End of file
If someone could help me, I would be pleased.
With kind regards,
Jozef00
Last edited by jozef00 (2009-09-01 15:28:07)

Are you sure that the nfs module is loaded? Do
lsmod | grep nfs
to check. If "nfs" doesn't appear then that's your problem. Do:
sudo modprobe nfs
and continue.
EDIT: Also, I'll assume both your server and your client machine are connected to the network. You have the network DAEMON "!"-disabled in each machine's /etc/rc.conf. So I'm assuming you're connecting them to the network in some other way, and have verified that you can, for example, ssh from one machine to the other.
Third, you're sure that /share exists on your server machine, that a (presumably empty) directory /share/downloads exists inside it, that another folder is mounted on top of that empty directory? When you type "mount" on the server machine there should be a line containing "on /share/downloads".
Fourth, if your client's ip address is 192.168.0.100 (this will be displayed when you do "ifconfig") then the /etc/exports on your server has been changed to read:
/shares 192.168.0.100(rw,fsid=0,no_subtree_check,async,no_root_squash)
/shares/downloads 192.168.0.100(rw,no_subtree_check,async,no_root_squash,nohide)
Then you either typed "exportfs -rf" on the server, or stopped and restarted nfs-server. (I'd stop nfs-server, nfs-common, and rpcbind, then start them up again in reverse order, to be sure.)
STATD_OPTS has no effect in /etc/conf.d/nfs-server. Also, you don't need to use statd if you're using nfs4. So you could change /etc/conf.d/nfs-common to read:
NEED_STATD=no
NEED_IDMAPD=yes
and /etc/conf.d/server and can be blank.
(Then restart everything, as described above.)
If you're using the latest arch packages then portmap has been replaced by rpcbind (which you do have in your DAEMONS line on the server). So you need to change the "portmap:" line in your server's /etc/hosts.allow to "rpcbind:". I also have a "lockd:" line in my /etc/hosts.allow, in addition to what you have. It's probably not the source of your present troubles, and I'm not sure it's necessary. But you could try adding it.
Finally, did you add/change a "Domain = ..." line in the /etc/idmapd.conf on your server, and a corrsponding line in the /etc/idmapd.conf on your client?
Last edited by Profjim (2009-08-25 12:51:48)

NFS share mount on solaris 10 : error 48

I got the below error when mount NFS share on solaris 10 . Please help
Oct 20 10:02:12 etravel2k nfs: [ID 182275 kern.warning] WARNING: NFS server initial call to scom01 failed: error 48

Hi,
try to force the mount with nfs version 3.
# mount -o vers=3 server-name:/share-point /local-dir
regards
Walter

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

Error mounting NFS share - mount.nfs: Operation not permitted

I've got an NFS share on a FreeBSD server which I mount via fstab.
It mounts automatically at boot and everything is fine.
However, if I unmount it and try to mount it again I get:
mount.nfs: Operation not permitted
I have tried vers=3 and nfsvers=3 in fstab, but to no avail.
rpcbind is allowed in /etc/hosts.allow.
Does anyone have any ideas?
fstab entry:
server:/path/to/files /mnt/files nfs ro,hard,intr,nfsvers=3 0 0

Tagging along, I have the same problem, although I have a different setup:
- Server = Arch linux
- Client1 = Debian Testing linux
- Client2 = Arch linux
On client1, I'm unable to mount all NFS-shares. 2 out of 3 mount ok and the third fails with this error (both through fstab and manually):
# mount -a
mount.nfs4: access denied by server while mounting (null)
On Client2 I'm able to connect automatically and manually to all shares.
Maybe it is Debian-related, but the debian user forums have not been of much help...
THX for any input!
Last edited by zenlord (2010-03-04 12:07:04)

First access to mounted NFS share very slow in finder

Hi,
we have some NFS Shares on our Celerra Fileserver mounted by Mac running Snow Leopard 10.6.2 (just updating to 10.6.3).
After a mount of FS in finder, there are approx 600MB loaded from the share on first access. On our LAN it isn't that problem ... but off-site it's very annoying if that amount of data have to go through an small 1Mbit pipe.
Access via Terminal to the same directory doesn't have the problem. Spotlight is disabled with a .metadataneverindex on the root of the share.
Now my question :
Is there any kind of cache, which can be turned of to prevent finder from loading the whole structure / part of files on first access ?
Thanks,
Robert

Thanks for your reply peter.
I have tried , without connecting database, i just hardcoded data values then i tried to access my application at that time it was very fast.
Then i came to conclusion that problem is in some where in data base connection. because my query is also fine tunes.

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.

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.

Can not mount nfs shares

I have a centos server which tries to mount a nfs share from an osx server tiger.
on the osx server showmount -e shows me the mountpoint perfectly.
on the linux server i try to mount the mountpoint and after some time it gives me the error:
mount.nfs: Input/output error
does this sound familiar to anyone? please help me :P

more information:
nidump -r /exports .
"name" = ( "exports" );
CHILDREN = (
"clients" = ( "192.168.0.10" );
"name" = ( "/backup" );
"opts" = ( "" );
showmount -a returns:
Exports list on localhost:
/backup 192.168.0.10

Mounting subdirectories of an NFS share

Similar Messages

Maybe you are looking for