LGTM.

However, I am wondering about the error message. Since we don't use shopt -s nullglob, /var/log/mail/* should be "expand" to /var/log/mail/* if there are no files in that directory:

# mkdir empty
# chmod 640 empty/*
chmod: cannot access 'empty/*': No such file or directory

# shopt -s nullglob
# chmod 640 empty/*
chmod: missing operand after ‘640’
Try 'chmod --help' for more information.

Thanks for spotting this, it'd trigger on first container setup too with a fresh volume mount that doesn't copy the images internal content.

Since we don't use shopt -s nullglob

We use it a few times in scripts. The setup call for getmail during initial container setup does set it which might continue to affect usage afterwards that follows outside the function? (I haven't verified, just a guess):

Thanks for pointing that out. You are right, I've overlooked that.

I'll review this today, please do not merge yet.

@georglauterbach the fix seems fine, it properly only applies to files, not that I think they'd be any directories in /var/log/mail/ itself.

The directory would be empty when given a fresh volume mount at container startup, or like the author during container restarts with tmpfs as well. Hence the error.

shopt -s nullglob should only accidentally be left enabled when the Getmail feature is enabled AFAIK. I assume that is a separate issue that should undo that to avoid surprises?

I just wanted to verify that there are not too many files, and no directories inside /var/log/mail. LGMT 👍🏼

The nullglob can be handled separately, but I do not see it as an issue, really.

Releasing v15.0.1 sounds like a good idea 👍🏼

The nullglob can be handled separately, but I do not see it as an issue, really.

It's an issue, but not a big one. OPs error message would be different, if getmail was not enabled. See my first post.

I think that should be streamlined. We could move the nullglob command to the top of start-mailserver.sh, making it consequently available to all code that is processed by start-mailserver.sh.