Microsoft Sentinel to Ingest Wasabi Bucket Logs

  • Published on Feb 23, 2026
  • 23 minute(s) read
Prev Next

Microsoft Sentinel is a Security Information and Event Management (SIEM) service that can be used to ingest Wasabi bucket logs to see S3 events affecting your bucket's data, such as when an object is uploaded or deleted. This requires the use of an on-premise server running Rclone to retrieve the logs from your Wasabi bucket and Logstash to send them to Sentinel, both of which are open-source.

Note that using Sentinel for analyzing and storing your bucket logs will incur additional charges from Microsoft.

This article details the procedure to configure your Wasabi buckets, Rclone, Logstash, and Sentinel (via Azure).

Prerequisites

  • An active Wasabi Cloud Storage account.

  • Wasabi access and secret keys.  It is recommended to create a sub-user with their own set of keys for this purpose rather than using your root keys. See Creating a User for more details.  You may also restrict what access the sub-user has, such as read-only access to a specific bucket, using IAM policies. See IAM and Bucket Policies for details.

  • Access to the Wasabi Console as the account's root user or a sub-user with WasabiFullAccess permissions.

  • A Linux server or virtual machine (VM).  This solution was tested using Ubuntu Linux 24.04.3 LTS, Rclone v1.72.1, and Logstash 8.19.10.  

  • An active Sentinel subscription that includes Log Analytics.

  • Access to the Azure portal with sufficient permissions.

High-Level Configuration Steps

  1.  Create a Wasabi “logging bucket” for storing logs from other buckets that store your data.  

  2.  Create a test bucket and configure it to send logs to the new logging bucket.

  3.  Install and configure Rclone to run as a service.

  4.  Install and configure Logstash.

  5.  Upload, download, and delete test objects to/from your test bucket.

  6. Observe Logstash creating a sample JSON file on your Linux server.  Save this file.

  7. Create a Data Collection Endpoint in Azure.

  8. Create a Data Collection Rule (DCR) based table in Azure Log Analytics.

  9. Register an Azure application and create a secret for it.

  10. Give the application appropriate permissions.

  11. Configure Logstash to run as a service.

  12. Create more test uploads and downloads to generate Wasabi bucket logs.

  13. Observe your bucket logs in Azure Log Analytics and/or Sentinel.

  14. Configure your other buckets to log to your logging bucket.

Creating a Wasabi Logging Bucket

  1. Log in to the Wasabi Console.  

  2. Create a Wasabi “logging bucket” for storing logs from other buckets. See Creating a Bucket for details on this procedure. Enable Object Lock and Versioning on this bucket during the creation process to make your logs immutable for a configurable period of time.  Note the name of this bucket and the region it is located in.

  3. Click Buckets and then click the name of your logging bucket.

  4. Click the gear icon on the right to open the bucket’s settings.

  5. Click the Object Lock tab.  Enable Default Object Retention, select the Enable Compliance Mode radio button, and enter the number of days and time scale you wish logs to be immutable for (where they cannot be deleted).  Click Apply.

  6. It is recommended to create a Lifecycle Policy to delete older log files.  Click Lifecycle, then click Create New Rule.

  7. Give the rule a name and select the radio button next to Apply to all objects in the bucket.  Scroll down.

  8. Under Actions, check the boxes next to Expire current version of objects and Permanently delete noncurrent versions of objects.  Enter the number of days after the object creation (for example, 91 days) and the days after the object becomes non-current (1 day).  This will fully delete a log file 92 days after it was created, which is two days after a log file’s immutability period is up since we previously configured a 90-day Object Lock Retention Time.  Scroll down.

  9. Click Save.

Creating a Wasabi Test Bucket

  1. Create a test bucket. It does not have to have Object Lock or versioning enabled.  This will be used for test object uploads, downloads, and deletions.  

  2. In the Wasabi console, click Buckets, then click the name of the bucket.

  3. Click the settings gear wheel on the right.

  4. Under Properties enable Bucket Logging.  Select the previously created logging bucket, and give a logging prefix (the name of the bucket works well).

  5. Click Save Settings.

