can't start minio server in ubuntu with systemctl start minio

Question

I configured a minio instance server on the ubuntu 18.04 with the guide from https://www.digitalocean.com/community/tutorials/how-to-set-up-an-object-storage-server-using-minio-on-ubuntu-18-04.

after the installation, the server failed to start with the command "sudo systemctl start minio", the error is saying :

root@iZbp1icuzly3aac0dmjz9aZ:~# sudo systemctl status  minio
● minio.service - MinIO
   Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2021-12-23 17:11:56 CST; 4s ago
     Docs: https://docs.min.io
  Process: 9085 ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES (code=exited, status=1/FAILURE)
  Process: 9084 ExecStartPre=/bin/bash -c if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in /etc/default/minio"; exit 1; fi (code=exited, status=0/SUCCESS)
 Main PID: 9085 (code=exited, status=1/FAILURE)

Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Main process exited, code=exited, status=1/FAILURE
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Failed with result 'exit-code'.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Service hold-off time over, scheduling restart.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Scheduled restart job, restart counter is at 5.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: Stopped MinIO.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Start request repeated too quickly.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: minio.service: Failed with result 'exit-code'.
Dec 23 17:11:56 iZbp1icuzly3aac0dmjz9aZ systemd[1]: Failed to start MinIO.
It looks like the reason is the Variable MINIO_VOLUMES not set in /etc/default/minio.

However, I double check the file from /etc/default/minio

MINIO_ACCESS_KEY="minioadmin"
MINIO_VOLUMES="/usr/local/share/minio/"
MINIO_OPTS="-C /etc/minio --address localhost:9001"
MINIO_SECRET_KEY="minioadmin"
I have set the value MINIO_VOLUMES.

I tried to start manually with minio server --address :9001 /usr/local/share/minio/, it works.

now I don't know what goes wrong with starting the minio server by using the systemctl start minio

Higgle

Please follow github.com/minio/minio-service/tree/master/linux-systemd/… – Esquimau

Answer 1

I'd recommend sticking to the official documentation wherever possible. It's intended for distributed deployments but the only real change is that your MINIO_VOLUMES will be for a single node/drive.

I would recommend trying a combination of things here:

1. Review minio.service and ensure the user/group exists
2. Review file path permissions on the MINIO_VOLUMES value

Now for the why:

My guess without seeing further logs (journalctl -u minio would have been helpful here) is that this is a combination of two things:

• the minio.service user/group doesn't have rwx permissions on the /usr/local/share/minio path,
• you are missing an environment variable we recently introduced to prevent users from pointing at their root drive (this was intended as a safety measure, but somewhat complicates these kinds of smaller setups).

Take a look at these lines in the minio.service file - I'm assuming that is what you are using based on the instructions in the DO guide.

If you ls -al /usr/local/share/minio I would venture it has ROOT permissions for user and group and limited write access if any.

Hope this helps - for further troubleshooting having at least 10-20 lines from journalctl is invaluable, as it would show the actual error and not just the final quit message.

Austro

Answer 2

Explanation:

1. Variable MINIO_VOLUMES not set in /etc/default/minio is NOT the error.
2. You have to look at the logs with journalctl -u minio command.

Possible Solution:

After you looked at the logs, you can see things like:

Sep 04 08:28:37 asus minio[43217]: Error: unable to create (/Volumes/data1/.minio.sys/tmp) file access denied, drive may be faulty please investigate (*fmt.wrapError)
Sep 04 08:28:37 asus minio[43217]:        6: internal/logger/logger.go:258:logger.LogIf()
Sep 04 08:28:37 asus minio[43217]:        5: cmd/prepare-storage.go:95:cmd.bgFormatErasureCleanupTmp()
Sep 04 08:28:37 asus minio[43217]:        4: cmd/xl-storage.go:250:cmd.newXLStorage()
Sep 04 08:28:37 asus minio[43217]:        3: cmd/object-api-common.go:61:cmd.newStorageAPI()
Sep 04 08:28:37 asus minio[43217]:        2: cmd/format-erasure.go:673:cmd.initStorageDisksWithErrors.func1()
Sep 04 08:28:37 asus minio[43217]:        1: internal/sync/errgroup/errgroup.go:123:errgroup.(*Group).Go.func1()
Sep 04 08:28:37 asus minio[43217]: Unable to use the drive /Volumes/data1: drive access denied
Sep 04 08:28:37 asus minio[43217]: Unable to use the drive /Volumes/data2: drive access denied
Sep 04 08:28:37 asus minio[43217]: Unable to use the drive /Volumes/data3: drive access denied
Sep 04 08:28:37 asus minio[43217]: Unable to use the drive /Volumes/data4: drive access denied

If that is the case and depending on your volumes, you can fix it like this:

sudo chown -R minio-user. /Volumes/data1 && sudo chmod u+rxw /Volumes/data1
sudo chown -R minio-user. /Volumes/data2 && sudo chmod u+rxw /Volumes/data2
sudo chown -R minio-user. /Volumes/data3 && sudo chmod u+rxw /Volumes/data3
sudo chown -R minio-user. /Volumes/data4 && sudo chmod u+rxw /Volumes/data4

Varitype

Answer 3

Run this first journalctl -u minio to see the error log. Read the error and fix it.

example of error log

Nubbin

Answer 4

I've also had a similar problem. But my case was super stupid, I set the data of MINIO_VOLUMES="/mnt/data" to a file instead of a directory, and it took me hours to solve... If anyone has the same problem as mine, don't forget to give access permission to the correct user after creating a directory for Minio.

Btw, I was about to comment under Cesar, but my reputation doesn't meet the requirement. journalctl -u minio really helps. It's clear and straightforward. You can use PageDown to move to the newest log to make sure the timestamp of the log matches :)

Colorado