Configuring an NFS Share for CDM (SGD 4.6 on Linux)

hello all,
i'm not able to access local drive from apps because i don't create /smb on the server, as specified in the doc 821-1926.pdf.
My question is:
- is it mandatory to have a nfs share on the SGD server?
Users just need to load local files into published apps, not to access remote files.
Thanks in advance for help,
gerard

Yes, I it is mandatory.
Note: The /smb share must be configured on the application server and not the SGD server (unless the server is performing both roles).
You must also install the SGD enhancement module on the application server and, after configuring the NFS share, you need to start the CDM component of the Enhancement Module as described in the doc.
The CDM component of the enhancement module presents the NFS share as an SMB share to the SGD server, and without this you will not be able to access local drives.

Similar Messages

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

Thunar freezing when mounting NFS shares

I have used Thunar and NFS for some time without any problems, but in the past week Thunar has been locking up solid when I use it to access a NFS share for more than a minutes or so. It totally locks up the Thunar GUI and I have to force it to quit. When this happens I noticed that the rpc.mountd process becomes zombified or defunct, and AutoFS no longer works too. Restarting these processes with systemctl does not work, since the restart command just hangs.
I run "journalctl -xn" when this happens, but noting really stands out.
I don't have any issues when I access the same NFS share using a terminal.
Currently I have a less than satisfactory workaround - which is to use PCmanFM instead of Thunar. PCmanFM seems to have the good graces to just automatically crash after mounting a NFS share for more than a minute and thus not case all the problems with rpc.mountd & AutoFS.

I finally solved my problem by changing the mount options to this in fstab:
pc-francois.local:/francois /mnt/pc-francois nfs4 rw,proto=tcp,vers=4.0,noauto,users,intr 0 0
One week to find it... Maybe it wants to use nfs 4.1 by default.

CM Repository for NFS share

Hello,
We are on EP 7.0 sp14 (windows) and currently have several CM repositories pointing to external Windows File shares.
Is it possible to point CM Repository to NFS share?
Thanks,
Alex
Edited by: Alex Trosman on Jan 13, 2009 10:14 PM

Hi Ramalakshmi,
you are using a CM Repository in FSDB Mode. Am I right? If so, check the following:
1. Did you configure your Network Path? The specified user should have full access to the resource.
2. Did you configure the Root Directory? Note: The Root Directory in your Repository Manager mustn't point to the same directory of your network path!!
3. Did you configure the Root Directory for Versions? Note: The Root Directory for Versions mustn't be a subfolder of your Root Directory!! Must point to a folder which contains the subfolders "versions, workingresources, workspaces, wastebasket"!
4. Persistence Mode must be set to "FSDB"
5. Windows Landscape System must be the same as your Network Path.
Hope this helps and will solve your issue.
Best regards,
Denis

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

Mac user locks files for Windows users on NFS shares

Hi Everyone,
We run a mostly Windows environment here at my school and have two AD servers which also do our file shares for AD users. Every user has a network drive mapped to L on Windows, and this is mounted on the dock of our Mac users (all Macs are bound to the AD for auth and the OD for management). We also have shared folders for different groups of people, such as admissions or art (where the issue is). Most of these divisions are only Windows, so file sharing isn't and issue - but this is not the case in our Art department.
We have a shared folder (T on Windows) setup for users of the Art department with mostly Office docs in it. Windows users can write to the share just fine, just as the Mac users can. The issue comes up once a Mac user edits and saves the file (all to the share) - Windows users are now locked out of the file because the permissions are reset. What can we do to fix this issue? It's obnoxious having to go and reset the permissions after every edit from a Mac user.
Thanks,
-MRCUR

We also have that same problem. We don't actually solved the issue but we what we do did is just unlock the files once and even they are edited or opened in windows or mac, it does not lock the file. We use windows pc and connect to the drives and just simply right clicking the file then properties a button will show in the properties window saying "unlock". After we did that, those files was never locked out again.

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.

Issue with special character in NFS shares

