New Samba/VMS Release : build 20040908

John E. Malmberg wb8tyw at qsl.net
Thu Sep 9 19:25:27 GMT 2004


In article <CF0913E9C3D53D4E94DE47FDE25C633D050489AB at hermes.cofiroute.com>,
COLLOT Jean-Yves <jean-yves.collot at cofiroute.fr> writes:
> Hi.
>
>> 1. I can not get guest access to work.
> I think it works here, but may be I am not doing what you want to do.
> What I do is :
> - define SAMBA__GUEST as the "guest account" in SMB.CONF
> - define "Bad user" for the "map to guest" parameter (Never is the default)

Here was the problem.  In 2.0.6 it may have been a compile time option.  Over 3
years, and I am getting forgetful.

The documentation on it is correct and incorrect depending on how you
look at things.

It states that the "map to guest" only affects access to services that
are not shares.

That is not exactly true, but not exactly false.

If you have "map to guest" set to "never", you can access guest shares
from WINDOWS-95 and earlier with out supplying a username and password.

You can not from Windows NT 4.0 and later.  The reason is that they
request a list of services from the server, and that requires either
the "map to guest" account to be "bad user", or it requires that the
user supply a password to the account they are using.

So thank you for that fix.  And it looks like I need to supply a document
enhancement request to the UNIX samba team.

> And it works.
>
> In addition, if I define "2" as "log level", I have no timeout problem, and
> I get messages in the log such as :
> "connect to service share1 as user samba__guest" (for "guest ok = Yes"
> shares)
> "Invalid username/password for share2 [samba__guest]" (for "guest ok = No"
> shares)

I was trying between 4 and 8 as log level.  With SAMBA 2.0.6, I could usually
run at least a level 8 on smbd with out any timeouts, and that was even
with the output being directed to a terminal emulator.

>> I hope that it's decision is based on a file extension
>> (about the "VMS  Record Format" parameter)
>
> Actually, I added that feature because Mr Tapani Rundgren
> (Tapani.Rundgren at treville.se) asked for it. Mr Rundgren is using a software
> product that writes files on Samba/VMS shares, but separates the written
> lines by <LF> instead of <CR><LF>. This is the case, for example, if you use
> smbmount from a Linux box, and create text files with vi or any Linux tool.
> When a VMS program or procedure tries to read such files, it does not see
> any line terminator, and sees the files as if they have only one big line.
> The parameter gives the opportunity of "telling" VMS that the line
> terminator is a single <LF>. This is a parameter attached to the entire
> share (a similar option exists in Pathworks).

I was taking a different approach to solving that and a greater problem.

Samba needs to present the variable length text files from OpenVMS as
stream<CR><LF> for notepad to be able to read them.  And then if notepad
modifies the file, it needs to be written in the same format it originally
was in.

So for known text files, I was converting them on the fly so that a PC would
see them as streamcrlf, and VMS would see them in the format that the user
desired.

But other files should be treated as either stream files or binary files.
Some of it had to do with making sure that true RMS record locking would work
well.

I did not take the time to figure out how to make it share specific, which is
definitely preferable to making it global to the server.

But it is do able, and the code in my 2.0.6 almost works.  I ran out of time
to figure out the last part.

The problem is with large files, greater than 128Kb in size, and only shows
up in transfers from Microsoft Windows to a SAMBA server.

It never shows up with a transfer from SAMBA server to SAMBA client.

This is because SAMBA always transfers the file in order.  Microsoft Windows
does not, for the large file I was testing, SAMBA transfered about the first
32K bytes, then skipped 32K bytes of the file, and then transfered some middle
parts of the file, and then went back and filled in the parts that were
skipped.

For binary files, no problem.  For a text file opened in record mode, it gets
totally corrupted, as there is no way to know how many records were in the
section that was skipped.

But I did not want to have to convert files from VMS text format to one of the
stream formats before putting them on a SAMBA share.

> I don't understand what you mean by "basing the feature on a file
> extension". In my example (Samba share accessed thru Linux smbmount, and
> accessed thru some Windows box at the same time), a text file will have only
> <LF> when created from Linux, but will have <CR><LF> when created from
> Windows. I think that you can't securely assume that a given file comes from
> Linux because, for example, its extension is .lis, or from Windows because
> its extension is .txt

And when created from VMS will have a variable format, which is natively
unreadable to either LINUX or Microsoft Windows, unless SAMBA translates
the file contents one way or another.

As you say, there is no way to make an assumption, so I made it configurable
by the server administrator with the default to do no conversion.

-John
wb8tyw at qsl.net
Personal Opinion Only



More information about the samba-vms mailing list