Samba DC restore fails with same VPN IP address

[DavidePrincipi]

Samba DC restoration fails if the source DC was bound to the same VPN IP address available on the destination host, e.g. 10.5.4.1.

Steps to reproduce

• Configure a new AD domain with DC bound to VPN IPADDRESS 10.5.4.1
• Create a backup the Samba DC
• Remove Samba AD domain
• Restore the DC backup (with workaround for Samba DC restore fails with empty TimescaleDB #7834)

Expected behavior

Restore is successful, DC services are started, bound to 10.5.4.1, e.g.:

~]# ss -tulpn | grep 53
udp   UNCONN 0      0             10.5.4.1:53         0.0.0.0:*    users:(("dns[master]",pid=450501,fd=48))                                                                                   udp   UNCONN 0      0            127.0.0.1:53         0.0.0.0:*    users:(("dns[master]",pid=450501,fd=46))
tcp   LISTEN 0      10           127.0.0.1:53         0.0.0.0:*    users:(("dns[master]",pid=450501,fd=44))
tcp   LISTEN 0      10            10.5.4.1:53         0.0.0.0:*    users:(("dns[master]",pid=450501,fd=47)) 

Actual behavior

The samba-dc container enters a crashloop. Post-exec hook fails to bind port 53:

Jan 26 14:37:07 rl1 bash[71808]: /usr/bin/bash: line 1: /dev/tcp/10.5.4.1/53: Connection refused

The module environment has no PREFIXLEN variable set. This is wrong with VPN IP address, it should be PREFIXLEN=24 or similar. Samba needs PREFIXLEN if the interface (wg0) has no broadcast address, otherwise it fails to start its subsystems.

Components

• samba 3.4.1

See also

• Discussion PVT https://mattermost.nethesis.it/nethesis/pl/4xdtnseanfdoxmzg85cnjxo8uw

---

Thanks to @nrauso

[DavidePrincipi]

In Testing 3.4.2-dev.3

Test case 1

Check the bug is not reproducible.

If the original DC has a VPN IP address matching the node's VPN IP no error occurs.

Test case 2

Check the restore of a file server with LAN IP address still works.

[nrauso]

test cases VERIFIED