Fw: [linux-cifs-client] SAMBA no longer works (FC5 to FC5): READ
op. FAILS
Igor Chudov
ichudov at Algebra.Com
Thu Oct 19 14:19:55 GMT 2006
On Thu, Oct 19, 2006 at 09:14:20AM -0500, Igor Chudov wrote:
> On Wed, Oct 18, 2006 at 10:22:48PM -0500, Steve French wrote:
> > What I thought Igor was saying was that:
> >
> > mount -t smbfs //server/share /mnt -o userid=""
> >
> > worked but
> >
> > mount -t cifs //server/share /mnt -o userid=""
> >
> > only partially worked, ie mount succeeded but read failed.
>
> Yes.
>
> I just tried again. We have a companywide "shared drive" that is
> hosted on a unix box. People using Windows machines just connect to it
> without supplying password. (it is passwordless).
>
> I am trying to get this CIFS to do just that. Here are two tries,
> nonoe worked because CIFS does what it wants instead of what I want
> (passes root as user);
>
> FIRST TRY
>
> frankie:root:/etc ==>mount.cifs //pfs/lts /v -o 'user=,pass=' -v ; ls -l /v; umount /v
> parsing options: user=,pass=
>
> skipping empty user mount parameter
>
> mount.cifs kernel mount options unc=//pfs\lts,ip=10.1.8.23,user=root,ver=1,pass=
> ls: reading directory /v: Invalid argument
> total 0
Also, regarding these Invalid argument failures:
I did strace ls /v and got this:
open("/v", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0777, st_size=0, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
getdents64(3, 0x8b2ca8c, 4096) = -1 EINVAL (Invalid argument)
write(2, "ls: ", 4ls: ) = 4
write(2, "reading directory /v", 20reading directory /v) = 20
write(2, ": Invalid argument", 18: Invalid argument) = 18
write(2, "\n", 1
You can see that open directory for reading worked, but actual getdents64() failed with EINVAL.
i
> ANOTHER TRY
>
> frankie:root:/etc ==>mount.cifs //pfs/lts /v -o 'guest' -v ; ls -l /v; umount /v
> parsing options: guest
>
> mount.cifs kernel mount options unc=//pfs\lts,ip=10.1.8.23,user=root,ver=1
> ls: reading directory /v: Invalid argument
> total 0
>
>
> You can see that in BOTH instances is sends 'root' as the user instead of "guest".
>
>
>
> > There was a bug introduced by Samba server 3.0.23a (quickly fixed in
> > Samba 3.0.23b or 3.0.23c, but some distro's shipped 3.0.23a - type "smbd
> > -V" to see) that caused failure on read if using newer unix extensions
>
> Nope, my Samba is up to date
>
> frankie:root:/etc ==>smbd -V
> Version 3.0.23c-1.fc5
>
> > (thus the cifs client, but possibly not smbfs was affected) - but that
> > would have required that you changed the server. It would help if you
> > could please verify that you are not running the buggy 3.0.23a server.
>
> I am running a client for that drive which is hosted by another
> machine (this machine is also a samba server, but it is beside the
> point).
>
> > It is possible of course that cifs is negotiating a null userid
> > differently than smbfs, or that you have specified the one
> > unsupported security type for cifs that works for smbfs (e.g. krb5
> > only, via security settings in smb.conf), but I had not seen this
> > reported elsewhere - and to prove it conclusively we would have to
> > see if you authenticated differently in the two cases (for cifs you
> > can tell part of this by "cat /proc/fs/cifs/DebugData, but it is
> > probably easier to check via smbstatus on the server side).
>
> No, the problem is that mount.cifs does not do what it is told to do.
> It does not want to use a null user to authenticate.
>
> i
>
> > Shirish S Pargaonkar wrote:
> > >
> > >Igor, Steve,
> > >
> > >I just started latest samba (3.0.23c) on SLES9 and mounted a share
> > >from this server onto SLES10 machine with cifs vfs client (1.45) using
> > >-o "username=guest", when asked for password, typed some password
> > >(typed in bunch of keys) and mount completed successfully.
> > >On SLES10 (cifs vfs client), I can list the mounted directory and
> > >could cat a file successfully and edited a file too.
> > >Permissions on the client appear as they appear on the server i.e. the
> > >permissions on server remain intact, do not get modified.
> > >
> > >Igor, am I doing same thing as you are which you reported as
> > >problematic or doing something different?
> > >
> > >Regards,
> > >
> > >Shirish
> > >
> > >PM -----
> > >
> > > *Igor Chudov <ichudov at Algebra.Com>*
> > > Sent by:
> > > linux-cifs-client-bounces+shirishp=us.ibm.com at lists.samba.org
> > >
> > >
> > > 10/02/2006 10:19 AM
> > > Please respond to
> > > ichudov at Algebra.Com
> > >
> > >
> > >
> > >To
> > >
> > >SAMBA CIFS Client List <linux-cifs-client at lists.samba.org>
> > >
> > >cc
> > >
> > >
> > >Subject
> > >
> > >[linux-cifs-client] SAMBA no longer works (FC5 to FC5): READ op. FAILS
> > >
> > >
> > >
> > >
> > >I had a directory that was samba shared, from a server that runs FC5 to
> > >a client (laptop) that runs FC5 also.
> > >
> > >Everything worked (except when SAMBA became CIFS, anonymous logons
> > >stopped working), it was a read only share.
> > >
> > >Starting from a few days ago, it no longer works. I can still get
> > >directory listings, mount the "shared drive", etc, however, when I
> > >actually read the file (with cat, wc, mplayer etc) I get a strange
> > >"permission denied" error. That happens even though the perms are all
> > >good looking, I still cannot read. I think that I can open the file
> > >descriptor for reading, but the actual read operation fails.
> > >
> > >After a while of frustration, I ditched SAMBA entirely and switched to
> > >NFS, but I would like to know just what could have happened?
> > >
> > >(we have one dinky MS Windows computer at home, that we do not run a
> > >lot, but it would be nice to have samba available, though it is not
> > >hugely important).
> > >
> > >i
> > >_______________________________________________
> > >linux-cifs-client mailing list
> > >linux-cifs-client at lists.samba.org
> > >https://lists.samba.org/mailman/listinfo/linux-cifs-client
> > >
More information about the linux-cifs-client
mailing list