Username already taken - Table 'postfix.config' doesn't exist


I have a few issues with my /e/cloud self-hosting (main reason why I chose /e/OS over LineageOS with MicroG).

I have a dedicated server at OVH, which has nice capabilities and so I want to use it for 2 purposes : eCloud self-hosting and personal lab to test some things ^^

I run a Proxmox hypervisor on that server and I have roughly this architecture on it :

(cf. img 1)

The lab is connected to the OPT1 interface of pfSense (and for now there are no VMs running in that lab) and the Ubuntu Server 18.04 VM is connected to the LAN interface of pfSense.

I made sure that every DNS (and reverse DNS) record were properly configured and I enabled port forwarding to the Ubuntu VM for ALL the ports described in docs/ · develop · e / infra / ecloud-selfhosting · GitLab

I followed the installation steps from the, there were no errors in any of the returned output from the scripts.

I then generated a signup link with “bash /mnt/repo-base/scripts/”

I followed the link but when I tried to create a user, I got an error (cf. img 2)

It’s in french but it says : “The username “john.doenut” is already taken”

At first I tried the same username as my true email, then I tried a pseudo, and finally I tried a 12-characters random string. Same message everytime.

In the “create-account” container’s logs, it shows that the response is status 403 with message “username_taken”

If I change my directory to /mnt/repo-base and verify with docker-compose up -d (or docker ps) it shows that every container is up and running.

With the admin credentials generated with /mnt/repo-base/scripts/, I can connect to Nextcloud, access notes, agenda, files, settings, but when I want to access users, I get an error. (cf. img 3)

It basically says “Internal server error” / “The server can’t execute your request (etc.)”

spam.mydomain.fake gives me a “502 Bad Gateway” from the nginx server (cf. img 4)

and mail.mydomain.fake returns the following error : “DEBUG INFORMATION: SQLSTATE[42S02]: Base table or view not found: 1146 Table ‘postfix.config’ doesn’t exist
Check your error_log for the failed query” (cf. img 5)

This probably means something went wrong with postfix, but I don’t know how I can debug it and how to find more relevant information to resolve this problem.

Thank you for the time invested in looking into this.

Looks like a mariadb problem.

Please issue

docker restart mariadb
docker logs --details --follow --tail 40 mariadb

Then retry the user registration, and post back log content.

You can also try

docker exec -it mariadb mysql -u root -p

with value of MYSQL_ROOT_PASSWORD from /mnt/repo-base/.env

I restarted the mariadb container with the command you provided.

Then, I launched the command to show the logs, and after that I retried the user registration. Weirdly, the user registration didn’t generate new log lines :confused:

Otherwise, when I connect to the mariadb database through the command you supplied, I can show the different databases and tables for these databases. On the database “postfix” there isn’t any table :confused:

postfix database should have been populated by /mnt/repo-base/scripts/

This script is called by, which is called by

Did you keep logs and outputs from the installation process ?

At this point, you may want to cleanup and restart deployment …

Thanks for the reply :slight_smile:

I didn’t keep logs from the installation process, I don’t know where to find them. I have tried deleting the entire VM and starting from scratch mutiple times.

I will try to cleanup and restart deployement and this time keep the logs. In the meantime, here is what the script outputs when I try to run it :


Ok, I restarted from scratch and kept all of the ouput !
I don’t see any error except this one :

[ERROR ] Command ‘crontab -l’ failed with return code: 1
[ERROR ] stderr: b’no crontab for root\n’
[ERROR ] retcode: 1

There isn’t any crontab for the root user by default on Ubuntu 18.04. If I remember well, the crontab is only used for certificates renewal, so I might need to redo that but in the meantime, it shouldn’t affect the postfix and mariadb deployment :confused:

Do you have any idea of what I should look for in the scripts’ logs ?

Here is my root crontab (18.04 LTS, Hetzner) :

# Lines below here are managed by Salt, do not edit
# SALT_CRON_IDENTIFIER:refresh-tls-certs
@daily bash /mnt/repo-base/scripts/ >> /var/log/letsencrypt/letsencrypt-cron.log 2>&1

If setup scripts logs didn’t show any other error, you better redo test above, starting with postfix database content ! :slight_smile:

Has this issue ever been resolved?

Please read here : Ecloud-selfhosting updates?

Thanks for your reply, Sylvain! The Onlyoffice/community server part is commented out in my repo-base/docker-compose.yml, so that shouldn’t be an issue. Nevertheless the webbased update does not work and running in repo-base/volumes/nextcloud/data/ says there aren’t any updated. What I understand from your answer is that an update should resolve this issue and we shall be patient until that update comes officially, is that correct? Is there any other solution (terminal based) to gat the latest nextcloud update working for ecloud?

I won’t recommend upgrading /e/ NextCloud using standard methods (apps are ok).
Best way would be to have a freshly updated Docker image, that’s the way it’s designed to work.

Yes, please be patient :wink: