Sun ZFS Storage 7420
 
Oracle ZFS Storage ZS5-2
 
Oracle ZFS Storage ZS3-2
 
Oracle ZFS Storage ZS4-4
 
Oracle ZFS Storage ZS5-4
 
Oracle ZFS Storage ZS3-4
 
Sun ZFS Storage 7120
 
Oracle ZFS Storage Appliance Racked System ZS4-4
 
Sun ZFS Storage 7320
 
Oracle ZFS Storage ZS3-BA
 

PLA-Support>Sun Systems>DISK>ZFS Storage>SN-DK: ZS
 

In this Document

Symptoms

Cause

Solution

References

Created from <SR 3-13221313721>

Applies to:

Symptoms

Access to ZFSSA SMB shares is very slow.

Users are no longer able to browse the ZFSSA shares list on SMB clients.

Making changes to ACLs fails with:

The program cannot open the required dialog box because it cannot determine
whether the computer named "xxx" is joined to a domain. Close this message
and try again." where "xxx" is the name of the ZFS storage.

The problem can be temporarily cleared by rejoining the ZFSSA to the AD domain or by restarting the idmap service, but it returns within hours or at most a few days.

Cause

A client application is opening a large number of pipes and disconnecting without properly closing the pipes, leading to a depletion of resources in an internal data structure.

Among other applications Microsoft OneNote and Access have been known to trigger this issue.

Analysis of the smbd core shows that ndr_pipe_table[] is full, all entries belonging to the same user:

> ndr_pipe_table::array |::print ndr_pipe_t np_refcnt
np_refcnt = 0x1                                                                <= 0x1 for all 128 entries

> ndr_pipe_table::array |::print ndr_pipe_t np_user.ui_account
np_user.ui_account = 0x9a3a1a8 "eduhamel"                     <= most likely the same user for all entries

In fact, the external application is not at fault. Failure to close these pipes is due to a bug in the ZFSSA software which gives an incorrect response to the application's filesystem info request (FS_INFO).
 

From snoop trace:

client opens IPC$\srvsvc - OK
getinfo FILE_INFO/FileStandardInformation - OK
getinfo FS_INFO/FileFsVolumeInformation - STATUS_FILE_CLOSED          <= response from appliance
getinfo FS_INFO/FileFsAttributeInformation - STATUS_FILE_CLOSED        <= response from appliance
       (the last two are in a compound request)
client opens IPC$\srvsvc - OK

... and the cycle begins again, the application considering srvsvc closed based on the appliance response.

AK allows file info requests but not filesystem info (FS_INFO) requests and should therefore respond with STATUS_NOT_SUPPORTED instead of STATUS_FILE_CLOSED (as per the SMB2 spec 3.3.5.20.2 "Handling SMB2_0_INFO_FILESYSTEM").

Solution

Bug 24331602 will be addressed in an upcoming release.  Look for it in the release notes of OS8.7.0.

See MOS Document ID 2021771.1 for current releases.
 

Fix available in:

IDR 8.6.5 IDR 2.1

OS8.7.0

References

This solution has no attachment