>[qssprod]
>          comment = share for QSSPROD
>          path = /QSSPROD/PUB
>          username = MGR.QSSPROD
>          writeable = Yes
>          guest ok = Yes

John Clogg already hit the nail on the head with his reply. Your
share is "guest ok" and will thus use the "guest account" from the
[global] section to access the files. The "username" is irrelevant
here, it would be used to check the password against, if you had
"guest ok = no". In that case I would also add "only user = yes",
because SMBD would otherwise use several other attempts to guess
the user (e.g. share name, windows logon, netbios name of client,
potentially mapped via user.map) to try the password against. This
can be confusing, thus I prefer to override with "username=x.y"
and "only user = yes".

For file access problems after successful "map network drive", it
is typically useful to examine the output of smbstatus (the showjob
of samba ;-) and check on which (MPE) user's behalf the access to
the files is performed for the share at hand. You can then logon as
that very user and try the same file access from CI or Shell to get
an idea why SMBD might fail to do what you want. The CI or Shell
has typically much better error messages (and means to examine the
permissions) then the Windows PC presents.

Two share definition examples that I typically use (besides [homes]):

 [alpha]
   comment = guest ok / public means: no password needed
   path = /ACCOUNT/GROUP
   guest ok = yes
   write ok = no
 ; guest account = user.account
 ; browseable = no


 [bravo]
   comment = this share requires MPE password validation
   path = /ACCOUNT/GROUP
   guest ok = no
   write ok = yes
   user = user.account
   only user = yes

For [alpha] you typically don't want "write ok" and "browseable"
at the same time, because popular worms can then find and use the
shared directory to try replicating themselves. No harm for MPE,
but for the potentially infected/corrupted files and other users
visiting the same share.

I believe, you can override "guest account" at the share level;
thus my commented line in the [alpha] example. Depending on the
MPE filesystem level permissions in /ACCOUNT/GROUP, you might
need this for successful file access/modification/creation from
the client side.

Lars.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *