Jump to content
Jaster

MSSQL Docker on UnRaid

54 posts in this topic Last Reply

Recommended Posts

On 12/4/2019 at 6:53 PM, BoxOfSnoo said:

Yes, I'm on rc7.  I built mine using "Add Container" and plugging in the values as recommended above.

Well isn't that great, of course the Bitwarden version is crashing.

I just have to wait until they decide to upgrade the SQL container to a newer version.

I did notice the MCR version of SQL doesn't require the ulimits override anymore so that's nice.

 

I've collected my Bitwarden MSSQL logging and rolled back to 6.7.2, everything's fine now (so said cause I liked the new features).

Thanks for confirming this.

 

EDIT:

Now that were an additional four hours well spend.

So apparently the combination of the newer docker build with the MSSQL container trips over mounting volumes relatively to /mnt/user/appdata (so the unRAID filesystem).

The docker version shipped with unRAID version 6.7.2 (that was 18.x?) doesn't seem to care but now on 19.x this becomes a problem all of a sudden.

 

The reason why your container worked (I assume) was that you mounted directly onto the btrfs (orwhichever filesystem you're using) mountpoint on /mnt/cache. Docker seems to now like this better. Although this would break if the mover kicks in I don't really mind cause my appdata is cache only anyways.

 

I've updated the docker-compose.override.yml file to map them differently and the container is running fine now.

#
# Override file for the auto-generated docker-compose.yml file provided 
#   by Bitwarden
# This file mounts the volumes inside the MSSQL container directly onto 
#   the btrfs mountpoint instead of a relative path in the unRAID 
#   filesystem as the MSSQL container fails otherwise.
# The file also sets ulimits on the same MSSQL container, because with the 
#   ulimit stack size set to ulimited systemwide (as is the case on unRaid),  
#   the container refuses to start.
#
#########################################################################

version: '3'
   
services:
  mssql:
    volumes:
      - /mnt/cache/appdata/bitwarden/bwdata/mssql/data:/var/opt/mssql/data
      - /mnt/cache/appdata/bitwarden/bwdata/logs/mssql:/var/opt/mssql/log
      - /mnt/cache/appdata/bitwarden/bwdata/mssql/backups:/etc/bitwarden/mssql/backups
    ulimits:
     stack:
      soft: "8192000"
      hard: "8192000"

Cheers! 🍻

Edited by S1dney

Share this post


Link to post
21 hours ago, S1dney said:

Well isn't that great, of course the Bitwarden version is crashing.

I just have to wait until they decide to upgrade the SQL container to a newer version.

I did notice the MCR version of SQL doesn't require the ulimits override anymore so that's nice.

 

I've collected my Bitwarden MSSQL logging and rolled back to 6.7.2, everything's fine now (so said cause I liked the new features).

Thanks for confirming this.

 

EDIT:

Now that were an additional four hours well spend.

So apparently the combination of the newer docker build with the MSSQL container trips over mounting volumes relatively to /mnt/user/appdata (so the unRAID filesystem).

The docker version shipped with unRAID version 6.7.2 (that was 18.x?) doesn't seem to care but now on 19.x this becomes a problem all of a sudden.

 

The reason why your container worked (I assume) was that you mounted directly onto the btfs mountpoint on /mnt/user/cache. Docker seems to now like this better. Although this would break if the mover kicks in I don't really mind cause my appdata is cache only anyways.

 

I've updated the docker-compose.override.yml file to map them differently and the container is running fine now.

 

I wa about to say “no that’s not it” but I went and looked at my config and yup, that’s exactly it.  Since I copied and pasted, the /mnt/cache path was entered when I was typically using the /mnt/user/appdata path in all of my previous tests.

 

Interesting, and fantastic detective work!

Share this post


Link to post
On 12/4/2019 at 2:11 PM, S1dney said:

So apparently the combination of the newer docker build with the MSSQL container trips over mounting volumes relatively to /mnt/user/appdata (so the unRAID filesystem).

The docker version shipped with unRAID version 6.7.2 (that was 18.x?) doesn't seem to care but now on 19.x this becomes a problem all of a sudden.

 

The reason why your container worked (I assume) was that you mounted directly onto the btfs mountpoint on /mnt/user/cache. Docker seems to now like this better. Although this would break if the mover kicks in I don't really mind cause my appdata is cache only anyways.

Interesting. And of course you have a typo in this text that you didn't repeat in your mapping:

 

/mnt/user/cache would be a user share named cache, not the actual cache disk.

 

There have been reports of user shares giving problems with databases on other dockers. See here:

 

https://forums.unraid.net/bug-reports/stable-releases/sqlite-db-corruption-testers-needed-r598/

 

Share this post


Link to post
2 hours ago, BoxOfSnoo said:

Interesting, and fantastic detective work!

Hahah thanks, trial and error though this time ;)

 

4 minutes ago, trurl said:

Interesting. And of course you have a typo in this text that you didn't repeat in your mapping:

 

/mnt/user/cache would be a user share named cache, not the actual cache disk.

You're right. It was a long night :P

I will adjust it right away, I meant the mountpoint of the cache indeed instead of a user share.

 

6 minutes ago, trurl said:

There have been reports of user shares giving problems with databases on other dockers. See here:

 

https://forums.unraid.net/bug-reports/stable-releases/sqlite-db-corruption-testers-needed-r598/

 

Yeah I was aware of this, I wasn't affected by the bug though so I haven't dug into this too deep.

I might try a few versions later to switch back to the /mnt/user shares, but until that time for me this is a perfect workaround.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.