<html><body><p>Thanks for the recommendations. I'll work on collecting those captures and give the example a try. In the group/account name, there are several "unknown account" entries. There are 127 of them of ~330 entries total.<br><br>This will take some time. There's a time delay between my time and the folks I'm working with, plus I'm out on vacation until 5/3.<br><br><br>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="592" bgcolor="#FFFFFF" colspan="3" valign="middle"><hr width="100%" size="2" align="left" style="color:#CCCCCC; "></td></tr>
<tr valign="top"><td width="483" bgcolor="#FFFFFF" colspan="2"><b><font size="2" face="Verdana">Colin Dean<br>Advisory Software Engineer & Tech Lead, Watson Explorer Connectivity<br>email: </font></b><a href="mailto:colindean@us.ibm.com"><b><font size="2" color="#3399FF" face="Verdana">colindean@us.ibm.com</font></b></a><b><font size="2" face="Verdana"> | tel: +1 (412) 315-2066<br>Find me on:</font></b><font size="2" face="Verdana"> </font><a href="http://linkedin.com/in/colindean" target="_blank"><img src="cid:1__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="LinkedIn: http://linkedin.com/in/colindean" border="0"></a><font size="2" face="Verdana"> </font><a href="http://github.com/colindean" target="_blank"><img src="cid:2__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Github: http://github.com/colindean" border="0"></a><font size="2" face="Verdana"> </font><a href="http://launchpad.net/~colindean" target="_blank"><img src="cid:3__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Launchpad: http://launchpad.net/~colindean" border="0"></a><font size="2" face="Verdana"> </font></td><td width="109" bgcolor="#FFFFFF" rowspan="2" valign="bottom"><div align="right"><img src="cid:4__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="105" height="101" align="bottom"></div></td></tr>
<tr valign="top"><td width="165" bgcolor="#FFFFFF" valign="bottom"><img src="cid:5__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="163" height="23" alt="IBM Watson Group" align="bottom"></td><td width="314" bgcolor="#FFFFFF" valign="bottom"><a href="http://www.facebook.com/ibmwatson" target="_blank"><img src="cid:6__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Watson on Facebook: http://www.facebook.com/ibmwatson" align="bottom" border="0"></a><a href="https://twitter.com/@ibmwatson" target="_blank"><img src="cid:7__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Watson on Twitter: https://twitter.com/@ibmwatson" align="bottom" border="0"></a><a href="http://www.youtube.com/user/IBMWatsonSolutions/videos" target="_blank"><img src="cid:8__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Watson on YouTube: http://www.youtube.com/user/IBMWatsonSolutions/videos" align="bottom" border="0"></a></td></tr>
<tr valign="top"><td width="592" bgcolor="#FFFFFF" colspan="3" valign="middle"><hr width="100%" size="2" align="left" style="color:#CCCCCC; "></td></tr></table><br><br><br><img width="16" height="16" src="cid:9__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" border="0" alt="Inactive hide details for Michael B Allen ---04/28/2015 11:35:18---Hi Colin, This is a buffering error at the DCERPC layer. Dur"><font color="#424282">Michael B Allen ---04/28/2015 11:35:18---Hi Colin, This is a buffering error at the DCERPC layer. During the DCERPC bind, the</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Michael B Allen <ioplex@gmail.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Colin Dean/Pittsburgh/IBM@IBMUS</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">"jcifs@lists.samba.org" <jcifs@lists.samba.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">04/28/2015 11:35</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [jcifs] Unexpected fragment length exception when retreiving ACLs/SIDs on a file that has explicit permission granted to a deleted user</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><font size="4">Hi Colin,<br><br>This is a buffering error at the DCERPC layer. During the DCERPC bind, the client submits max_xmit and max_recv values that negotiate the largest buffer size that the client will transmit / receive. This value is hardcoded in JCIFS at 4280. This is observed Windows behavior and I don't recall ever seeing an issue with buffering like you're experiencing.<br><br>But apparently the server is returning a buffer that is much larger (28757). At first glance, this might look like a decoding error. Meaning the buffer begin decoded as a DCERPC message is actually total garbage. But I don't think this is the case because there is a DCERPC header sanity check just before the frag size check. So it looks like a legit DCERPC response. It's just that the fragment size is way to large for JCIFS to handle.<br></font><br><font size="4">I do recall that the max_xmit and max_recv values are actually suggested sizes and that the server can actually return more data. But I could be mis-remembering that.<br></font><br><font size="4">The Japanese characters could be involved but I somewhat doubt that it has anything to do with the ability to interpret the actual characters. It's more likely just a buffer size issue. If the SID names are Japanese strings, their encoding could be unexpectedly large.<br></font><br><font size="4">Just as a sanity check, try examples/SidLookup.java from the JCIFS package with one of the offending SIDs. What gets printed on the console might not be legible unless your on a Japanese workstation but it might still be enlightening.</font><br><br><font size="4">I would need to see a packet capture to diagnose this further (do not post captures to the mailing list! - send them to me directly). If you can get good network packet captures of a Windows client successfully resolving the SIDs and then another of JCIFS failing to resolve those same SIDs, then I would be happy to at least look at them. But to get good captures might be tricky. You might need to write a JCIFS program that takes a list of SIDs and calls resolveSids. And for Windows you might need to reboot the workstation, start the capture and then look at the ACL on the file using the file browser.<br></font><br><font size="4">If you look at the ACL of the file in the file browser, are the group / account names displayed correctly / successfully? Are there a lot?</font><br><br><font size="4">Unfortunately if it turns out that JCIFS is not correctly handling some kind of dynamic buffering, that could be a difficult fix. But you might be able to workaround by catching that particular exception and then recursively re-trying resolveSids with fewer SIDs (meaning divide the operation into 2 SID arrays and if it still fails, recur on each array with some depth limit). But I'm just thinking out loud. I would need to see captures to make a proper diagnosis.</font><br><br><font size="4">Mike<br></font><br><font size="4">PS: Do NOT send network packet captures to the mailing list. Send them only to me directly.</font><br><br><font size="4">On Mon, Apr 27, 2015 at 3:09 PM, Colin Dean <</font><a href="mailto:colindean@us.ibm.com" target="_blank"><u><font size="4" color="#0000FF">colindean@us.ibm.com</font></u></a><font size="4">> wrote:</font><ul><font size="5" face="Helvetica">Hello,</font><font size="4"><br></font><font size="5" face="Helvetica"><br>I’m encountering an unexpected exception while retrieving SIDs/ACLs for a file served by Windows Server 2012 Standard Edition. We’re running on Windows in this instance, if that matters.</font><font size="4"><br></font><i><font size="5"><br>Caused by: java.io.IOException: Unexpected fragment length: 28757<br> at jcifs.dcerpc.DcerpcPipeHandle.doReceiveFragment(DcerpcPipeHandle.java:96)<br> at jcifs.dcerpc.DcerpcHandle.sendrecv(DcerpcHandle.java:220) <br>at jcifs.smb.SID.resolveSids(SID.java:94)<br> at com.vivisimo.connector.smb.SMBConnector.resolveSids(SMBConnector.java:629) ... 10 more</font></i><font size="4"><br></font><font size="5"><br>This is approximately where our code hands off to jcifs to resolve the SIDs:</font><font size="4"><br></font><font size="5" face="Courier New"><br>SID[] sidsToResolveArray = sidsToResolve.toArray(new SID[0]);<br>try {<br>LsaPolicyHandle policyHandle = null;<br>try {</font><font size="4"><br></font><font size="5" face="Courier New"><br>policyHandle = handle.openPolicyHandle(file);<br>SID.resolveSids(handle.getHandle(), policyHandle, sidsToResolveArray);</font><font size="4"><br></font><font size="5" face="Courier New"><br>} finally {<br>if (policyHandle != null) {<br>LOGGER.debug("Closing Policy handle for [" + file + "]");<br>policyHandle.close();<br>}<br>policyHandle = null;<br>}<br>} catch (IOException e) {<br>throw new ConnectorException(e);<br>}</font><font size="4"><br></font><font size="5"><br>It dies shortly after we call SID.resolveSids() there in the middle of the inner try.</font><font size="4"><br></font><font size="5"><br>We have a few theories:</font><font size="4"><br></font><font size="5"><br>1. This filesystem has a lot of files with Japanese characters in the filename. We considered that perhaps jCIFS or our software using it lacks support for Japanese characters, but we set up a testing environment with a bunch of files with Japanese filenames and it works for us. We’re pretty certain that our configuration mirrors that of the erring environment, but there might be subtle differences were are not able to replicate (e.g. real data instead of made up test data).</font><font size="4"><br></font><font size="5"><br>2. All of the files that are failing (we’re crawling a filesystem) share one trait: they have what appears in the Windows properties a permitted user that shows as “unknown user”, which may be an artifact remaining after the user was removed but its explicit permissions remained. Processing on a directory that has no “unknown users” yields no failures.</font><font size="4"><br></font><font size="5"><br>This leads me to believe that jCIFS is failing on unknown users. However, looking through the source, I don’t see an obvious way to detect this.</font><font size="4"><br></font><font size="5"><br>The obvious workaround appears to be “clean your unknown users” but I think this could be detectable and loggable during our processing of the share.</font><font size="4"><br></font><font size="5"><br>I’d appreciate input on this.</font><font size="4"><br><br></font></ul><br>
<table border="0" cellspacing="0" cellpadding="0"><tr valign="top"><td width="588" bgcolor="#FFFFFF" colspan="3" valign="middle"><hr width="100%" size="2" align="left"></td></tr>
<tr valign="top"><td width="479" bgcolor="#FFFFFF" colspan="2"><b><font face="Verdana">Colin Dean<br>Advisory Software Engineer & Tech Lead, Watson Explorer Connectivity<br>email: </font></b><a href="mailto:colindean@us.ibm.com" target="_blank"><b><u><font color="#3399FF" face="Verdana">colindean@us.ibm.com</font></u></b></a><b><font face="Verdana"> | tel: </font></b><a href="tel:%2B1%20%28412%29%20315-2066" target="_blank"><b><u><font color="#0000FF" face="Verdana">+1 (412) 315-2066</font></u></b></a><b><font face="Verdana"><br>Find me on:</font></b><font face="Verdana"> </font><a href="http://linkedin.com/in/colindean" target="_blank"><img src="cid:1__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="LinkedIn: http://linkedin.com/in/colindean" border="0"></a><font face="Verdana"> </font><a href="http://github.com/colindean" target="_blank"><img src="cid:2__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Github: http://github.com/colindean" border="0"></a><font face="Verdana"> </font><a href="http://launchpad.net/~colindean" target="_blank"><img src="cid:3__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Launchpad: http://launchpad.net/~colindean" border="0"></a><font face="Verdana"> </font></td><td width="109" bgcolor="#FFFFFF" rowspan="2" valign="bottom"><div align="right"><img src="cid:4__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="105" height="101" align="bottom"></div></td></tr>
<tr valign="top"><td width="165" bgcolor="#FFFFFF" valign="bottom"><img src="cid:5__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="163" height="23" alt="IBM Watson Group" align="bottom"></td><td width="314" bgcolor="#FFFFFF" valign="bottom"><a href="http://www.facebook.com/ibmwatson" target="_blank"><img src="cid:6__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Watson on Facebook: http://www.facebook.com/ibmwatson" align="bottom" border="0"></a><a href="https://twitter.com/@ibmwatson" target="_blank"><img src="cid:7__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Watson on Twitter: https://twitter.com/@ibmwatson" align="bottom" border="0"></a><a href="http://www.youtube.com/user/IBMWatsonSolutions/videos" target="_blank"><img src="cid:8__=0ABBF4A4DF80679F8f9e8a93df938690918c0AB@" width="16" height="16" alt="Watson on YouTube: http://www.youtube.com/user/IBMWatsonSolutions/videos" align="bottom" border="0"></a></td></tr>
<tr valign="top"><td width="588" bgcolor="#FFFFFF" colspan="3" valign="middle"><hr width="100%" size="2" align="left"></td></tr></table>
<ul><font size="4"><br></font></ul><br><font size="4"><br><br><br>-- </font><br><font size="4">Michael B Allen<br>Java Active Directory Integration</font><u><font size="4" color="#0000FF"><br></font></u><a href="http://www.ioplex.com/" target="_blank"><u><font size="4" color="#0000FF">http://www.ioplex.com/</font></u></a><br><br><BR>
</body></html>