SMBFS with EMC Celerra

From: Gordon Tetlow <gordon_at_FreeBSD.org>
Date: Thu, 10 Apr 2003 13:32:45 -0700
I've got a unique issue with SMBFS. Here at work we have an EMC Celerra
(big NAS storage) that has the ability to share out via CIFS. When I do
the mount_smbfs, everything seems to mount fine, but I get errors when
I try to stat a directory in the mounted FS:

gtetlow_at_roark:~$ sudo mount_smbfs -I dm3.lj.gnf.org -W DOMAIN //gtetlow_at_dm3/homedir1$ /mnt
Password:
gtetlow_at_roark:~$ mount
/dev/ad0s1a on / (ufs, local, soft-updates)
...
//GTETLOW_at_DM3/HOMEDIR1$ on /mnt (smbfs)
<everything looks good so far>
gtetlow_at_roark:~$ ls /mnt
ls: mnt: RPC struct is bad
gtetlow_at_roark:~$ ls /mnt/gtetlow
ls: gtetlow: RPC struct is bad
gtetlow_at_roark:~$ ls /mnt/foofoo
ls: /mnt/foofoo: No such file or directory
<so apparently it knows the directory structure, it's just unable to stat>

Accompanying the RPC struct is bad is the folling in /var/log/messages:
Apr 10 12:57:46 roark kernel: smb_maperror: Unmapped error 1:234
Apr 10 12:57:46 roark last message repeated 5 times

So 1 is the local error code (EPERM) and 234 is the remote error which is
probably "More data to be returned" which is shown later...

I did an ethereal trace of the transactions and here's what I get:
<from the mount_smbfs command>
...
115   5.111106 172.25.11.152 -> 172.25.24.15 NBSS Positive session response
116   5.111271 172.25.24.15 -> 172.25.11.152 SMB Negotiate Protocol Request
117   5.112223 172.25.11.152 -> 172.25.24.15 SMB Negotiate Protocol Response
118   5.114580 172.25.24.15 -> 172.25.11.152 SMB Session Setup AndX Request, User: DOMAIN\GTETLOW
119   5.142876 172.25.11.152 -> 172.25.24.15 TCP netbios-ssn > 61033 [ACK] Seq=4231982701 Ack=3262376903 Win=16384 Len=0
120   5.146310 172.25.11.152 -> 172.25.24.15 SMB Session Setup AndX Response
121   5.149613 172.25.24.15 -> 172.25.11.152 SMB Tree Connect AndX Request, Path: \\DM3\HOMEDIR1$
122   5.150548 172.25.11.152 -> 172.25.24.15 SMB Tree Connect AndX Response
...
<Everything looks good>
<from the ls /mnt>
126   6.720085 172.25.24.15 -> 172.25.11.152 SMB Transaction2 Request QUERY_FS_INFORMATION
127   6.720559 172.25.11.152 -> 172.25.24.15 SMB Transaction2 Response QUERY_FS_INFORMATION, Error: More data to be returned
128   6.723912 172.25.24.15 -> 172.25.11.152 SMB Transaction2 Request QUERY_FS_INFORMATION
129   6.724651 172.25.11.152 -> 172.25.24.15 SMB Transaction2 Response QUERY_FS_INFORMATION, Error: More data to be returned
130   6.727883 172.25.24.15 -> 172.25.11.152 SMB Transaction2 Request QUERY_FS_INFORMATION
131   6.728162 172.25.11.152 -> 172.25.24.15 SMB Transaction2 Response QUERY_FS_INFORMATION, Error: More data to be returned
132   6.731673 172.25.24.15 -> 172.25.11.152 SMB Transaction2 Request QUERY_FS_INFORMATION
133   6.732265 172.25.11.152 -> 172.25.24.15 SMB Transaction2 Response QUERY_FS_INFORMATION, Error: More data to be returned
134   6.735483 172.25.24.15 -> 172.25.11.152 SMB Transaction2 Request QUERY_FS_INFORMATION
135   6.735783 172.25.11.152 -> 172.25.24.15 SMB Transaction2 Response QUERY_FS_INFORMATION, Error: More data to be returned
136   6.739021 172.25.24.15 -> 172.25.11.152 SMB Transaction2 Request QUERY_FS_INFORMATION
137   6.739327 172.25.11.152 -> 172.25.24.15 SMB Transaction2 Response QUERY_FS_INFORMATION, Error: More data to be returned

From the looks of it, the server seems to be expecting something else to
happen between the Tree Connect AndX Response and the QUERY_FS_INFORMATION.

The only thing that looks odd about the transactions is that the reserved
field in the SMB header of the Tree Connect AndX Response (as noted by
Ethereal) is not all 0's which is about the only significant thing I can
see different between this trace and one where I attempt to mount a
Windows 2000 server.

This bug affects both FreeBSD and Mac OS X. I have the traces if you are
interested. I'll work on getting a trace from a windows client to the
Celerra to see if that exposes any steps that are missing.

-gordon

Received on Thu Apr 10 2003 - 11:32:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:03 UTC