Yesterday I spent too much time in identifying what breaks the communication between SAMBA and Windows clients. In our environment, we have all data residing on the HPUX environment, and windows servers do the processing. The communication between HPUX CIFS and Windows was working fine until Thursday night, (Nightmare patching night).
What seemed obvious is you would rollback the patches and things should work fine but all things are not as simple as it looks. I thought first let me look at the SAMBA logging to see if the requests are coming and the reason for rejection.
What surprised me is that the version running does not provide me any detailed debugging option so i thought of upgrading the server from 2.0 to 3.0, by installing the new depot.
This after installation atleast proved me that the issue seems to be with the Windows system since the requests were not coming to the SAMBA.
Anyhow a learning that SMB signing is a feature to be used only in a pure windows environment.
For all those facing these issues i did the following steps to isolate the issue.
- First I checked the /etc/opt/samba/smb.conf file run the parser on the UAT
- swlist and swinstall –s depot
- I upgraded the samba to the 3.1.0 http://hp-ux-br.blogspot.com/2012/07/configuring-cifs-server-samba.html so that i can get detailed logging of the issue and find out the root cause
- CIFS-CLIENT A.02.02.02 HP CIFS Client
- CIFS-SERVER A.03.02.00 HP CIFS Server
- I reconfigured the users and gave access to root also for Samba directories
- The in the log I found that the request is not coming to the server.
- Then we disabled the end point protection
- Opened a case with HP where they mentioned they do not support individual software so I can open a forum case.
- In the forum, HP said it a Microsoft issue for which Microsoft released a patch, they told me to refer to these links
- http://www.networksteve.com/forum/topic.php/KB2536276_kills_SMB_access_to_old_Linux_Samba/?TopicId=22232&Posts=1
- And download and install this patch
- http://support.microsoft.com/kb/2560452/en-us
- Even after patch install, the request did not come to the Unix server.
- Then we checked that we were able to mount the access from other servers but not these UAT servers
- In the mean time we were reported of the similar issue on production after restart.
- Then I checked for some SMB blocking that we did as part of the Vulnerability management remediation.
- We referred the following link http://www.joseftschiggerl.name/2012/09/server-message-block-smb-signing-enable
- Since the server was restarted now that is the reason the setting became effective now.
- The we changed the AD setting
- Did the gpupdate /force couple of times and restarted the server
- We were able to map the drives without any issue without Microsoft TAC help
What seemed obvious is you would rollback the patches and things should work fine but all things are not as simple as it looks. I thought first let me look at the SAMBA logging to see if the requests are coming and the reason for rejection.
What surprised me is that the version running does not provide me any detailed debugging option so i thought of upgrading the server from 2.0 to 3.0, by installing the new depot.
This after installation atleast proved me that the issue seems to be with the Windows system since the requests were not coming to the SAMBA.
Anyhow a learning that SMB signing is a feature to be used only in a pure windows environment.
For all those facing these issues i did the following steps to isolate the issue.
- First I checked the /etc/opt/samba/smb.conf file run the parser on the UAT
- swlist and swinstall –s depot
- I upgraded the samba to the 3.1.0 http://hp-ux-br.blogspot.com/2012/07/configuring-cifs-server-samba.html so that i can get detailed logging of the issue and find out the root cause
- CIFS-CLIENT A.02.02.02 HP CIFS Client
- CIFS-SERVER A.03.02.00 HP CIFS Server
- I reconfigured the users and gave access to root also for Samba directories
- The in the log I found that the request is not coming to the server.
- Then we disabled the end point protection
- Opened a case with HP where they mentioned they do not support individual software so I can open a forum case.
- In the forum, HP said it a Microsoft issue for which Microsoft released a patch, they told me to refer to these links
- http://www.networksteve.com/forum/topic.php/KB2536276_kills_SMB_access_to_old_Linux_Samba/?TopicId=22232&Posts=1
- And download and install this patch
- http://support.microsoft.com/kb/2560452/en-us
- Even after patch install, the request did not come to the Unix server.
- Then we checked that we were able to mount the access from other servers but not these UAT servers
- In the mean time we were reported of the similar issue on production after restart.
- Then I checked for some SMB blocking that we did as part of the Vulnerability management remediation.
- We referred the following link http://www.joseftschiggerl.name/2012/09/server-message-block-smb-signing-enable
- Since the server was restarted now that is the reason the setting became effective now.
- The we changed the AD setting
- Did the gpupdate /force couple of times and restarted the server
- We were able to map the drives without any issue without Microsoft TAC help
No comments:
Post a Comment