On Mon, Feb 7 at 13:43, Afshin Salek wrote:
On 02/ 7/11 10:05 AM, John Ryan wrote:
Hi,
I have 2 problems, that sound related, but might no be.
My server is running snv_134, and connected to an AD domain.
1. I'm using a CIFS share for my Windows roaming profiles. Sometimes, a
Windows machine complains it can't read the NTUSER.DAT file and logs the
user on with a temporary profile. Logging the user off, deleting their
profile, and restoring a previous version fixes the problem.
The file NTUSER.DAT exists in the proper place, and has the correct ACLs.
I don't recall that we've had any such problem report.
Could you qualify and/or quantify "sometimes" a bit more?
How often and/or with how many users does this happen?
Do you see this with a specific Windows version as client? If yes, what
version?
What's your domain controller OS (specific flavor)?
We had issues with all versions up through b134 where both windows
(win7 + winxp) and linux clients would occasionally stat a file and
get a null size and no permissions for it, even though it looked fine
from the ZFS/solaris side. As soon as another client tried to access
the same file, the first client would then be able to access it just
fine.
A snoop trace showed the following occuring every time a client got
the error:
SERVER RESPONSE
Command code = 0x32
Command name = SMBtrans2
SMB Status:
- Error class = Incorrect format.
- Error code = No error
The above response from a CIFS server will result in the CIFS client
seeing the file as garbage (0 length, no permissions, or other
oddities). I know there were changes in the response handling of an
SMBtrans2 between 134 and 147, but I don't understand the protocol
well enough to zone in on a "root cause".
When we upgraded to oi_147, the issue went away, and we're currently
running oi_148 without any problems.
--eric
--
Eric D. Mudama
edmud...@bounceswoosh.org
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
