On Tue, 2006-04-04 at 17:36 +0100, Anne Wilson wrote: > On Tuesday 04 April 2006 14:15, Craig White wrote: > > for the record, defaults are what you get when you don't specify > > anything... > > > > from smb.conf > > Default: workgroup = WORKGROUP > > and as in windows, it is always better to not use the default. ---- It doesn't matter if you use or don't use the defaults unless you haven't a clue what the defaults are. The easy way to figure out what the true settings are (explicit and default supplied) is to issue 'testparm -s -v > /tmp/samba.conf' and you can then see all of the settings, including those supplied by default ---- > > security = share means that there are no users, no home directories and > > login is a password with access/file permissions as the user specified > > by smb.conf and thus a user name logging in is pointless when using > > 'security = share' > > > I think we can take it that John Terpstra knows what he is talking about. > From "Samba-2 by Example': > > "This installation demands simplicity. Frequent turn-over of volunteer staff > would indicate that a network environment that requires users to logon might > be problematic. It is suggested that the best solution for this office would > be one where the user can log onto any PC with any username and password..... > > This oranisation is a prime candidate for Share Mode security." > > He goes on to say that ownership of files created can be forced. > > Note that he is saying that they would not need a password to access the > shares. ---- your abbreviation removes the context that would make the last sentence above meaningful. 'security = share' does not automatically mean there is no password...only 'guest access = SOME_VALID_USER and guest ok = yes' can accomplish that. By the way I am also a member of the samba team and might actually know what I am talking about. ---- > > > The information is available in the man pages for smb.conf should either > > the OP or the other people trying to help actually want to solve the > > problem. > > > Very little information of this kind is available in the man pages. There is > a lot of information in the original samba.conf file, but if you use swat or > webmin to edit the file it will be overwritten and you will never see the > useful stuff. I always rename a copy for safe-keeping before editing. If > anyone needs a copy of the original I'm happy to supply one. ---- this information is very much supplied in the man pages of smb.conf - see below ---- > > > I don't know what the OP is actually trying to accomplish. Is it the > > ability to access without passwords? security = share would probably be > > ok but he should set a user and (map to guest = that user) and permit > > guest (guest ok = yes) on each share. > > Again, I disagree, based on the authority of JT. ---- Perhaps you are referring to something else then. Security = share does indeed require a password or adequate guest setup...no other way around it. ---- > > > The section within the man page of > > smb.conf 'security = share' completely describes this. > > There is no such section in the man page, so I presume you are referring to > another document. It would be helpful to know which one. ---- man smb.conf (admittedly this is from FC-4 installation) perhaps you are having trouble locating the section, which I will now quote... The different settings will now be explained. SECURITY = SHARE When clients connect to a share level security server they need not log onto the server with a valid username and password before attempting to connect to a shared resource (although modern clients such as Windows 95/98 and Windows NT will send a logon request with a username but no password when talking to a security = share server). Instead, the clients send authentication information (passwords) on a per-share basis, at the time they attempt to connect to that share. Note that smbd ALWAYS uses a valid UNIX user to act on behalf of the client, even in security = share level security. As clients are not required to send a username to the server in share level security, smbd uses several techniques to determine the correct UNIX user to use on behalf of the client. A list of possible UNIX usernames to match with the given client password is constructed using the following methods : · If the guest only parameter is set, then all the other stages are missed and only the guest account username is checked. · Is a username is sent with the share connection request, then this username (after mapping - see username map), is added as a potential username. · If the client did a previous logon request (the SessionSetup SMB call) then the username sent in this SMB will be added as a potential username. · The name of the service the client requested is added as a potential username. · The NetBIOS name of the client is added to the list as a potential username. · Any users on the user list are added as potential usernames. If the guest only parameter is not set, then this list is then tried with the supplied password. The first user for whom the password matches will be used as the UNIX user. If the guest only parameter is set, or no username can be determined then if the share is marked as available to the guest account, then this guest user will be used, otherwise access is denied. Note that it can be very confusing in share-level security as to which UNIX username will eventually be used in granting access. See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION. Craig
