if you are using docker then your docker run command can have parameters that will overwrite the parameters in the config.yaml
not sure if that is the case, but only guess i really got.
your docker run command would look something like this.
docker run -d --restart unless-stopped --stop-timeout 300 -p 192.168.1.100:28967:28967/tcp -p 192.168.1.100:28967:28967/udp \
#--log-opt max-size=1m \
-p 192.168.1.100:14002:14002 -e WALLET="0x111111111111111111111" \
-e EMAIL="your@email.com" -e ADDRESS="global.ip.inet:28967" \
-e STORAGE="4TB" --mount type=bind,source="/sn3/id-sn3",destination=/app/identity \
--mount type=bind,source="/sn3/storj",destination=/app/config --name sn3 storjlabs/storagenode:latest \
--filestore.write-buffer-size 4096kiB --pieces.write-prealloc-size 4096kiB
when using this, if i was to change my email, storage size or some such thing in the config.yaml it will not be used, because its defined by my run command.
ofc only valid for stuff that is defined, everything else will use the config.yaml and if that isn’t defined it will use the default config.yaml which is buried somewhere in the node files.
not really that relevant, but … its how it works afaik
mostly just used to revert back if one messed up the config.yaml, then it can be deleted and the default one will be put in its place i believe.
I think this is more of a Synology docker problem. They obfuscate the run command.
Order of actions as always with docker (regardless of OS):
docker stop… containername
docker rm containername
docker run… containername
Is this what you did?
@peem if I remove the docker won’t I also lose all the data volumes?
I think I need to learn more about docker.
What did work for me was extracting the /etc/supervisor/supervisord.conf file from the container and manually editing the run parameters. Restart.
Works for now… ill monitor and try your method next time I need to make a change.
the docker container is pretty much irrelevant, its basically like an app…
the storagenode data and identity are in the location you mount when creating the docker container using the docker run command.
good job on finding that supervisord.conf file… digging so deep you can quickly get into all sort of trouble… since it’s all open source so you can pretty much do anything…
Command:
docker rm containername
removes the container from RAM, not from disk.
From removing the container from the disk there is another command 
Only you need to stop the container beforehand, in the case of storagenode software you need to give some time to stop the ongoing processes inside:
docker stop -t 300 containername
I recommend logging into the Synology via SSH and issuing these commands there in the CLI. From Synology’s GUI browser interface, you’ll have to work a lot harder to get the same results and it’s easier to make a mistake…
This is inside the container. There will be an update (new version) of the container and your modification in this file will disappear…