UPD 2025:
I once again had this issue, and its due to 0 free space on disk. In this case you delete or update instance_id but after container start the issue will repeat itself and instnce_id file will remain empty, and SQL wont start ☝️
2023:
I had this exact issue today. It happened after I resized disk partition somehow.
At first I inspected docker volume and data seemed to be ok, however
/var/opt/mssql/.system/instance_id
wich is
/var/lib/docker/volumes/[YOUR-VOLUME]/_data/.system/instance_id
was empty!
Then I googled this thread https://github.com/microsoft/mssql-docker/issues/615 suggested to run chown 10001:0 on _data folder wich did not help.
Fortunately my docker is running inside Hyper-V vm. So I created checkpoint and reverted to previous one to see whats inside instance_id file
It turned out to be guid and 20 digit number
dfb10ba0-dc20-4022-ab31-0f52be4dcabe
16537894658124376490
I copied that and returned to latest checkpoint. Stopped container, updated instance_id with recovered data and container started seamlessly.
SQL Server on Linux stores the sequential UUID seed in /var/opt/mssql/.system/instance_id and increments it during startup. Take a backup of the instance_id file in case of system failure. If the file is lost, the seed is missing, and the new seed is regenerated. The initial seed generation is based on a random bit pattern and a UUID to avoid collisions. However, the new seed that has to be sequentially ordered may not be sequentially ordered after the seed is lost.