Installing and Configuring Rclone

  1. Log in to your Linux server via Secure Shell (SSH). The commands given here were executed on Ubuntu 24.04.3 LTS.

  2. Install Rclone.

    sudo apt install rclone
  3. rclone config

  4. Create a new remote by entering “n”. 

    $ rclone config
                Current remotes:

                Name Type
                ==== ====
                wasabi s3

                e) Edit existing remote
                n) New remote
                d) Delete remote
                r) Rename remote
                c) Copy remote
                s) Set configuration password
                q) Quit config
                e/n/d/r/c/s/q> n

  5. Name the remote “wasabi”.

    Enter name for new remote.
                name> wasabi

  6. Enter the number associated with Amazon S3 Compliant Storage Providers (“4” in our example).

    Option Storage.
                Type of storage to configure.
                Choose a number from below, or type in your own value.
                1 / 1Fichier
                \ (fichier)
                2 / Akamai NetStorage
                \ (netstorage)
                3 / Alias for an existing remote
                \ (alias)
                4 / Amazon S3 Compliant Storage Providers including AWS, Alibaba, ArvanCloud, Ceph, ChinaMobile, Cloudflare, Cubbit, DigitalOcean, Dreamhost, Exaba, FileLu, FlashBlade, GCS, Hetzner, HuaweiOBS, IBMCOS, IDrive, Intercolo, IONOS, Leviia, Liara, Linode, LyveCloud, Magalu, Mega, Minio, Netease, Outscale, OVHcloud, Petabox, Qiniu, Rabata, RackCorp, Rclone, Scaleway, SeaweedFS, Selectel, Servercore, SpectraLogic, StackPath, Storj, Synology, TencentCOS, Wasabi, Zata, Other
                ...
                Storage> 4

  7. Enter the number associated with Wasabi. This is “44” in our example, but this number changes over time.

    Option provider.
                Choose your S3 provider.
                Choose a number from below, or type in your own value.
                Press Enter to leave empty.
                ...
                44 / Wasabi Object Storage
                \ (Wasabi)
                provider> 44

  8. Enter “1” to enter your Wasabi access and secret keys in the next step.

    Option env_auth.
                Get AWS credentials from runtime (environment variables or EC2/ECS meta data if no env vars).
                Only applies if access_key_id and secret_access_key is blank.
                Choose a number from below, or type in your own boolean value (true or false).
                Press Enter for the default (false).
                1 / Enter AWS credentials in the next step.
                \ (false)
                2 / Get AWS credentials from the environment (env vars or IAM).
                \ (true)
                env_auth> 1

  9. Enter your Wasabi access and secret keys. It is recommended to use a sub-user’s keys, not the root user’s keys.

    Option access_key_id.
                AWS Access Key ID.
                Leave blank for anonymous access or runtime credentials.
                Enter a value. Press Enter to leave empty.
                access_key_id> 8X9HK***************

                Option secret_access_key.
                AWS Secret Access Key (password).
                Leave blank for anonymous access or runtime credentials.
                Enter a value. Press Enter to leave empty.
                secret_access_key> vu6vZ3**********************************

  10. Enter “1” to use v4 signatures.

    Option region.
                Region to connect to.
                Leave blank if you are using an S3 clone and you don't have a region.
                Choose a number from below, or type in your own value.
                Press Enter to leave empty.
                / Use this if unsure.
                1 | Will use v4 signatures and an empty region.
                \ ()
                / Use this only if v4 signatures don't work.
                2 | E.g. pre Jewel/v10 CEPH.
                \ (other-v2-signature)
                region> 1

    This configuration example discusses the use of Wasabi's us-east-1 storage region. Use the region your bucket is located in. For a list of regions, see Available Storage Regions.

    Option endpoint.
                Endpoint for S3 API.
                Required when using an S3 clone.
                Choose a number from below, or type in your own value.
                Press Enter to leave empty.
                1 / Wasabi US East 1 (N. Virginia)
                \ (s3.wasabisys.com)
                2 / Wasabi US East 2 (N. Virginia)
                \ (s3.us-east-2.wasabisys.com)
                3 / Wasabi US Central 1 (Texas)
                \ (s3.us-central-1.wasabisys.com)
                4 / Wasabi US West 1 (Oregon)
                \ (s3.us-west-1.wasabisys.com)
                5 / Wasabi CA Central 1 (Toronto)
                \ (s3.ca-central-1.wasabisys.com)
                6 / Wasabi EU Central 1 (Amsterdam)
                \ (s3.eu-central-1.wasabisys.com)
                7 / Wasabi EU Central 2 (Frankfurt)
                \ (s3.eu-central-2.wasabisys.com)
                8 / Wasabi EU West 1 (London)
                \ (s3.eu-west-1.wasabisys.com)
                9 / Wasabi EU West 2 (Paris)
                \ (s3.eu-west-2.wasabisys.com)
                10 / Wasabi EU South 1 (Milan)
                \ (s3.eu-south-1.wasabisys.com)
                11 / Wasabi AP Northeast 1 (Tokyo) endpoint
                \ (s3.ap-northeast-1.wasabisys.com)
                12 / Wasabi AP Northeast 2 (Osaka) endpoint
                \ (s3.ap-northeast-2.wasabisys.com)
                13 / Wasabi AP Southeast 1 (Singapore)
                \ (s3.ap-southeast-1.wasabisys.com)
                14 / Wasabi AP Southeast 2 (Sydney)
                \ (s3.ap-southeast-2.wasabisys.com)
                endpoint> 1
            

  11. Press Enter to leave the location constraint empty.

    Option location_constraint.
                Location constraint - must be set to match the Region.
                Leave blank if not sure. Used when creating buckets only.
                Enter a value. Press Enter to leave empty.
                location_constraint>

  12. Enter “1” in the Option acl step.

    Option acl.
                Canned ACL used when creating buckets and storing or copying objects.
                This ACL is used for creating objects and if bucket_acl isn't set, for creating buckets too.
                For more info visit https://docs.aws.amazon.com/AmazonS3/latest/dev/acl-overview.html#canned-acl
                Note that this ACL is applied when server-side copying objects as S3
                doesn't copy the ACL from the source but rather writes a fresh one.
                If the acl is an empty string then no X-Amz-Acl: header is added and
                the default (private) will be used.
                Choose a number from below, or type in your own value.
                Press Enter to leave empty.
                / Owner gets FULL_CONTROL.
                1 | No one else has access rights (default).
                \ (private)
                / Owner gets FULL_CONTROL.
                2 | The AllUsers group gets READ access.
                \ (public-read)
                / Owner gets FULL_CONTROL.
                3 | The AllUsers group gets READ and WRITE access.
                | Granting this on a bucket is generally not recommended.
                \ (public-read-write)
                / Owner gets FULL_CONTROL.
                4 | The AuthenticatedUsers group gets READ access.
                \ (authenticated-read)
                / Object owner gets FULL_CONTROL.
                5 | Bucket owner gets READ access.
                | If you specify this canned ACL when creating a bucket, Amazon S3 ignores it.
                \ (bucket-owner-read)
                / Both the object owner and the bucket owner get FULL_CONTROL over the object.
                6 | If you specify this canned ACL when creating a bucket, Amazon S3 ignores it.
                \ (bucket-owner-full-control)
                acl> 1

  13. Enter “n” for the Advanced configuration.

    Edit advanced config?
                y) Yes
                n) No (default)
                y/n> n

  14. Enter “y” to keep the remote configuration.

    Configuration complete.
                Options:
                - type: s3
                - provider: Wasabi
                - access_key_id: 8X9HK***************
                - secret_access_key: vu6vZ3**********************************
                - endpoint: s3.wasabisys.com
                - acl: private
                Keep this "wasabi" remote?
                y) Yes this is OK (default)
                e) Edit this remote
                d) Delete this remote
                y/e/d> y

  15. Enter “q” to quit the configuration.

    Current remotes:

                Name Type
                ==== ====
                wasabi s3

                e) Edit existing remote
                n) New remote
                d) Delete remote
                r) Rename remote
                c) Copy remote
                s) Set configuration password
                q) Quit config
                e/n/d/r/c/s/q> q

  16. Start Rclone with the following commands to create a local directory and test connectivity to your Wasabi bucket. Replace YOUR_USER and YOUR_GROUP with your Linux user and group and YOUR_LOGGING_BUCKET with the name of your logging bucket.  

    sudo mkdir /mnt/wasabi-logs/
