Changing the IP address of a Synology NAS sounds simple enough: change the address, update anything that points directly to the old address, and carry on.
In practice, if the NAS provides DNS, LDAP/domain services, NFS and SMB, there can be several hidden references to the old address.
I recently moved a Synology NAS from:
192.168.68.100 → 192.168.68.20
The NAS itself came back up, but several services behaved strangely. Here’s what was actually involved.
The symptoms
After changing the NAS IP:
- Windows could access the NAS by IP but didn’t initially show all the expected shares by hostname.
- The Raspberry Pi’s NFS mounts stopped working.
- The Pi couldn’t download packages from Debian repositories.
- Some domain/LDAP functionality was still referencing the old NAS address.
- DNS was resolving the NAS hostname to the old IP.
The important lesson was that the NAS IP had changed, but not every service had automatically followed the change.
1. Update the NAS DNS record
The first issue was the DNS record for the NAS.
The hostname was:
seido.order.realm
but DNS was still returning:
192.168.68.100
even though the NAS was now actually:
192.168.68.20
This produced a classic situation where:
\\192.168.68.20
worked correctly, while:
\\seido
could behave differently.
Updating the DNS record to:
seido.order.realm → 192.168.68.20
fixed the stale hostname resolution.
On Windows, this can be verified with:
nslookup seido
The expected result is:
Name: seido.order.realm
Address: 192.168.68.20
If Windows has cached the old result, flush the DNS cache:
ipconfig /flushdns
2. Check Domain/LDAP configuration
The Synology was also providing domain/LDAP-related functionality.
A reference to the old:
192.168.68.100
was still present in the Synology’s LDAP/domain configuration.
This is easy to overlook because changing the NAS’s primary IP doesn’t necessarily mean every configured service automatically updates its stored server address.
The LDAP/domain configuration was updated to use:
192.168.68.20
This was another important piece of the migration.
3. Check the Raspberry Pi’s DNS configuration
The Raspberry Pi initially appeared to have correct hostname resolution because /etc/hosts contained:
192.168.68.20 seido.order.realm seido
So:
getent hosts seido
correctly returned:
192.168.68.20
However, there was another stale reference hiding in /etc/resolv.conf.
It contained:
nameserver 192.168.68.100
search order.realm
The Pi was therefore still trying to use the old NAS address as its DNS server.
This explained why package downloads were hanging at:
Connecting to deb.debian.org
The resolver itself was pointing at an address that no longer existed.
The DNS server was changed to:
nameserver 192.168.68.20
search order.realm
After that, normal DNS resolution and package downloads worked again.
This is a particularly useful check when troubleshooting a NAS IP migration:
cat /etc/resolv.conf
Don’t just check /etc/hosts.
4. Check /etc/hosts
The Pi’s /etc/hosts was also checked and contained:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 NoobSaibot
192.168.68.20 seido.order.realm seido
The NAS entry was already correct.
It’s worth checking this whenever a server’s IP changes:
cat /etc/hosts
and looking for any references to the old address.
A broader search can also be useful:
grep -R "192.168.68.100" /etc 2>/dev/null
This can reveal old addresses hiding in configuration files.
5. SMB testing
Windows provided a useful way of separating DNS problems from SMB problems.
Initially:
\\192.168.68.20
showed the complete set of shares.
Meanwhile:
\\seido
was not initially behaving the same way.
That immediately suggested that the SMB service itself wasn’t necessarily broken — the hostname was resolving to or being associated with the wrong server information.
Once the DNS record and domain/LDAP references were corrected, the Windows network drives returned.
This is a useful troubleshooting technique:
Always test both the hostname and the IP address.
For example:
\\seido
versus:
\\192.168.68.20
If the IP works but the hostname doesn’t, don’t immediately blame SMB. Check DNS and server identity first.
6. NFS
The Raspberry Pi was using NFS mounts in /etc/fstab, for example:
Seido:/volume1/Raiden/ /home/Seido/Raiden nfs rsize=8192,wsize=8192,rw,dev,exec,suid 0 0
The Synology’s NFS exports were still present and could be queried with:
showmount -e seido.order.realm
The exports included the Raspberry Pi’s existing address:
192.168.68.88
So the Pi’s NFS permissions weren’t the immediate issue.
The important point is that NFS should be investigated separately from SMB. Having SMB working doesn’t necessarily mean NFS is correctly operating.
For NFS troubleshooting, useful tests include:
showmount -e seido.order.realm
and:
sudo mount -v -t nfs -o vers=4 192.168.68.20:/volume1/Raiden /home/Seido/Raiden
Using the IP in the second test is useful because it removes DNS from the equation completely.
7. What wasn’t changed
The Raspberry Pi’s own IP address was left alone.
It remains:
192.168.68.88
The intention to move it to .30 was deliberately put aside while troubleshooting the NAS migration.
This was the right approach because changing multiple network addresses simultaneously makes troubleshooting much harder.
Final checklist
When moving a NAS to a new IP, check all of these:
- NAS primary IP
- DNS A/host record
- Domain/LDAP server references
/etc/hostson Linux clients/etc/resolv.conf/ DNS configuration- SMB access by hostname
- SMB access by IP
- NFS exports
- NFS client permissions
fstabentries- Docker/container configurations
- Reverse proxy configurations
- Cloudflare Tunnel origin addresses
- Any scripts or applications using the old IP
The takeaway
The biggest lesson is simple:
Changing a server’s IP address doesn’t necessarily change every place that server’s old IP has been configured.
In this case, the Synology’s old .100 address was hiding in multiple places.
The most important ones we found were:
DNS:
seido.order.realm → 192.168.68.100
LDAP/domain configuration:
192.168.68.100
and on the Raspberry Pi:
/etc/resolv.conf:
nameserver 192.168.68.100
Once those stale references were corrected, the network started behaving normally again.
The key troubleshooting method was to test by IP and by hostname separately. That quickly showed whether the problem was actually the service or simply something still pointing at the old address.