Free ports 80 and 443 on Synology NAS

free_ports.sh

#! /bin/bash

# NEWLY ADDED BACKUP FUNCTIONALITY IS NOT FULLY TESTED YET, USE WITH CARE, ESPECIALLY DELETION
# Developed for DSM 6 - 7.0.1. Not tested on other versions.
# Steps to install
# Save this script in one of your shares
# Edit it according to your requirements
# Backup /usr/syno/share/nginx/ as follows:
# # cd /usr/syno/share/
# # tar cvf ~/nginx.tar nginx
# Run this script as root
# Reboot and ensure everything is still working
# If not, restore the backup and post a comment on this script's gist page
# If it did, schedule it to run as root at boot
#   through Control Panel -> Task Scheduler

HTTP_PORT=81
HTTPS_PORT=444

BACKUP_FILES=true # change to false to disable backups
BACKUP_DIR=/volume1/apps/free_ports/backup
DELETE_OLD_BACKUPS=false # change to true to automatically delete old backups.
KEEP_BACKUP_DAYS=30

DATE=$(date +%Y-%m-%d-%H-%M-%S)
CURRENT_BACKUP_DIR="$BACKUP_DIR/$DATE"

if [ "$BACKUP_FILES" == "true" ]; then
  mkdir -p "$CURRENT_BACKUP_DIR"
  cp /usr/syno/share/nginx/*.mustache "$CURRENT_BACKUP_DIR"
fi

if [ "$DELETE_OLD_BACKUPS" == "true" ]; then
  find "$BACKUP_DIR/" -type d -mtime +$KEEP_BACKUP_DAYS -exec rm -r {} \;
fi

sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)80\([^0-9]\)/\1$HTTP_PORT\2/" /usr/syno/share/nginx/*.mustache
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)443\([^0-9]\)/\1$HTTPS_PORT\2/" /usr/syno/share/nginx/*.mustache

if which synoservicecfg; then
  synoservicecfg --restart nginx
else
  synosystemctl restart nginx
fi

echo "Made these changes:"

diff /usr/syno/share/nginx/ $CURRENT_BACKUP_DIR 2>&1 | tee $CURRENT_BACKUP_DIR/changes.log

Tried Rev 14 of free_ports.sh on DSM 7.1.1-42962 Update 4.

Got the following errors
sed: no input files
./free-ports.sh: line 72: /usr/syno/share/nginx/Alias_v2.mustache: Permission denied
sed: no input files
./free-ports.sh: line 74: /usr/syno/share/nginx/Alias_v2.mustache: Permission denied

Everything else seemed to work.

Fixed some nano clitches

Just to follow up on https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7?permalink_comment_id=4420595#gistcomment-4420595

I ultimately went with this approach because I want to set it and forget it (without worrying that the next DSM update will break the script). The one draw back being that it uses the reverse proxy on the Synology NAS instead of changing the reverse proxies port so it's one more more hop for clients to go through.

Yes, best way to use reverse proxy settings.

Hello everybody,

thanks to @hjbotha and you guys for this solution!
I modified the script and it does the job for DSM 6.2.4-25556 Update 6 !
Yeaaaah!

You may want to use my modified script.
I did NOT change the replacements themselve, so the core of the original script is still the same.

Here is what I changed:

• removed option fo disable backups - WE WANT BACKUPS IF CHANGES ARE DONE!
• ... but if the script did NO changes, the backup of this run will be removed. Normally this is the case, if former modifications are still in place.
• only if changes were made they get reported
• only if changes were made NGINX gets restarted
• removed funcionallity to "restore" former changes

Why the "restore"-part was removed and how to restore then?
If someone modifies multiple times with different new ports it would be tricky to fiddle the right settings into the script, set the environment-vars and track the resulting changes. So I removed that completely.
If you need to restore just look in your backup-folder and restore the version you like manually. Because your backup-folder does not contain "useless" backups it's very easy to see the changes (changes.log) and replace files in /usr/syno/share/nginx/ with backups.

#! /bin/bash
# Script-source and discussion: https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7

# Developed for DSM 6 - 7.0.1. Not tested on other versions.
# run as root at boot through Control Panel -> Task Scheduler

# Ports to free - blocked by nginx on Synology
DEFAULT_HTTP_PORT=80
DEFAULT_HTTPS_PORT=443

# New ports to set instead
CUSTOM_HTTP_PORT=5080  # DO NOT USE 5000 
CUSTOM_HTTPS_PORT=5443 # DO NOT USE 5001 

# Backup-settings
BACKUP_DIR=/volume2/Backups/Settings/DSM-nginx
DELETE_OLD_BACKUPS=true
KEEP_BACKUP_DAYS=90

echo "Replacing port $DEFAULT_HTTP_PORT with $CUSTOM_HTTP_PORT"
echo -e "Replacing port $DEFAULT_HTTPS_PORT with $CUSTOM_HTTPS_PORT\n"

# Always backup...
BACKUP_DIR="$BACKUP_DIR/$(date +%Y%m%d-%H%M%S)"
echo "Backup Dir: "$BACKUP_DIR
mkdir -p "$BACKUP_DIR"
cp -r /usr/syno/share/nginx/* "$BACKUP_DIR"

if [ "$DELETE_OLD_BACKUPS" == "true" ]; then
  find "$BACKUP_DIR/" -type d -mtime +$KEEP_BACKUP_DAYS -exec rm -r {} \;
fi

# Replace ports as desired in mustache config files
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTP_PORT\([^0-9]\)/\1$CUSTOM_HTTP_PORT\2/" /usr/syno/share/nginx/*.mustache
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTPS_PORT\([^0-9]\)/\1$CUSTOM_HTTPS_PORT\2/" /usr/syno/share/nginx/*.mustache

# create changes.log
diff -r --exclude=changes.log /usr/syno/share/nginx/ "$BACKUP_DIR" > "$BACKUP_DIR/changes.log"

# remove backup if NO changes were made - else restart nginx
if [ $(stat -c%s "$BACKUP_DIR/changes.log") -eq 0 ]; then
	rm -f -r "$BACKUP_DIR"
	echo No changes detected, backup removed.
else
	echo "Made these changes:"
	cat "$BACKUP_DIR/changes.log"
	echo -e "\n[ ] Restarting Nginx..."
	if grep -q 'majorversion="7"' "/etc.defaults/VERSION"; then
		nginx -s reload
		echo "[✔] Nginx reloaded!"
	else
		if which synoservicecfg; then
			synoservicecfg --restart nginx
		else
			synosystemctl restart nginx
		fi
		echo "[✔] Nginx restarted!"
	fi
fi

@knilde i had to manually execute synosystemctl restart nginx for the settings to take effect. the script "only" did nginx -s reload.

sh-4.4# cat /etc.defaults/VERSION
majorversion="7"
minorversion="1"
major="7"
minor="1"
micro="1"
productversion="7.1.1"
buildphase="GM"
buildnumber="42962"
smallfixnumber="5"
nano="5"
base="42962"
builddate="2023/04/08"
buildtime="20:01:57"

If you have a domain, you can reverse proxy with synology dsm without any scripts.... just set Config Panel > External Access > Advanced to the following:

* Hostname: intranet.mydomain,com (any subdomain will do actually)

* DSM Http: something else than 80 (5080 for exemple)

* DSM Https: something else than 443 (5043 for exemple)

Then the reverse proxy will allow you to reverse proxy on port 80/443 as long as you specify a domain other than the one specified above, including the root domain,

Can you clarify what you mean here? I have synology.me domain specified in Control Panel -> Externl Access -> Advanced and ports other than 80/443, but when I create a SWAG container with ports 80/443 it still won't let me because the Syno's nginx reverse proxy is still listening on ports 80 and 443.

I am not sure that's what you meant with settings a SWAG container with port 80/443 but I don't recomend you to open the port 80 and 443 in your containers. as you know a docker container that can open a port below 1024 has host admin rights or something has been tempered with the container during build. This is not basically a docker feature but a linux kernel feature that is also present in dsm. That means a hacker who gets access to your container may freely do what they want with your docker host in that state.

That aside, the dns reverse proxy is not litteraly blocking port 80/443 as people suggest here. your DSM can be configured through the configuration panel to use ports other than 80/443 with the three settings mentioned above. Beyond that, the web station package can also blocking port 80/443 but it can be uninstalled if that is the case for you. I personally made the reverse proxy accept port 80/443 without a fuss without touching the web station package in the least and that resulted in having the web station package as a fallover of the reverse proxy when no entry match the request, I think that's pretty well designed. so well, the web station package is a problem only if you want to open the port 80/443 directory to your host network interface and not inside docker.

Please take a look at

All you need is to set the settings i mentioned above from the control panel to use ports other and 80/443 and ensure your synology server is accessed via a specified FQDN (synology doesn't explain that very well in its documentation) so if you have myserver.synology.me (i use a paid domain and not synology ddns so i required to setup a dns server with the dns package but it should be the same nonetheless since you have unlimited subdomains on your domain). So set your synology server configuration to be accessible through a subdomain, let's say dsm.myserver.synology.me and then the reverse proxy allows you to use anything else than that as an entry. For exemple you could setup swag.myserver.synology.me on port 80/443.

You container will not have port 80/443 (it shouldn't anyway) but the reverse proxy will forward the requests to your containers using port 80/443 for each subdomains you have an entry for in it.

@julichan Hello! Thank you for your very in-depth explanation for how to setup the ports and reverse proxy settings. You shed some light on a much better way to think of the ports and keeping it all safe. I can completely understand the red lines blocking the the specifics for your setup, but it leaves me wondering what subdomains you were exactly referencing. Would you please show your Synology reverse proxy with just the domain name changed to like domain? I already have SWAG running in Docker and have a working reverse proxy setup. I am not necessarily trying to abandon that in exchange for the built in one.

I was hoping I could pick your mind for the first reason that I found this post. I am trying to do something that I would think would be simple enough but is eluding me. Perhaps your knowledge can point me in the right direction. I realized when my internet was having an outage that my reverse proxy setup had broken. It proved that when I am interacting with my i.e. sonarr.domain.com, I am going out to to the net and back when I am accessing a service on my DS that's on the same switch as my PC. Could you shed some light on any ideas on how to locally access my docker services directly in same subnet, while keeping the same google domain DDNS working.

Thank you so much for any help you can offer with all this. You're explanations were awesome!

@pyrothebearded1, hello,
Indeed, your synology should still be accessible even if your internet went out from your lan as long as hubs and potential intermediate routers connecting your pc to your nas are still powered on. It might be pointing to a possible unwanted access to your nas from outside. You should check this out carefully.

In anyway, as i imagine your configuration, it was your gateway that was turned off and you couldn't access your nas anymore. You don't have a local dns server overriding the google dns or a similar configuration in your lan. Right? Check this with a simple ping or tracert on your url to ensure it's a lan ip and not your internet ip. If it's your internet ip, that means your network machines are resolving the dns entries from google. That means all your lan computers go through your gateway to access your nas when using the dns url. If your gateway use a lan loopback, your nas server may still be secure and just forward the requests to your nas allowing you access. If there is no loopback, that means you are accessing your nas as if going through the wan port of your gateway meaning it's accessible from outside. That possibility is highly dangerous for your nas. Either way, going through your gateway also remove all benefits from using dual port ethernet from your nas if you use that.

In my case, i have two dns configurations:

• one from google domain with pointing to my internet ip (both root domain and wildcard domain)
• one on my synology router is overriding the google domain one for my local network that point to the internal network ip of my nas. (You can also configure your router to point to dsm dns as a replacement and use the same dns server package)

I recently made a much more secure setup with 2 reverse proxies:

• the one from dsm is now used only to access private applications localy from my network and is still set to use ports 80/443
• i created a traeffik reverse proxy and bound ports 8080 and 8443 on my nas for public access. This reverse proxy is in a docker container and can only access docker containers on the same docker network.
  With those settings, my router is now forwarding external ports 80/443 to internal port of the nas 8080 and 8443 and apps accessible to both the public and private realm are configured in both reverse proxies.

If you want, you may just use one reverse proxy, the synology's one and point your router ports 80/443 to 80/443 but that means your nas and the private apps are only protected by access profiles and firewall. In my case, i consider safer a reverse proxy with no private app knowledge than one with filters that could be misconfigured.

So now for the dsm config, let's say my root domain is domain.net, my dsm is configured as nas.domain.net with port 5080 and 5443.
The synology reverse proxy is still listening to port 80/443 without any domaon restriction but i can add an entry for my app, let's use photoprism as an exemple, with the following settings:

• source: photoprism.domain.net
• port: 443
• hsts enabled (i'm not sure this has any effect unless you also setup port 80 but since it's internal use, it doesn't matter in this case)
• destination: localhost
• port: 3443 (in docker i bound the host port as 3443 with docker-compose ports directive for exemple)

Since the docker container has been configured to be bound to the host port, the destination localhost means to use the nas' port but localhost isn't filtered by the firewall since it s a nas loopback so you don't need to open the port 3443 on it. It can't be accessed by the port from outside the nas.

In the internal dns you create, you need to correctly reference the urls set to the nas ip to make sure you have access but in any case, you should still be able to access your nas via ip:5443 if you messed up your config.

I set up traefik reverse proxy in a similar way except it's bound on host port 8080/8443 of my nas but instead of targetting the entry to localhost:3443, I set its target to the container name and its internal port since it is in the same container network: http://photoprism-containter-name:internal-port

For this kind of setup its much easier to keep containers internal and host ports with identical values or it becomes a nightmare to manage.

Sometimes images are configured to use ports below 1024 and require admin rights which is docker default behaviour but most of the time this can be changed via a setting file or an environment variable.

Make sure to use the docker user directive with a userid and a groupid of 1000+ for very secure containers without any access to the nas. And especially those accessible from internet otherwise your nas is in serious danger. Your path volumes if you use any will however require same access rights. Please note that the user and group does not need to exist in your host system (your synology nas) which is how it becomes secure.
It's not always possible off course. If you have a portainer container and it needs access to /var/run/docker.pid file, this file requires root access anyway... Just don't expose that container to internet!
In the case of photoprism, you may want to manage your photos in a dsm share too, in this case, you ll need a dsm user and group set on this share and bind its ids to the docker user instead of using a non existant user.

On your reverse proxies, be it synology's or traeffik's or any other's you can also set access profiles to limit the source of access such as an internal ip or ip of specific countries which is very useful to increase the security of your device.

I hope that was a clear enough answer. My config is enterily set via docker-compose, ansible and ansible-semaphore rather than dsm and portainer. That gives more control but it's so insanely time consuming...

Hello everybody,

thanks to @hjbotha and you guys for this solution! I modified the script and it does the job for DSM 6.2.4-25556 Update 6 ! Yeaaaah!

You may want to use my modified script. I did NOT change the replacements themselve, so the core of the original script is still the same.

Here is what I changed:

* removed option fo disable backups - WE WANT BACKUPS IF CHANGES ARE DONE!

* ... but if the script did NO changes, the backup of this run will be removed. Normally this is the case, if former modifications are still in place.

* only if changes were made they get reported

* only if changes were made NGINX gets restarted

* removed funcionallity to "restore" former changes

Why the "restore"-part was removed and how to restore then? If someone modifies multiple times with different new ports it would be tricky to fiddle the right settings into the script, set the environment-vars and track the resulting changes. So I removed that completely. If you need to restore just look in your backup-folder and restore the version you like manually. Because your backup-folder does not contain "useless" backups it's very easy to see the changes (changes.log) and replace files in /usr/syno/share/nginx/ with backups.

#! /bin/bash
# Script-source and discussion: https://gist.github.com/hjbotha/f64ef2e0cd1e8ba5ec526dcd6e937dd7

# Developed for DSM 6 - 7.0.1. Not tested on other versions.
# run as root at boot through Control Panel -> Task Scheduler

# Ports to free - blocked by nginx on Synology
DEFAULT_HTTP_PORT=80
DEFAULT_HTTPS_PORT=443

# New ports to set instead
CUSTOM_HTTP_PORT=5080  # DO NOT USE 5000 
CUSTOM_HTTPS_PORT=5443 # DO NOT USE 5001 

# Backup-settings
BACKUP_DIR=/volume2/Backups/Settings/DSM-nginx
DELETE_OLD_BACKUPS=true
KEEP_BACKUP_DAYS=90

echo "Replacing port $DEFAULT_HTTP_PORT with $CUSTOM_HTTP_PORT"
echo -e "Replacing port $DEFAULT_HTTPS_PORT with $CUSTOM_HTTPS_PORT\n"

# Always backup...
BACKUP_DIR="$BACKUP_DIR/$(date +%Y%m%d-%H%M%S)"
echo "Backup Dir: "$BACKUP_DIR
mkdir -p "$BACKUP_DIR"
cp -r /usr/syno/share/nginx/* "$BACKUP_DIR"

if [ "$DELETE_OLD_BACKUPS" == "true" ]; then
  find "$BACKUP_DIR/" -type d -mtime +$KEEP_BACKUP_DAYS -exec rm -r {} \;
fi

# Replace ports as desired in mustache config files
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTP_PORT\([^0-9]\)/\1$CUSTOM_HTTP_PORT\2/" /usr/syno/share/nginx/*.mustache
sed -i "s/^\([ \t]\+listen[ \t]\+[]:[]*\)$DEFAULT_HTTPS_PORT\([^0-9]\)/\1$CUSTOM_HTTPS_PORT\2/" /usr/syno/share/nginx/*.mustache

# create changes.log
diff -r --exclude=changes.log /usr/syno/share/nginx/ "$BACKUP_DIR" > "$BACKUP_DIR/changes.log"

# remove backup if NO changes were made - else restart nginx
if [ $(stat -c%s "$BACKUP_DIR/changes.log") -eq 0 ]; then
	rm -f -r "$BACKUP_DIR"
	echo No changes detected, backup removed.
else
	echo "Made these changes:"
	cat "$BACKUP_DIR/changes.log"
	echo -e "\n[ ] Restarting Nginx..."
	if grep -q 'majorversion="7"' "/etc.defaults/VERSION"; then
		nginx -s reload
		echo "[✔] Nginx reloaded!"
	else
		if which synoservicecfg; then
			synoservicecfg --restart nginx
		else
			synosystemctl restart nginx
		fi
		echo "[✔] Nginx restarted!"
	fi
fi

Why can't we use 5000/5001?

This no longer works as of DSM 7.2. There's still a process remaining for nginx that uses port 443.

@KComrade53 I'm running 7.2.1. Have you made sure to double check all the DSM settings to make sure nothing is proxied or enabled? Have you tried to restart nginx / the nas?

@apearson I changed no settings, I just updated my synology to 7.2.1. I run the free_ports command as a scheduled task on boot and before the update it worked fine, but now netstat shows port 443 in use by nginx

I just wanted to let you know:

I have updated my Synology DS918+ with my modified Script from 6.2 to 7.1.

I had nothing to do to make the dockerizes NGNIX working after the updates.
Just installed the DSM Updates, reboot, still working! :-)