sudo chown YOUR_USER:YOUR_GROUP /mnt/wasabi-logs/
rclone mount wasabi:/YOUR_LOGGING_BUCKET/ /mnt/wasabi-logs/

  17. Perform some test uploads, downloads, and deletes on your test bucket (not the logging bucket).  After a short period of time (approximately 30 minutes or so), a log file should be generated in your logging bucket.

  18. Log in to your Linux server with another SSH session and issue the following command. You should see a bucket log listed.

    ls -la /mnt/wasabi-logs/

  19. Go back to your original SSH session and issue a “Ctrl+C” command to stop Rclone.

  20. Create an “rclone.service” file in /etc/systemd/system with the following contents.  You can use sudo vi /etc/systemd/system/rclone.service to create the file, or use whatever your preferred Linux text editor is (for example, vi, vim, nano). Replace YOUR_USER and YOUR_GROUP with your Linux user and group and YOUR_LOGGING_BUCKET with the name of your logging bucket.

    [Unit]
                Description=Startup script for Rclone to mount Wasabi logs bucket as /mnt/wasabi-logs
                After=network-online.target
                Wants=network-online.target

                [Service]
                ExecStart=/usr/bin/rclone mount wasabi:/YOUR_LOGGING_BUCKET/ /mnt/wasabi-logs/
                ExecStop=/bin/fusermount -u /mnt/wasabi-logs
                Restart=always
                RestartSec=10
                User=YOUR_USER
                Group=YOUR_GROUP
                Type=simple

                [Install]
                WantedBy=multi-user.target

  21. Issue the following commands to run Rclone as a service that persists across reboots.

    sudo systemctl daemon-reload
