<FONT face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=2>-----kwlug-disc-bounces@kwlug.org wrote: -----<br><div><font color="#990099"><br></font>>From: unsolicited <unsolicited@swiz.ca><br>><br>>For NFS, does this assume a central authentication mechanism? e.g. <br>>LDAP / PAM? Otherwise you create an account on the sharing machine<br>>for each user and supply that when connecting?<br><br>It doesn't assume a central mechanism for authentication, although it's suggested on networks larger than one node ;) NFS does not require central authentication it doesn't even require synchronized user IDs. <br><br>An NFS mounted file system generally works like a normally mounted file system. The user ID is provided by Linux and passed to the server, there isn't any authentication at the server, it's done at the client. There is the standard Linux file system permissions though.<br><br>Having centralized auth means that user IDs between systems are consistent which in turn means that would have access to the same files consistently. <br><br>>Which, I assume would also be true for samba, with config files for <br>>the sharing machine. Unless you're authenticating against Active <br>>Directory? (Does that work? All that well?)<br><br>The samba server itself does authentication and so it doesn't care who you are logged in as on the client system. The client's samba file system driver takes the user name and password used to authenticate with the Samba server. These are the credentials that are used for the entire connection. As a result if Tom and Dick both use the same system and access a samba mounted file system they would have the same permissions.<br><br>Since Samba does the authentication it is centralized, but realize that the samba user and the user credentials you use to logon to Linux are different.<br><br>>There are, or equivalents, out there. e.g. in the mount file. Note, <br>>however, that not all work, YMMV. Using smb://, for example, in<br>>mount, <br>>fails miserably. Bug reports have been filed and outstanding for many<br>>revs now. The problem(s) has never been resolved.<br><br>I'm not sure we are communicating on this one. By automount I mean a daemon that watches a special directory, like /net. When a user 'cd's to /net/systemname the automount daemon automatically displays the exported file systems from "systemname" and mounts them as needed and unmounts on idle.<br><br>For example on Net Direct's network if I cd to /net/nfshome/home/john I get my home directory. I don't require a line in fstab to do this it just happens automatically.<br><br>>I can think of a couple of other reasons to have non-NFS around. <br>>Richard, IIRC, and he can confirm/deny, was setting up an external<br>>USB or standalone NAS box, and just gave up on getting NFS working -<br>>going to Samba instead. IIRC, the problem was with the standalone box's NFS<br>>implementation.<br>><br>>There are more 'samba' familiar users and devices out there than not.<br>><br>>Camera cards, and windows user's usb keys come to mind. I can<br>>envision <br>>circumstances where simply inserting the stick in the other machine <br>>isn't palatable. Inevitably, you'll run into the issue. Perhaps<br>>easier <br>>to just set it up that way in the first place.<br>><br>>Sort of like JFS, or whatever, on a USB key, with Windows at work and<br>>Linux at home. Not gonna get you where you wanted to go.<br><br>According to Jeremy Allison (last year's Ontario GNU Linux Fest keynote presenter and core Samba developer, register for this year now at http://onlinux.ca/olfreg ) most devices use samba for that functionality which means it's likely a Linux or BSD O/S which support NFS well.<br><br>I don't work with consumer NAS devices like that so I can't comment. I usually find that the client determines the network file share protocol.<br></div></FONT>