Offhand, after analysing the bug and the patches mentioned in the original description, I'm a bit skeptical that we're dealing with the same issue here.
The upstream bug expliciltly mentions a limitation with crypt_r on RHEL systems, and the person says that the underlying problem is that "... libfreeblpriv3.so tries to read /tmp as a file to update as an RNG cache during nspr init." This doesn't seem to be the case for Ubuntu.
I inserted a few debugging statements around the crypt_rn call, ran the samba-tool command, and noticed that there are two calls to crypt_rn: the first one seems valid (with valid phrase and salt arguments), but the second one contains a strange phrase which doesn't look like a string at all, and this is the call that causes the error to be thrown.
Offhand, after analysing the bug and the patches mentioned in the original description, I'm a bit skeptical that we're dealing with the same issue here.
The upstream bug expliciltly mentions a limitation with crypt_r on RHEL systems, and the person says that the underlying problem is that "... libfreeblpriv3.so tries to read /tmp as a file to update as an RNG cache during nspr init." This doesn't seem to be the case for Ubuntu.
I inserted a few debugging statements around the crypt_rn call, ran the samba-tool command, and noticed that there are two calls to crypt_rn: the first one seems valid (with valid phrase and salt arguments), but the second one contains a strange phrase which doesn't look like a string at all, and this is the call that causes the error to be thrown.