Alpha 8.3 SAMBA CIFS V1.1 ECO1 PS9 errors

[Peter Barkas]

Error occurred but the relevant logfile had been deleted.

Running with debug level 4 creates many 10000 block debug files and it appears that the SAMBA VAR directory default version limit was 10.

Have changed the limit to 0 and now waiting for the next failure.

[Peter Barkas]

Windows server 2008 application reported Network access is denied at 14:40 on 11-May-2010.

Tried to attach debug file split in to small parts but all attempts failed with:

"Error while posting the reply"

So here's the last but before the error.

[2010/05/11 14:40:21, 4] SAMBA$SRC:[SOURCE.SMBD]TRANS2.C;1:(1955)

dptr_num is 256, wcard = *, attr = 22

[2010/05/11 14:40:21, 4] SAMBA$SRC:[SOURCE.SMBD]DIR.C;1:(339)

closing dptr key 256

[2010/05/11 14:40:21, 4] SAMBA$SRC:[SOURCE.SMBD]TRANS2.C;1:(2042)

SMBtrans2 mask=* directory=./ dirtype=22 numentries=33

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]PROCESS.C;1:(1086)

Transaction 111179 of length 90

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]PROCESS.C;1:(933)

switch message SMBtrans2 (pid 636344853) conn 0xb74038

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]UID.C;1:(176)

change_to_user: Skipping user change - already user

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]VFS.C;1:(734)

vfs_ChDir to dsa203:[jetform]

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]TRANS2.C;1:(1780)

call_trans2findfirst: dirtype = 16, maxentries = 1366, close_after_first=0, close_if_end = 2 requires_resume_key = 4 level = 0x104, max_data_bytes = 16384

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]DIR.C;1:(615)

creating new dirptr 256 for path ./, expect_close = 1

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]TRANS2.C;1:(1955)

dptr_num is 256, wcard = *, attr = 22

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]DIR.C;1:(339)

closing dptr key 256

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]TRANS2.C;1:(2042)

SMBtrans2 mask=* directory=./ dirtype=22 numentries=36

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]PROCESS.C;1:(1086)

Transaction 111180 of length 118

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]PROCESS.C;1:(933)

switch message SMBntcreateX (pid 636344853) conn 0xb74038

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]UID.C;1:(176)

change_to_user: Skipping user change - already user

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]VFS.C;1:(734)

vfs_ChDir to dsa203:[jetform]

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]OPEN.C;1:(1644)

calling open_file with flags=0x0 flags2=0x0 mode=00, access_mask = 0x20089, open_access_mask = 0x20089

[2010/05/11 14:40:26, 2] SAMBA$SRC:[SOURCE.SMBD]OPEN.C;1:(404)

jetformscif opened file JF_TST_OK.TST read=Yes write=No (numopen=1)

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]PROCESS.C;1:(1086)

Transaction 111181 of length 63

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]PROCESS.C;1:(933)

switch message SMBreadX (pid 636344853) conn 0xb74038

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]UID.C;1:(176)

change_to_user: Skipping user change - already user

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]VFS.C;1:(734)

vfs_ChDir to dsa203:[jetform]

[2010/05/11 14:40:26, 4] SAMBA$SRC:[SOURCE.SMBD]VFS.C;1:(734)

vfs_ChDir to dsa203:[jetform]

[2010/05/11 14:40:26, 0] SAMBA$SRC:[SOURCE.SMBD]SERVICE.C;1:(188)

chdir (dsa203:[jetform]) failed

[2010/05/11 14:40:26, 3] SAMBA$SRC:[SOURCE.SMBD]ERROR.C;1:(102)

error packet at SAMBA$SRC:[SOURCE.SMBD]PROCESS.C;1(998) cmd=46 (SMBreadX) NT_STATUS_NETWORK_ACCESS_DENIED

[Paul Nunez]

Hi Peter,

Well, unfortunately, nothing definitive. The best clue is the last error:

