Closed yakhatape closed 1 year ago
After investigation on my side, I identify the following point :
1) We are using ansible to deploy the minio client
2) We identify inside the ansible code that minio service was started at the end of the deploiement but the ALIAS isn't managed on this step. So the minio Client start without any knowledge of the ALIAS referenced into the command which create this local directory.
3) sounds like minio client tell : "Oh I don't know this Alias so I will create it as a local directory"
4) minio client shoudn't return an error when an ALIAS doesn't exist into its config ?
- sounds like minio client tell : "Oh I don't know this Alias so I will create it as a local directory"
- minio client shoudn't return an error when an ALIAS doesn't exist into its config ?
No that is not what the intention here is, if you do not have an alias it behaves like unix cp
would in that scenario creating the directory and copying contents.
This is an expected designed behavior.
I'm using minio for syncing logs from servers to specific bucket and bucket path by their environnement.
Expected behavior
No local directory created on filesystem using the ALIAS and Bucket PATH informations
Actual behavior
Minio client used as a systemd service :
So the final command executed by the binary looks like :
/usr/local/bin/mc mirror --watch --overwrite /log/ MINIOS3/BucketsLogs/Production/PROmyServerName
I've create my Alias (name : MINIOS3) without any problem etc.. but the client minio is duplicating data from the /log/ directory to a local directory (created by the client) with ALIAS+PATH information in the root folder "/" :Which create a saturation of my "/" partition :
/dev/mapper/vg_os-root 3.9G 3.8G 0 100% /
PS : /log/ directory data are correctly sent to the bucket in same time ... How can I remove this behavior on local filesytem ?
Steps to reproduce the behavior
mc --version
System information
Operating System and version (uname -a):
Linux PROmyServerName 3.10.0-1062.18.1.el7.x86_64 #1 SMP Tue Mar 17 23:49:17 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux