Bug 5794 - Unable to access samba shares from windows 2003 R2 SP2 terminal server
Summary: Unable to access samba shares from windows 2003 R2 SP2 terminal server
Status: RESOLVED INVALID
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: File services (show other bugs)
Version: 3.2.3
Hardware: x86 Linux
: P3 critical
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-25 03:45 UTC by Erik Sørnes
Modified: 2008-12-11 03:13 UTC (History)
0 users

See Also:


Attachments
tar-gzip of /var/log/samba during the test. In addition smb.conf is there as well (311.36 KB, application/x-gzip)
2008-09-25 03:50 UTC, Erik Sørnes
no flags Details
tar-gzip of /var/log/samba during netmon trace of "net view \\lordvader" (179.58 KB, application/x-gzip)
2008-09-25 04:27 UTC, Erik Sørnes
no flags Details
gzipped smb.conf from lordvader (859 bytes, application/x-gzip)
2008-09-25 04:27 UTC, Erik Sørnes
no flags Details
netmon trace from the same timeframe the sambalogs are from (73.71 KB, application/x-gzip)
2008-09-25 04:29 UTC, Erik Sørnes
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Sørnes 2008-09-25 03:45:11 UTC
When trying to access samba shares from windows 2003 R2 SP2 I get "The specified network name is no longer available" and "System error 64 has occured"
Accessing the sambe sambamachines from windows 2000 and windows XP pc-clients goes without any problems. 

Accessing other windows server on the same subnet as the sambservers from the terminalservers goes fine.

I.e. Starte -> run -> \\<sambaserver>\<sharename> Results in the above error.

To isolate the problem I have picked one sambaserver which and one terminalserver and one command to test (net use \\lordvader), lordvader being the sambaserver with sles9, x86 and samba 3.2.3

Net use \\lordvader results int the above error messages.
I will upload debuglevel 10 output from lordvader during the above command + smb.conf + wireshark run from the test-server.

-regards
Erik
Comment 1 Erik Sørnes 2008-09-25 03:50:35 UTC
Created attachment 3631 [details]
tar-gzip of /var/log/samba during the test. In addition smb.conf is there as well

sambalogsandsmb.conf.tar.gz is an upload of the samba log dirctory during the run of "net view \\lordvader" + smb.conf
Comment 2 Erik Sørnes 2008-09-25 04:27:08 UTC
Created attachment 3632 [details]
tar-gzip of /var/log/samba during netmon trace of "net view \\lordvader"

tar-gzip of /var/log/samba during netmon trace of "net view \\lordvader"
Comment 3 Erik Sørnes 2008-09-25 04:27:40 UTC
Created attachment 3633 [details]
gzipped smb.conf from lordvader
Comment 4 Erik Sørnes 2008-09-25 04:29:05 UTC
Created attachment 3634 [details]
netmon trace from the same timeframe the sambalogs are from
Comment 5 Erik Sørnes 2008-09-25 04:39:52 UTC
>Net use \\lordvader results int the above error messages.

Sorry. The command i tested was "net view \\lordvader"
NOT "net use \\lordvader"

-regards
Erik
Comment 6 Erik Sørnes 2008-09-25 04:48:03 UTC
The terminalserver:
hostname: h1-586-os0025, ip 10.151.28.27
linux-samaba-sserver:
hostname: lordvader, ip 10.225.3.15

-regards
Erik
Comment 7 Erik Sørnes 2008-10-08 10:17:51 UTC
I have found the root cause for this problem.
The cause was that the windows Group Policy 
"Microsoft network client: Digitally sign communication (always)" was set to "enabled"
Setting this to "disabled" and all our samba servers became accessible to windows-machines on the network.
As I don't know if this samba 3.2.3 is supposed to support "Microsoft network client: Digitally sign communication (always)", I leave this bug in state NEW.

-kind regards
Erik
Comment 8 Erik Sørnes 2008-12-11 03:13:50 UTC
>As I don't know if this samba 3.2.3 is supposed to support "Microsoft network
>client: Digitally sign communication (always)", I leave this bug in state NEW.

The man pages for smb.conf says this is supported by setting 

"server signig = auto"

However we didn't see that so we solved the problem by setting digital singing to optional at the windows client side.