Use docker compose to arrange and deploy nginx and rustfs services, and report an error "SignatureDoesNotMatch" when accessing the console.
The current rustfs image version is the latest 1.0.0-alpha.73,Use docker compose to arrange the deployment of nginx and rustfs services. After accessing the nginx agent, the console login fails, and an error of 403 Forbidden is reported. The console response is printed as follows:
<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code></Error>
At the same time, the S3 API service after the nginx agent is accessed, and the error is reported as follows:
<Error>
<Code>UnauthorizedAccess</Code>
<Message>Your account is not signed up2, access_key: xxxx</Message>
</Error>
My docker-compose.yml document is as follows, which is written with reference to official documents:
networks:
app_network:
driver: bridge
services:
rustfs:
image: rustfs/rustfs:latest
container_name: pms-rustfs
security_opt:
- "no-new-privileges:true"
expose:
- "9000"
- "9001"
ports:
- "9000:9000" # S3 API 对外端口
- "9001:9001" # 控制台对外端口
environment:
# API 和控制台监听地址
- RUSTFS_ADDRESS=:9000
- RUSTFS_CONSOLE_ADDRESS=:9001
- RUSTFS_CONSOLE_ENABLE=true
# CORS 设置,控制台与 S3 API 都放开来源
- RUSTFS_CORS_ALLOWED_ORIGINS=*
- RUSTFS_CONSOLE_CORS_ALLOWED_ORIGINS=*
# 访问密钥(生产环境请修改为强密码)
- RUSTFS_ACCESS_KEY=xxxx
- RUSTFS_SECRET_KEY=xxxxxx
# 日志级别
- RUSTFS_OBS_LOGGER_LEVEL=info
volumes:
- /mnt/rustfs/data:/data
- /mnt/rustfs/logs:/app/logs
networks:
- app_network
restart: unless-stopped
healthcheck:
test:
[
"CMD",
"sh",
"-c",
"curl -f http://localhost:9000/health && curl -f http://localhost:9001/health",
]
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
nginx:
image: nginx:latest
container_name: pms-nginx
ports:
- "80:80"
- "8080:8080"
expose:
- "80"
- "8080"
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d:ro # 配置文件
- ./nginx/logs:/var/log/nginx # 日志目录
networks:
- app_network
depends_on:
- rustfs
restart: always
Nginx is also written with reference to official documents. The configuration is as follows:
# RustFS API服务代理
upstream rustfs_api {
least_conn;
server rustfs:9000;
}
# RustFS控制台代理
upstream rustfs_console {
least_conn;
server rustfs:9001;
}
server {
listen 80;
server_name 127.0.0.1;
# RustFS API服务
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Host $host;
# 关键配置:禁用 HEAD 请求转换,避免 S3 V4 签名失效
proxy_cache_convert_head off;
proxy_connect_timeout 300;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://rustfs_api;
}
}
server {
listen 8080;
server_name 127.0.0.1;
# RustFS控制台
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Host $host;
# 禁用 HEAD 请求转换
proxy_cache_convert_head off;
proxy_connect_timeout 300;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://rustfs_console;
}
}
It's hard work, In addition, there are also some rustfs log files that need to be supplemented。
This is the log when accessing the S3 API service:
{"timestamp":"2025-12-18T10:44:09.93966543Z","level":"WARN","fields":{"message":"load_user_identity failed: no such user, name: zlzx, user_type: Svc"},"target":"rustfs_iam::store::object","filename":"crates/iam/src/store/object.rs","line_number":442,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
{"timestamp":"2025-12-18T10:44:09.940032995Z","level":"WARN","fields":{"message":"load_user_identity failed: no such user, name: zlzx, user_type: Reg"},"target":"rustfs_iam::store::object","filename":"crates/iam/src/store/object.rs","line_number":442,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
{"timestamp":"2025-12-18T10:44:09.940416514Z","level":"WARN","fields":{"message":"load_user_identity failed: no such user, name: zlzx, user_type: Sts"},"target":"rustfs_iam::store::object","filename":"crates/iam/src/store/object.rs","line_number":442,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
{"timestamp":"2025-12-18T10:44:09.940485574Z","level":"WARN","fields":{"message":"get_user failed: no such user, access_key: zlzx"},"target":"rustfs::auth","filename":"rustfs/src/auth.rs","line_number":121,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
{"timestamp":"2025-12-18T10:44:09.940563762Z","level":"ERROR","fields":{"error":"S3Error { code: UnauthorizedAccess, message: \"Your account is not signed up2, access_key: zlzx\", .. }"},"target":"s3s::ops","filename":"/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/s3s-0.12.0-rc.4/src/ops/mod.rs","line_number":256,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
{"timestamp":"2025-12-18T10:44:09.940640283Z","level":"ERROR","fields":{"message":"failed to prepare","err":"S3Error(Inner { code: UnauthorizedAccess, message: Some(\"Your account is not signed up2, access_key: zlzx\"), request_id: None, status_code: None, source: None, headers: None })"},"target":"s3s::ops","filename":"/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/s3s-0.12.0-rc.4/src/ops/mod.rs","line_number":206,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
This is the log when logging in to the console page:
{"timestamp":"2025-12-18T10:46:54.529982371Z","level":"ERROR","fields":{"error":"S3Error { code: SignatureDoesNotMatch, .. }"},"target":"s3s::ops","filename":"/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/s3s-0.12.0-rc.4/src/ops/mod.rs","line_number":256,"threadName":"rustfs-worker","threadId":"ThreadId(15)"}
{"timestamp":"2025-12-18T10:46:54.530048395Z","level":"ERROR","fields":{"message":"failed to prepare","err":"S3Error(Inner { code: SignatureDoesNotMatch, message: None, request_id: None, status_code: None, source: None, headers: None })"},"target":"s3s::ops","filename":"/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/s3s-0.12.0-rc.4/src/ops/mod.rs","line_number":206,"threadName":"rustfs-worker","threadId":"ThreadId(15)"}
Please wait for our confirmation.
@MosonHe The issue is caused by your nginx configuration; please try to change proxy_set_header Host $host; to proxy_set_header Host $http_host;. After change the configuration, your configuration works fine for me; i can log in to the rustfs via ip:8080;
Please try and if have any other issue, update here and contact us. Thx,
@MosonHe The issue is caused by your nginx configuration; please try to change
proxy_set_header Host $host;toproxy_set_header Host $http_host;. After change the configuration, your configuration works fine for me; i can log in to the rustfs viaip:8080;Please try and if have any other issue, update here and contact us. Thx,
@majinghe Thank you very much for your help! According to your opinion, I modified the nginx configuration fileproxy_set_header Host $http_host and can indeed access the console page through port 8080. However, I found that I still cannot access the API service stored in the object. The reason why I reported the error UnauthorizedAccess was that my access key was somehow deleted. After I tried to recreate the key, the access error is consistent with the previous access to the console page, as shown below:
<?xml version="1.0" encoding="UTF-8"?><Error><Code>SignatureDoesNotMatch</Code></Error>
I also tried to modify the server block configuration where S3 API is located in nginx configuration file. Whether using proxy_set_header Host $host orproxy_set_header Host $http_host,is the same as the error reporting prompt mentioned above, I did not change other configurations, which is consistent with what was provided at the beginning. Please help again, thank you.
server {
listen 80;
server_name 127.0.0.1;
# RustFS API服务
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Host $host;
# 关键配置:禁用 HEAD 请求转换,避免 S3 V4 签名失效
proxy_cache_convert_head off;
proxy_connect_timeout 300;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://rustfs_api;
}
}
In addition, the error report log is consistent with the error report of the previous visit to the console page.
{"timestamp":"2025-12-18T16:18:52.074746187Z","level":"ERROR","fields":{"error":"S3Error { code: SignatureDoesNotMatch, .. }"},"target":"s3s::ops","filename":"/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/s3s-0.12.0-rc.4/src/ops/mod.rs","line_number":256,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
{"timestamp":"2025-12-18T16:18:52.074807903Z","level":"ERROR","fields":{"message":"failed to prepare","err":"S3Error(Inner { code: SignatureDoesNotMatch, message: None, request_id: None, status_code: None, source: None, headers: None })"},"target":"s3s::ops","filename":"/home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/s3s-0.12.0-rc.4/src/ops/mod.rs","line_number":206,"threadName":"rustfs-worker","threadId":"ThreadId(14)"}
I think I have found a new problem. Under the condition that rustfs has been deployed through docker compose, modifying the RUSTFS_ACCESS_KEY and RUSTFS_SECRET_KEY of the docker-compose.yml to other values, and then rearranging and starting the container will cause the rustfs access key to be emptied, and then the above problem will occur.
environment:
# 访问密钥(生产环境请修改为强密码)
- RUSTFS_ACCESS_KEY=rustfsadmin
- RUSTFS_SECRET_KEY=rustfsadmin
@MosonHe
I found that I still cannot access the API service stored in the object.
I don't understand what does this mean? API service stored in the object or access data stored in object via S3 API service?
@majinghe 十分抱歉,我已经找到访问API服务报错SignatureDoesNotMatch的原因。是我在修改docker-compose.yml文件中的RUSTFS_ACCESS_KEY 和RUSTFS_SECRET_KEY 后,重新部署容器,访问秘钥被自动删除,然后我手动添加之前的秘钥时,输入错误,现在我已经解决了这个问题,可以正常使用了。
所以请问修改RUSTFS_ACCESS_KEY 和RUSTFS_SECRET_KEY 会导致控制台访问秘钥被删除这个是正常的现象吗?
I am very sorry, I have found the reason why the access API service reported an error SignatureDoesNotMatch. It was after I modified the RUSTFS_ACCESS_KEY and RUSTFS_SECRET_KEY in the docker-compose.yml file that I redeployed the container, and the access key was automatically deleted. Then when I manually added the previous key, the input was wrong. Now I have solved this problem and can use it normally.
Therefore, is it normal to modify the RUSTFS_ACCESS_KEY and RUSTFS_SECRET_KEY to delete the console access key?
@MosonHe Cool, for ak&sk deletion, team will check, any result will update here.
In accordance with GitHub community principles.
Recommendation: Different issues should be addressed in separate issues.
In accordance with GitHub community principles.
Recommendation: Different issues should be addressed in separate issues.
OK, thank you again for your hard work. I will create a new issue to describe this problem.
In accordance with GitHub community principles. Recommendation: Different issues should be addressed in separate issues.
OK, thank you again for your hard work. I will create a new issue to describe this problem.
No problem.