Hello,
I run a Ubuntu 10.04 server for serving my files via NFS. I have no problems mounting the NFS shares in my iMac (OS X 10.6.3). I can access all files, even the ones containing special characters in their names. I can copy, create, move them with no problem, both on Finder and on the Terminal.
The problem comes when I try to synchronize or backup files using backup tools. Files with accents in their names (á, é, ã, ç, etc) are simply ignored by the backup/sync tools I am using. I could reproduce the problem in different softwares like "ChronoSync" and "File Synchronization". Accents are a must have in my network.
I saw in other posts in this forum that there might be some incompatibilities with Unicode and special chars while using Mac OS X as a NFS client for a Linux NFS server. What strikes me is that Finder and Terminal work just OK.
Any clue?
Some details of my NFS configuration:
/etc/exports on my server:
/mnt/disco01 10.209.1.0/24(rw,sync,nosubtree_check,anonuid=1000,anongid=1000,allsquash)
/mnt/disco02 10.209.1.0/24(rw,sync,nosubtree_check,anonuid=1000,anongid=1000,allsquash)
/mnt/disco03 10.209.1.0/24(rw,sync,nosubtree_check,anonuid=1000,anongid=1000,allsquash)
/mnt/disco04 10.209.1.0/24(rw,sync,nosubtree_check,anonuid=1000,anongid=1000,allsquash)
On my iMac I moount them like this using Disk Utility's NFS tool:
URL: nfs://servidor/mnt/disco01
Mount point: /Network/disco01
Options: -P nosuid
Thanks for any help you can give me.

Well, I dug a little further and got a solution, although It make no sense to me.
So, the scenario is:
server URL: nfs://server/mnt/disco01
mount point: /Network/disco01
I was trying to synchronize a folder from the server called /Network/disco01/Música (meaning music in Portugueses) to a local folder /Users/shared/Música. I would use ChronoSync to keep the folders in sync, mirroring the NFS share to the local folder. ChronoSync was ignoring the folder.
After not being able to copy using the ChronoSync tool, I tried to copy the folder via the Finder. I could browse the nfs share using the finder, but not copy the files the local folder.
While trying to copy, I use Cmd-C then Cmd-V in the /User/shared/ folder. I noticed that first the Finder named the folder "Music" and then some instants after if would refuse to copy. Very strange.
I first renamed the "Música" folder on the NFS share to "Músicas", then everything worked allright, even Chronosync. Turns out that Música is the name of one of the system folder OS X creates on the user's home folder. It is actually a translation to the underlying name Music.
Why it was interfering with the copy of totally unrelated NFS and local folders I can really not understand.
More interesting, afterwards I renamed the NFS folder again to Música (without s) and it kept working.
I am happy now, but I have no clue as to why there was the problem, and why it got solved.
Hope this helps somebody in a similar situation.

[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)

Windows 2012 R2 - Access problems to NFS shares via IPv6

Hello,
we setup some NFS shares on HNAS storage box. The connection to this storage is only possible over IPv6 network.
My server with Windows 2012 R2 has the feature 'Client for NFS' installed and a 'showmount -e servername/or IPv6 address' works. I can see all shares when i try to open the storagebox in Windows Explorer with the command "\\servername" or "\\IPv6
address", too.
My problem is, when I try to mount the share via "Map network drive" or "mount \\servername\sharename *" I get Error 53 - Network path not found.
The share is configured that every server in the IPv6 subnet could access it and it works on Unix machines, but not on Windows.
It does not matter if i set some option parameters for the "mount" command like sec=sys or anon, everytime error 53.
I don't know, if the share needs special options for Windows. I hope somebody can help.
Kind regards