sudo systemctl enable rclone.service
sudo systemctl start rclone.service

  22. Test to make sure Rclone is running by issuing the following command. You should see your bucket log file(s).

    ls -la /mnt/wasabi-logs/

Installing and Configuring Logstash

As of the writing of this document, the latest supported version of Logstash with the microsoft-sentinel-logstash-output-plugin is 8.15.  We ran Logstash version 8.19.10 in our tests and did not encounter any issues.

  1. Log in to your Linux server via SSH.

  2. Issue the following commands to install Logstash. To install the version used during our testing, issue the following command in place of the last one:  sudo apt install logstash=1:8.19.10-1

    wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elastic-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/elastic-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt update
sudo apt install logstash

  3. If you do not want to not update Logstash automatically going forward, issue the following command:
    sudo apt-mark hold logstash

  4. Issue the following command to install the Microsoft Sentinel Logstash Output plugin:

    sudo /usr/share/logstash/bin/logstash-plugin install microsoft-sentinel-logstash-output-plugin

  5. In /etc/logstash/logstash.yml uncomment (remove the preceding # mark from the line) and set the following.  This affects all pipelines, but it may instead be set for individual pipelines if desired. Use the command sudo vi /etc/logstash/logstash.yml to edit the file, or use your favorite text editor. 

    pipeline.ecs_compatibility: disabled

  6. Create a sample config file for testing purposes using your favorite Linux text editor.  For example:  
    sudo vi /etc/logstash/conf.d/wasabi-to-sentinel-sample.conf
    Insert the following text into the file and save it.

    input {
                file {
                path => "/mnt/wasabi-logs/*"
                }
                }

                output {
                microsoft-sentinel-logstash-output-plugin {
                create_sample_file => true
                sample_file_path => "/tmp/logstash/"
                }
                }

  7. Issue the following command to create the temporary directory for testing:

    mkdir /tmp/logstash

  8. To test with a log file from your bucket, execute the following command. 

    /usr/share/logstash/bin/logstash -f /etc/logstash/conf.d/wasabi-to-sentinel-sample.conf

  9. Upload, download, and delete files from your test bucket several times and then wait for a log file to appear in your logging bucket and in /mnt/wasabi-logs/.  It can take approximately 30 minutes or so for a log file to show up.

  10. Save the .json file in /tmp/logstash/ to your computer for use later.

- If you see a log file appear in your /mnt/wasabi-logs/directory but do not see any output file in /tmp/logstash, modify the ExecStart line in /etc/systemd/system/rclone.service to be the following, replacing YOUR_LOGGING_BUCKET with the name of your logging bucket:

ExecStart=/usr/bin/rclone mount wasabi:/YOUR_LOGGING_BUCKET/ /mnt/wasabi-logs/ --dir-cache-time 10s --poll-interval 10s --allow-other
- Uncomment (remove the preceding # character from the line) the following line in /etc/fuse.conf:

user_allow_other

- Reboot your Linux server for all changes to take effect, then repeat steps 9-10.

Creating a Data Collection Endpoint in Azure

  1. Log in to the Azure Portal.  

  2. Go to the Azure Monitor.

  3. Under Settings on the left hand side, click Data Collection Endpoints.

  4. Click Create.

  5. Give the endpoint a name of “Logstash-Wasabi”, select your subscription and resource group, along with the appropriate region. Click Review + Create.

  6. Click Create.

  7. Click the name of your Data Collection Endpoint, Logstash-Wasabi.

  8. Copy the Logs Ingestion URL and save it to a file on your computer.

Creating a Data Collection Rule (DCR) Based Table in Azure Log Analytics

  1. Go to your Log Analytics workspace and under Settings click Tables. Click Create.

  2. Click New custom log (Direct Ingest).

  3. Give the table a name of “Logstash_Wasabi”, select Basic as the table plan, and click Create a new data collection rule.

  4. Select the appropriate Subscription and Resource group. Give the rule a name of “Logstash_Wasabi_DCR”.  Click Done.

  5. Select the previously created DCR from the drop-down menu along with the previously created “Logstash-Wasabi” Data Collection Endpoint. Click Next.

  6. Under Schema and transformation click Browse for files.

  7. Upload the sample .json file previously saved from /tmp/logstash on your Linux server.  

  8. Click Transformation editor.

  9. Download and open the attached “Log-Analytics-Transformation.txt” file and copy and paste the contents into the textbox.  

    Log-Analytics-Transformation
    1.16 KB

  10. Click Run.

  11. You will see the contents of your sample .json file from your Linux server in the output. Click Apply.

  12. Click Next.

  13. Click Create.

Registering Application and Creating Secret

  1. Go to your Azure Directory Overview page and click Add registration application.

  2. Give the application a name of “Logstash_Wasabi”. Select the radio button next to Accounts in this organizational directory only. Click Register.

  3. Copy the application (client) ID and save it to your computer for use later. Click Add a certificate or secret.

  4. Click + New client secret.

  5. Give a description of “Logstash_Wasabi” and select the appropriate expiration value for your organization (we selected the recommended value of 180 days in our testing). This will need to be changed periodically so as not to have an interruption in Wasabi log delivery to Sentinel. Click Add.

  6. Copy the Secret Value and save it to a secure location. Note the expiration date.

  7. Under Microsoft Azure Monitor, search for “data collection rules”.  Click Data collection rules.

  8. Click Logstash_Wasabi_DCR.

  9. Click JSON View.

  10. Copy the “immutableId” value and save it to your computer.

  11. Scroll down and copy the “streams” value under “dataFlows”. In our testing it is “Custom-Logstash_Wasabi_CL”.

Giving Application Permissions

  1. Under your Logstash_Wasabi Data Collection Rule, click Access control (IAM). Click Add then click Add role assignment.

  2. Search for “monitoring metrics publisher”. Select Monitoring Metrics Publisher and click Next.

  3. Click + Select members.

  4. Search for “Logstash” and select the “Logstash_Wasabi” application.  Click Select.

  5. Click Review + assign.

  6. Click Review + assign again on the next screen.

Creating New Logstash Configuration File

  1. Remove the previously created temporary Logstash configuration file:
    sudo rm /etc/logstash/conf.d/wasabi-to-sentinel-sample.conf

  2. Create a new /etc/logstash/conf.d/wasabi-logs-to-sentinel.conf file by issuing the following command, or by using your favorite text editor.  sudo vi /etc/logstash/conf.d/wasabi-logs-to-sentinel.conf

  3. Insert the following text into the file, replacing all the values in CAPS with your own values. For your tenant_id, search for “tenant properties” in your Azure portal and copy the Tenant ID.

    input {
                file {
                path => "/mnt/wasabi-logs/*" # Use absolute paths; wildcards are supported
                }
                }

                output {
                microsoft-sentinel-logstash-output-plugin {
                client_app_Id => "YOUR_CLIENT_APP_ID"
                client_app_secret => "YOUR_CLIENT_APP_SECRET"
                tenant_id => "YOUR_AZURE_TENANT_ID"
                data_collection_endpoint => "YOUR_DATA_COLLECTION_ENDPOINT_URL"
                dcr_immutable_id => "YOUR_DCR_IMMUTABLE_ID"
                dcr_stream_name => "YOUR_DCR_STREAM_NAME"
                }
                }


    Below is an example file.

    input {
                file {
                path => "/mnt/wasabi-logs/*" # Use absolute paths; wildcards are supported
                }
                }

                output {
                microsoft-sentinel-logstash-output-plugin {
                client_app_Id => "ffaada90-****************************"
                client_app_secret => "tjG8Q~***********************************"
                tenant_id => "aa9d7384-****************************"
                data_collection_endpoint => "https://logstash-wasabi-ufnq.eastus-1.ingest.monitor.azure.com"
                dcr_immutable_id => "dcr-d034fa6b4***********************"
                dcr_stream_name => "Custom-Logstash_Wasabi_CL"
                }
                }

  4. Start Logstash as a service and make it persist across reboots by issuing the following commands. Logstash will automatically use the new configuration file.  The status command will show if the service is running.

    sudo systemctl start logstash
                sudo systemctl enable logstash
                sudo systemctl status logstash

Generating New Bucket Logs and Observing in Azure Log Analytics and/or Sentinel

  1. Generate new bucket logs by performing test uploads, downloads, and deletes in your test bucket.  It may take 30 minutes or so for logs to show up in your logging bucket and Azure.

  2. Observe the new log files in Azure Log Analytics and/or Sentinel by going to your Log Analytics workspace, clicking on Logs, and running a query.  Here is an example screenshot of logs in Azure Log Analytics.

    If you see log files in /mnt/wasabi-logs/ on your Linux server but do not see them in Azure Log Analytics or Sentinel, see the note in step 10 of the Installing and Configuring Logstash section above.

Configuring Other Buckets to Log to Your Logging Bucket

  1. Repeat steps 2-5 of the Creating Wasabi Test Bucket section on your other existing buckets to log to your logging bucket.  

  2. Observe new bucket log entries as they appear in Log Analytics and/or Sentinel.

Updating Azure Secret Periodically

Your Azure secret used by Logstash will need to be updated periodically (i.e. every 180 days or whatever value was configured earlier).    

  1. Log in to the Microsoft Entra Admin Center.

  2. Click App registrations and click the Logstash_Wasabi name.

  3. Click the link under Client credentials.

  4. Click + New client secret.

  5. Give the secret a name, an expiry time, and click Add.

  6. Copy the secret Value and save it in a safe location.

  7. Log in to your Linux server running Logstash.

  8. Edit the /etc/logstash/conf.d/wasabi-logs-to-sentinel.conf file using your favorite text editor, such as:
    sudo vi /etc/logstash/conf.d/wasabi-logs-to-sentinel.conf

  9. Change the client_app_secret value to be the new secret value and save the file.

  10. Restart Logstash.

    sudo systemctl restart logstash

  11. Verify you are seeing new logs in Azure Log Analytics and/or Sentinel. It may take 30 minutes or so for new logs to be available after any S3 action is performed on the bucket (object is uploaded, downloaded, deleted, and so on).  

  12. Delete the old secret in the Microsoft Entra Admin Center.

Appendix A - Example Bucket Log

Below is an example bucket log as it appears in a logging bucket before it is modified by Logstash and Azure Log Analytics.  

Record format: [BucketOwner Bucket Time RemoteIP Requester RequestId Operation Key Request-URI HttpStatus ErrorCode BytesSent ObjectSize TotalTime Turn-AroundTime Referrer User-Agent VersionId]
        =========================================================================================================================================================
        49147859625EDC969DDAB60F1069DFA737576CF81F72FD97CCCDA1F9F8867C7E mt-test-bucket [20/Jan/2026:01:36:59 +0000] 121.200.4.63 49147859625EDC969DDAB60F1069DFA737576CF81F72FD97CCCDA1F9F8867C7E CF7DB7BEDE0BBA67:A REST.HEAD.OBJECT test.txt "HEAD /test.txt" 404 NoSuchKey - 0 4 0 "" "rclone/v1.72.0" -