mbentley
commented
8 months ago I originally created the Dockerfile for the smb variant back in 2019 so it's been a while since any of this was done so there are likely some valid points to these. I imagine all I was doing back in 2019 was making sure that any paths where the container was actively writing data to the copy on write filesystem was in a volume of sorts.
/run/samba- yes, this can should be able to be mapped to a tmpfs and probably should be done so./var/cache/samba- based on this old reference, I don't see any tdb files that are considered persistent so this could be tmpfs I suppose. It's not much data at all so I doubt that performance is much of a consideration for this cache./var/lib/samba- based on this old reference, many of these are considered persistent data however when I read the descriptions, I am not sure I see any usage that would actually be done in order to test. If there is persistent data in these, I would expect that the container would be able to re-bootstrap all of that data as long as it ends up creating the users again. There might be some instances, like a container restart, where if this data was just tmpfs, it would cause issues because it would be expecting things like passwords to be saved. So this likely shouldn't be tmpfs but if it is data being written to the copy on write filesystem, that may be less than ideal from a "don't write anything to the CoW filesystem" mantra but wouldn't harm the function of the container.
Regardless of whether these are bind mounted, docker named volumes, unnamed volumes, tmpfs, or just left to be written to the copy on write filesystem, it's not really impacting the statelessness of the container - the persistent data of the time machine backup is doing that on it's own.
Now, I would need to test in an environment to see how these behave if they are configured any differently as the last thing I would want to do is lose someone's time machine backup due to a configuration change that wasn't tested properly. A basic test that should function pretty well would be to just map each of the volume paths as tmpfs filesystems. If the data doesn't matter, it will not be impacted by the two main instances where data loss would happen - container restarts or container re-creation. I suspect there would be issues with /var/lib/samba though if it were tmpfs so that would either just need to stay a volume or just let it be written to the copy on write filesystem.
Describe the Bug
Dockerfile.smb creates threee volumes:
/var/lib/samba,/var/cache/sambaand/run/sambaExpected Behavior
Do not create these volumes.
Steps to Reproduce
Build the Dockerfile.smb
How You're Launching the Container
Container Logs
Additional Context
I am not an expert with samba, but I don't see why it is needed to create these volumes, i.e. why should one want to persist the data in these folders.
/run/sambasounds like it should be backed by a tmpfs as /run is usually a tmpfs on linux./var/cache/sambasounds like it should potentially be a tmpfs to increase the cache performance/var/lib/sambaI have no idea why this data should be persisted or backed by anyTo follow Docker best practises to keep images as stateless as possible I would suggest to not create these Volumes in the Dockerfile.smb.