DMS has been working well for a few weeks. All messages lost now?

[Doni49]

A few weeks ago, I was able to get DMS working and I've enjoyed it. But today, I noticed that I'm not receiving any email messages. Upon investigation, I found that the DMS container wasn't running. When I checked on it, I found that I forgot to enable "restart unless stopped". So I enabled that and restarted the container.

When I did, the next time my mail client connected, all the messages that were in the client from the last connection were no longer there.

DMS is configured to connect to a remote mail server, download them locally and my mail clients read from the local DMS server. When I login to the remote server, I can see a bunch of email messages that have been waiting since yesterday for DMS to download.

Yesterday, I had a short power outage (less than a minute). So I think this is related to the power outage.

But now that I've restarted DMS, the new messages that were on the remote server when I first started troubleshooting this have been downloaded to the local server but the messages that WERE in the local inbox no longer there.

I've got a 1 TB SSD for storage with less than 1 GB used so it's not out of room.

[glime-ai[bot]]

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

---

It sounds like you're experiencing issues with DMS not downloading new messages from the remote server and also losing previously downloaded messages in your local inbox after a restart. This could be related to several factors including configuration settings, volume persistence, or issues triggered by the power outage affecting the container's state.

Here are a few steps you can take to troubleshoot and potentially resolve the issue:

1. Check Volume Configuration: Ensure that your Docker volumes are correctly set up to persist data across container restarts. This is crucial for maintaining the state of your emails and configuration. The volume for mail data should be properly mapped in your docker-compose.yml or Docker run command.

2. Review Logs: Check the logs of the DMS container for any errors or warnings that might indicate what went wrong. This can provide clues on whether the issue is with connectivity, authentication, or file system access.

3. Verify Remote Server Connectivity: Ensure that DMS can still connect to the remote mail server. Check network settings, firewall rules, and whether the remote server's IP or authentication details have changed.

4. Restart Services: Sometimes, simply restarting the sub-services within DMS can resolve issues. You can use commands like docker exec -it <container_name> supervisorctl restart <service_name> to restart services like Dovecot or Postfix.

5. Force Container Recreation: If configuration files might have been corrupted or not properly updated, recreating the container might help. Use docker-compose down followed by docker-compose up --force-recreate to ensure a clean state.

6. Check for Software Bugs or Issues: Look into the DMS GitHub issues page to see if others have reported similar problems or if there are any noted bugs that might be affecting your version of DMS.

If after these steps the issue persists, consider rolling back to a previous stable state if you have backups or snapshots of your Docker volumes. This can help determine if the issue is with the current state or a more systemic problem with the setup.

This comment was generated by Glime.

[Doni49]

I just stopped and restarted the DMS container. The messages that were downloaded today, survived the restart. So that seems to eliminate the possible issue of the volume not being persistent.

When I look at the logs, they're not helpful. They only show my connection today but don't say anything about deleting any messages.

Just before posting this, I went back and looked at the logs again. I did NOT see any of this in there the first time I looked but now I did find something that might help diagnose this but I'm unsure what to make of it.

It says the container was (likely) restarted incorrectly. I used portainer to restart it.

[   INF   ]  Welcome to docker-mailserver v13.3.1
[   INF   ]  Checking configuration
[ WARNING ]  This container was (likely) improperly restarted which can result in undefined behavior
[ WARNING ]  Please destroy the container properly and then start DMS again
[   INF   ]  Configuring mail server
sed: cannot rename /tmp/docker-mailserver/sedLj3sk5: Device or resource busy
sed: cannot rename /tmp/docker-mailserver/sed4nV6Sb: Device or resource busy
[ WARNING ]  !! INSECURE !! SSL configured with plain text access - DO NOT USE FOR PRODUCTION DEPLOYMENT
[ WARNING ]  'ONE_DIR=1' but no volume was mounted to '/var/mail-state'
chown: cannot access '': No such file or directory
[   INF   ]  Starting daemons
[   INF   ]  homeraspi5.home.arpa is up and running
May 24 19:04:34 homeraspi5 amavis[709]: starting. /usr/sbin/amavisd-new at homeraspi5.home.arpa amavisd-new-2.11.1 (20181009), Unicode aware, LC_CTYPE="C.UTF-8"
May 24 19:04:34 homeraspi5 amavis[709]: perl=5.032001, user=, EUID: 110 (110);  group=, EGID: 112 112 (112 112)
May 24 19:04:34 homeraspi5 amavis[709]: Net::Server: Group Not Defined.  Defaulting to EGID '112 112'
May 24 19:04:34 homeraspi5 amavis[709]: Net::Server: User Not Defined.  Defaulting to EUID '110'
May 24 19:04:34 homeraspi5 amavis[709]: No ext program for   .zoo, tried: zoo
May 24 19:04:34 homeraspi5 amavis[709]: No ext program for   .doc, tried: ripole
May 24 19:04:34 homeraspi5 amavis[709]: No decoder for       .F   
May 24 19:04:34 homeraspi5 amavis[709]: No decoder for       .doc 
May 24 19:04:34 homeraspi5 amavis[709]: No decoder for       .zoo 
May 24 19:04:34 homeraspi5 dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=10.10.0.245, lip=172.19.0.2, mpid=762, session=<t9aZ1jcZstsKCgD1>
May 24 19:04:40 homeraspi5 dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=10.10.0.245, lip=172.19.0.2, mpid=775, session=<ayf01jcZtdsKCgD1>

[polarathene]

It says the container was (likely) restarted incorrectly. I used portainer to restart it.

This is because DMS does not support docker restart, it needs to be force recreated.

When a container is restarted instead of re-created, it will persist any internal state that is not volume mounted. Only when the container is destroyed does it discard that state.

In Docker Compose docker compose down will destroy the container. If you only run docker compose up and then abort with CTRL+C for example, this is not equivalent to docker compose down the containers are not destroyed. A separate command can enforce that containers are recreated when they are started again, this is covered and explained in our troubleshooting/debugging docs page. I suggest you read that.

We do not have support for additional tooling like Portainer and anything it may do differently to affect the way DMS is run/managed. I would suggest you avoid the restart policy, since as our docs explain, DMS can be buggy when it does not have the original/fresh state it expects to work with when starting a container, hence the logged warning to alert you.

---

I just stopped and restarted the DMS container. The messages that were downloaded today, survived the restart. So that seems to eliminate the possible issue of the volume not being persistent.

As per the prior advice above, what you may have witnessed was the internal state being kept across a container restart. That's not the equivalent, when it's destroyed the data will be lost.

You've not shared much about your configuration. For the feature you describe you're presumably using Fetchmail or Getmail, these are community contributed.

We recently resolved a bug for Getmail that would try to store mail in a location that was internal only. Fetchmail should send to Dovecot if you've followed the docs for configuration, but Getmail isn't as obvious about that expectation AFAIK. View the :edge version of the docs as both pages have been updated for the next upcoming release (v14).