smbfs/cifs and recent kernels

[Harry Putnam]

[Windbag alert: Long but please read if interested in cifs]

I'm still having trouble with cisfs mounts.  Briefly put: They mount
but cannot write to them.

I posted here about it and was told by at least one poster that I
should take it up with upstream mainters.  Further that they were
`very' interested in feedback.   

I did just that, and did get one reply message back that had some
helpfull info in it.  I tried the suggestions and wrote back with the
data from my tests.  Wrote again a week later to remind ... that was
several day ago.  So I'm not seeing the high interest suggested.

At any rate from what I understand from Dave's posts here; 
it (cifs) is being actively promoted by leaving smbfs out of the
kernel in the hope of getting people to `hammer' on cifs.

After I ran out of ideas for getting cifs mounted with write enabled
I decided to rebuild a recent kernel and enable smbfs.

With that done I can post a side by side comparison (included near
the end) but I'd like to ask why is cifs being promoted over smbfs?
What benefits might one expect from switching over.

The comparison is included below in a reprint of letter to Steven.
Note that the options used are the same (in fstab) but the results 
quite different. (cifs ends up readonly)
But since mounting the exact same share with smbfs allows write is
wouls seem to rule out problems on the windows config side.

Is it faster, more reliable etc etc?  Should most options work the
same?

And since cifs is being actively promoted here it seems appropriate
to discuss its virtues or lack of same here in this forum.

=====

Reprint of letter sent to upstream mainters (with cosmetic changes):
( I've taken the liberty of including part of Steven's reply since it
has good usefull info in case someone here is having trouble"

Steven French <sfrench at us.ibm.com> writes:

> To address a few of your questions smb.conf is not needed or used by the
> cifs vfs.
>
> The (0) in the mount options would represent flags but is not being
> populated by the kernel code or the mount table (I need to check which of
> the two routines is the one that populates this particular view of the
> mount status).   Mounts "r" vs. "rw" are not particular meaningful unless
> the kernel enforces them locally before it gets to the vfs (I need to check
> if that is the case) - the local "r" vs. "rw" flags are invisible to the
> server which does the authorization decision.   Likely the lack of ability
> to write is caused by the server thinking you are a different id, or one
> for which the ACL denies write.   

NOTE this [emphasis added -hp (NET SESSION can be typed in a dos window)]
> Try "NET SESSION" on the server to see
> what id the server thinks you are.   By doing "cat /proc/fs/cifs/DebugData"
> you may also be able to see if your user authenticated as a "guest" rather
> than a normal user.

Steven,
I sent you data from the suggested diagnostics above but never heard
back.  Since then I've backed up a few versions in kernels and
recompiled one to reinable smbfs.  Currently running kernel-2.6.1-1.65
with smbfs enabled.

I'm seeing something that appears to be an anomally.

First these are the mount parameters from fstab that I use for testing
the two protocols:

//192.168.0.15/J-ahn-d  /mnt/J-ahn-d  cifs   username=reader,password=""   0 0
//exp-xp/J-ahn-d  /mnt/J-ahn-d    smbfs   username=reader,password=""    0 0

I've been tinkering with parameters then comment one out and mount,
test etc.

(All commands are done as root)
What I'm seeing here is that mounted smbfs as above and the share is writable
umount comment out smbfs line and uncomment cifs line then,

Mount again:
Share is mounted but is read only.  The cifs code doesn't seem to
care about the notation for host name.  That is, cifs mounts with
either:
   //192.168.0.15/J-ahn-d
or
   //exp-xp/J-ahn-d

But what is causing the read only state?

As noted in my previous message... NET SESSION indicates share is
mounted as reader whether its smbfs of cifs

Aren't the options for smbfs and cifs mostly similar?

Is there something I'm overlooking in the parameters that has to be
different for cifs compared to smbfs.

What is supposed to be better about cifs?