Hi,
here is the output of your 2 commands:
PS C:\Users\admin> get-SmbConnection
PS C:\Users\admin> get-SmbServerConfiguration
AnnounceServer                  : False
AsynchronousCredits             : 64
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 0
AnnounceComment                 :
EnableDownlevelTimewarp         : False
EnableLeasing                   : True
EnableMultiChannel              : True
EnableStrictNameChecking        : True
AutoDisconnectTimeout           : 0
DurableHandleV2TimeoutInSeconds : 30
EnableAuthenticateUserSharing   : False
EnableForcedLogoff              : True
EnableOplocks                   : True
EnableSecuritySignature         : True
ServerHidden                    : True
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                : HydraLsPipe
NullSessionShares               :
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RequireSecuritySignature        : False
EnableSMB1Protocol              : True
EnableSMB2Protocol              : False
Smb2CreditsMax                  : 2048
Smb2CreditsMin                  : 128
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True
EncryptData                     : False
RejectUnencryptedAccess         : True
I try to access the file share with Windows Explorer. When I enter \\fe08--babe-face-cafe-dead.ipv6-literal.net (just example), I can see all shares on the storage box. When I double-click the share, I want to access, where an access is definitely allowed,
it takes a while and then the error "\\fe08--babe-face-cafe-dead.ipv6-literal.net\share is not accessable. You might not have permission to use this network resource. ..." appears. Of this action a recorded the trace.
Another way I tried is to open command line an type "mount \\fe08--babe-face-cafe-dead.ipv6-literal.net\share *". After this an error 53 occurs immediately without any wait time.

Can you re-export an nfs mount as an nfs share

If so what is the downside?
I'm asking because we currently have an iscsi san and a recent upgrade
severely degraded iscsi connectivity. consequently can't mount my iscsi
volumes.
Thanks,
db

Originally Posted by David Brown
The filer/san NFS functionality is working normally. I can't access
some of the iscsi luns. Thinking of just using NFS as the backend.
Which would be a better sub forum?
Thank you,
db
Depending on which Novell OS you are running.... this subform is for NetWare, but I suspect you are using OES Linux.
I've never tried creating a NCP share on OES for a remote NFS mount on the server. My first guess would be it is not allowed and also not a good practice. You could however, with this situation and if you are running an OES2 or OES 11 Linux server, try configuring an NFS mount on the OES server and then configuring the NCP share on that using remote manager on the server.
What I would recommend however to see if the iSCSI issue cannot be fixed or worked around.
Could you describe a bit more of the situation there/what happened and what is not working on that end?
-Willem

OS X Lion, NFS shares, Time Machine?

A few years ago I bought a Mac Mini server. I wanted to use it as a storage server using attached drives. I got everything up and running but kept running into the same problem: The NFS server deamon would stop / crash for no apparent reason when I was writing large files to the server over NFS.
I spent some time troubleshooting the issue but never resolved it and eventually resorted to wiping out OS X on the Mac Mini server an install CentOS Linux instead. The NFS deamon here is rock solid and I have used it ever since.
Fast forward to today where my Time Capsule died due to the usual power supply failures (thanks to Apple for a crappy design). I then realized that I could use my Mac Mini Server as a host for Time Machine, I'd just need to get it running OS X Server again. I would still want to serve writeable NFS shares so this leads to my question:
Does anyone know for sure whether OS X Mountain Lion has had any improvements to the NFS deamon over previous versions? I'd be quite happy to buy the new OS, but I'd prefer to be a little more confident that all the work would pay off (in the form of a stable NFS service)

The Server.app and Server Admin utilities for Lion no longer let you configure NFS. However the NFS software is still there and in fact was significantly upgraded and now supports NFS v4.
See http://support.apple.com/kb/HT4695

Nfs share with specified hosts

I am running Solaris 8 on sparc. What is the share command for specifying which hosts can access the shared partition?

Hi,
Though NTFS permission should be set automatically, please still check if everyone do have Write permission on that NFS share - Add Everyone - Full Control as a test.
Also see if this policy could help:
http://technet.microsoft.com/en-us/library/cc772211.aspx
Allow anonymous access by the Everyone group
To allow anonymous access by the Everyone group
Click Start , type gpedit.msc in the Start Search text box, and then press ENTER .
In the Local Group Policy Editor console tree, open Computer Configuration , open Windows Settings , open Security Settings , open Local Policies , and then click Security Options .
In the details pane, right-click Network access: Let Everyone permissions apply to anonymous users , and then click Properties .
To allow permissions that are applied to the Everyone group to apply to anonymous users, click Enabled .
- or -
To prevent permissions that are applied to the Everyone group from applying to anonymous users, click Disabled .
Click OK .
If you have any feedback on our support, please send to [email protected]

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.

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

Configuring an NFS Share for CDM (SGD 4.6 on Linux)

Similar Messages

Maybe you are looking for