NT_STATUS_NETWORK_ACCESS_DENIED

With a debug level of 4 the log probably doesn't contain enough info to determine who CIFS thinks the user is. You may have to increase the level to 10 to get that info, but that's likely going to slow the server down.

Also, is the user expected to gain access to the dsa203:[jetform] directory based on the RMS protection mask or some ACE in the ACL?

You might also post $ SHOW DEV/FULL DSA203.

One thing I just noticed that is a bit different is the share paths for the 4 shares use the same directory name, but on 2 different volumes. Can you confirm that dsa203 is the correct device for the operation being attempted from the client? Is the client also accessing the shares on dsa607: at the time the problem occurs? Is there anything different between the security on dsa607:[jetform] vs. dsa203:[jetform]?

BTW, I don't think the "hosts allow" stuff works. I know the "interfaces" and "bind interfaces only" parameters don't. These types of restrictions have to be setup on the SMBD and SMBD445 TCP/IP services in order to be effective. FWIW, the up-coming V1.2 config procedures will do this for you.

Regards,

Paul

[Peter Barkas]

Paul

Thank you for the response.

Test environment, no ACEs everything is RWED.

Disk DSA203:, device type Generic SCSI disk, is online, mounted, file-oriented
device, shareable, available to cluster, error logging is enabled, device
supports bitmaps (no bitmaps active).

Error count 0 Operations completed 138917690
Owner process "" Owner UIC [COMPUTER,SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 3 Default buffer size 512
Total blocks 134217728 Sectors per track 128
Total cylinders 8192 Tracks per cylinder 128
Logical Volume Size 134217728 Expansion Size Limit 135794688

Volume label "APPLICATION3" Relative volume number 0
Cluster size 129 Transaction count 1
Free blocks 66067092 Maximum files allowed 516222
Extend quantity 5 Mount count 2
Mount status System Cache name "_DSA100:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 6606709
File ID cache size 64 Blocks in extent cache 2901081
Quota cache size 0 Maximum buffers in FCP cache 4244
Volume owner UIC [COMPUTER,WADE] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD

Volume Status: ODS-2, subject to mount verification, protected subsystems
enabled, write-back caching enabled.
Volume is also mounted on KRONOS.

Share on DSA203 (ODS2) is used for outgoing files, DSA607 (ODS5) is used for incoming. There was no incoming at the time of the error.

The 'client' is a Windows Server 2008 application polling DSA203 for files and depositing incoming files on DSA607. Incoming is event driven, so there is 'client' activity on the DSA607 share only when there is an incoming file.

DSA607 directories RWED.

'Hosts allow' seems to work, 'anyone' on the LAN can read, only W2008 server can write.

Peter

[Peter Barkas]

Apparently caused by a memory leak in directory enumeration code.

Expecting a patch from HP this week.

[P Muralidhar Kini]

Hi Peter,

Thanks for updating the thread with the root cause of the problem.
As per your update the problem does not seem to be with related to any
particular connection i.e. anonymous/non-anonymous, but its a bug in
directory enumeration code that can occur with any connection.

Regards,
Murali

[Peter Barkas]

Presumably more information may be included in any future release notes from HP.

However, I did forget to mention that apparently the issue arises only with shares hosted on ODS-2 disks.

[Peter Barkas]

Downloaded and installed patch yesterday.

No recurrence of the error since.

[P Muralidhar Kini]

Hi Peter,

>> No recurrence of the error since.
Thats Great. Bug Root caused, fixed and tested.
Nice and Happy ending indeed.

Regards,
Murali

[Verne Britton]

just for documentation here in ITRC if nothing else, is that patch now publicly available ... if so, what is the exact name of it ?

Verne

[Peter Barkas]

Patch I downloaded from HP was:

cifsv11eco1-alpha-v83-ps010_5.zip

Presumably this fix will be included in 1.2

[Peter Barkas]

Fix seems to have worked.