== Sometimes brute force is the answer, Samba edition Like many places, we have a Samba server so that users with various sorts of laptop and desktop machines can get at their files. [[For good reason WhyNFSSamba]] the actual storage does not try to live on the Samba server but instead lives on [[our NFS fileservers ../solaris/ZFSFileserverSetupII]]. For similarly good reasons, people don't have separate Samba credentials; they use their regular Unix login and password. However, behind the scenes Samba has a separate login and password system, so we are actually creating and maintaining two accounts for people; a Unix one, used for most things, and a Samba one, used for Samba. This means that when we create a Unix account, we must also create a corresponding Samba account, which is done by using '_smbpasswd -a -n_' (the password will be set later). For a long time we've had an erratic problem with this, in that occasionally the _smbpasswd -a_ would fail. Not very often, but often enough to be irritating (since fixing it took noticing and then manual intervention). Our initial theory was that [[our _/etc/passwd_ propagation system OurPasswordPropagation]] was not managing to update the Samba server's _/etc/passwd_ with the new login by the time we ran _smbpasswd_. To deal with this we wrote a wrapper around _smbpasswd_ that explicitly waited until the new login was visible in _/etc/passwd_ and dumped out [[copious information ContextInErrorMessages]] if something (still) went wrong. Surely we had solved the problem, we figured. You can guess what happened next: no, we hadn't. Oh, it was clear that some of the problem was _/etc/passwd_ propagation delays, because every so often we could see the wrapper script report that it had needed to wait. But sometimes _smbpasswd_ still failed, reporting simply: .pn prewrap on > Unable to modify TDB passwd: NT_STATUS_UNSUCCESSFUL! > Failed to add entry for user . We could have spent a lot of time trying to figure out what was going wrong in the depths of Samba and then how to avoid it, staring at logs, perhaps looking at _strace_ output, maybe reading source, and so on and so forth. But we decided not to do that. Instead we decided to take a much simpler approach. We'd already noticed that every time this happened we could later run the '_smbpasswd -a -n _' command by hand, so we just updated our wrapper script so that if _smbpasswd_ failed it would wait a second or two and try again. This is a brute force solution, or really more like a brute force workaround. We haven't at all identified the cause or what we really need to do to fix it; we've simply identified a workaround that we can execute automatically without actually understanding the real problem. But it works (so far) and it did not involve us staring at Samba for a long time; instead we could immediately move on to productive work. Sometimes brute force and pragmatics are the right answer, under the circumstances. (It helps that account creation is a rare event for us.)