We are currently developing a system that does automated BIOS updates for our computers.
The system runs in Windows 10 PE booted via PXE-Boot. One of the first steps is connecting to a SMB-Share where all the needed data is stored.
The share itself is hosted on Debian 4.9.88-1+deb9u1 with smbd Version 4.5.12-Debian.
The procedure needs multiple reboots and booting Windows PE again.
What we discovered is, that each system runs fine on first boot, but with every reboot to Windows PE, the connection to the SMB-Share takes more time and sometimes even times out with Windows error 63.
Since Windows PE is stored "new" in the RAM on each reboot and is not persistent, in our opinion the problem has to be on server-side.
The log files from Samba did not contain any errors regarding the connection of the hosts.
Mount Command in PE
NET USE B: \\SERVER\buffet \user:user password
Since Windows 10 is not allowing anonymous guest logins or shares without a password, not using login-credentials is not an option, despite the fact that I personally don't believe the problem has to do with authentication.
As you can see we already tried many timeout-configurations:
[global] workgroup = WORKGROUP security = user server role = standalone disable netbios = no server string = %h map to guest = Bad User obey pam restrictions = Yes passdb backend = tdbsam pam password change = Yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . unix password sync = Yes log file = /var/log/samba/log.%m log level = 10 winbind:5 auth:3 max log size = 1000 dns proxy = No usershare allow guests = Yes panic action = /usr/share/samba/panic-action %d create mask = 0777 directory mask = 0777 map hidden = no map system = no map archive = no store dos attributes = yes dos filemode = Yes acl map full control = Yes server min protocol = SMB3_10 socket options = TCP_NODELAY IPTOS_LOWDELAY read raw = yes write raw = yes server signing = no strict locking = no min receivefile size = 16384 use sendfile = Yes aio max threads = 250 aio read size = 1 aio write size = 1 ldap timeout = 3 deadtime = 1 winbind request timeout = 10 name cache timeout = 0 winbind max domain connections = 50 winbind max clients = 750 inherit owner = No [buffet] path = /share/buffet public = yes writeable = no browseable = yes guest ok = yes force user = nobody force group = nogroup read only = yes case sensitive = no default case = lower preserve case = yes short preserve case = yes
How we can fix the config so the hosts can make infinite reboots and still connect to the share instantly?
Attempts to fix it
We've tried several timeout settings as you can see in the
smb.conf above, but they all had no effect for our problem (conclusion is, that they cannot be the problem).
We've also pulled and analysed a ton of samba logfiles, where we tried to avoid any "failed" or "timeout" or whatever may point to an error due to misconfiguration and finally we solved them all, but nevertheless, the issue still persists.
We also tried some different DHCP server settings, like setting the default lease time to a very little value like ten seconds but again, this has no effect on our issue.
We had also tried to force Samba to use SMB2 or SMB3_11 but setting the used SMB protocol to a fixed value also wasn't able to fix the problem, that after three or four reboots of our winPE client, the SMB share will no longer connect immediately.
After a fast ping was successful, there is no high CPU / Memory load on the server, while the attempt to mount the share lasts. Also we monitored the network bandwidth using speedometer and we can only see really low loads (only few KB/s up and down) on the connection. The ping times itself do not increase during these laggy attempts to mount the share.