[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-03 (世界標準時間)。"],[],[],null,["# Troubleshoot file system transfers\n\nThis document describes how to troubleshoot and resolve transfer and agent\nissues, and where to find agent logs to help you troubleshoot issues.\n\nErrors\n------\n\nThe following table describes transfer error messages, and how to resolve\nthem:\n\nViewing agent logs\n------------------\n\nAgent logs contain information relevant to agent processes, and can help you\ntroubleshoot agent connection problems. If your agents are listed as connected\nin Google Cloud console and you are experiencing transfer failures, see\n[Viewing errors](/storage-transfer/docs/managing-on-prem-jobs#view-errors) to view a sample of transfer\nerrors. To view logs that contain a record of every file Storage Transfer Service\nconsidered during a transfer, see\n[Viewing transfer logs](/storage-transfer/docs/managing-on-prem-jobs#viewing-logs).\n\nBy default, agent logs are stored in `/tmp`. You can change the location with\nthe `--log-dir=`\u003cvar translate=\"no\"\u003elogs-directory\u003c/var\u003e\n[command-line option](/storage-transfer/docs/on-prem-agent-command-options).\n\nThe logs are named:\n\n`agent.`\u003cvar translate=\"no\"\u003ehostname\u003c/var\u003e`.`\u003cvar translate=\"no\"\u003eusername\u003c/var\u003e`.log.`\u003cvar translate=\"no\"\u003elog-level\u003c/var\u003e`.`\u003cvar translate=\"no\"\u003etimestamp\u003c/var\u003e\n\nWhere:\n\n- \u003cvar translate=\"no\"\u003ehostname\u003c/var\u003e - hostname the agent is running on.\n- \u003cvar translate=\"no\"\u003eusername\u003c/var\u003e - username running the agent.\n- \u003cvar translate=\"no\"\u003elog-level\u003c/var\u003e is one of:\n - **`INFO`** - informational messages\n - **`ERROR`** - errors encountered during transfer, but that don't prevent the transfer job from continuing.\n - **`FATAL`** - errors encountered that prevent the transfer job from continuing.\n- \u003cvar translate=\"no\"\u003etimestamp\u003c/var\u003e - timestamp in `YYYYMMDD-hhmmss.thread-id` format.\n\nThe logs directory contains symlinks to the most recent logs for each of the\npriority levels:\n\n- `agent.ERROR`\n- `agent.FATAL`\n- `agent.INFO`\n\nSlow transfer speed\n-------------------\n\nIf your data is taking a long time to transfer, check the following:\n\n1. The read throughput of your file system should be approximately 1.5\n times your desired upload speed. You can use [FIO](https://fio.readthedocs.io/en/latest/fio_doc.html)\n to test the read throughput of your file system.\n\n \u003cbr /\u003e\n\n Install fio: \n\n sudo apt install -y fio\n \n Create a new directory `fiotest`: \n\n TEST_DIR=/mnt/mnt_dir/fiotest\n sudo mkdir -p $TEST_DIR\n \n Test read throughput: \n\n sudo fio --directory=$TEST_DIR --direct=1\n --rw=randread --randrepeat=0 --ioengine=libaio --bs=1M --iodepth=8\n --time_based=1 --runtime=180 --name=read_test --size=1G\n \n \u003cbr /\u003e\n\n After you run the commands above, Fio generates a report. The line labeled\n \"bw\" represents the total aggregate bandwidth of all threads, and it can be\n used as a proxy for read throughput.\n2. Use [iPerf3](https://iperf.fr/iperf-download.php) to check your\n available internet bandwidth to Storage Transfer Service.\n\n3. Make sure each of your transfer agents have at least 4 vCPU and 8GB of RAM.\n\nIf you've checked the conditions above and are still experiencing long transfer\ntimes, you can add additional agents to increase the number of concurrent\nconnections to your data's file system.\n\nFor more information on how to maximize the performance of your transfer agents,\nsee [Agent best practices](/storage-transfer/docs/on-prem-agent-best-practices).\n\nTroubleshooting agent errors\n----------------------------\n\nThe following sections describe how to troubleshoot and resolve transfer\nagent errors:\n\n### Agents are not connected\n\nIf transfer agents are not displayed as connected within Google Cloud console:\n\n1. Verify that agents can connect to Cloud Storage APIs:\n\n 1. Run the following command from the same machine as the transfer agent to\n test the agent's connection to Cloud Storage APIs:\n\n `gcloud storage cp test.txt gs://`\u003cvar translate=\"no\"\u003emy-bucket\u003c/var\u003e\n\n Replace:\n\n \u003cvar translate=\"no\"\u003emy-bucket\u003c/var\u003e with the name of your Cloud Storage\n bucket.\n2. If your project uses VPC Service Controls,\n [view the agent logs](#agent-logs) for errors. If\n VPC Service Controls is misconfigured, the `INFO` agent logs will contain\n the following error:\n\n `Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: `\u003cvar translate=\"no\"\u003eid\u003c/var\u003e\n\n In this output:\n - \u003cvar translate=\"no\"\u003eid\u003c/var\u003e is the [VPC Service Controls error's unique id](/vpc-service-controls/docs/troubleshooting#using_the_errors_unique_id)\n\n### Agents are connected but jobs fail\n\nIf agents are displayed as connected but transfer jobs fail, check the\n[error details of the failed jobs](/storage-transfer/docs/managing-on-prem-jobs#view-errors).\n\n### Proxy rejects IP addresses\n\nIf you run behind a proxy like [Squid](https://www.squid-cache.org/)\nand you use an allowlist, you may see requests being denied because of\nIP addresses being used instead of hostnames.\n\nTo resolve this issue, use the\n[docker run command to run the agents](/storage-transfer/docs/managing-on-prem-agents#docker-run)\nand add the following flag: \n\n --transfer-service-endpoint=storagetransfer.googleapis.com:443\n\nIf you use an alternative endpoint to reach `googleapis.com` (e.g. for\nPrivate Service Connect), replace `googleapis.com` with the\nalternative endpoint.\n\n### Agent is unable to connect to an HTTPS endpoint using a self-signed certificate\n\nIf your agent is unable to connect to an HTTPS endpoint using a self-signed\ncertificate, use an extra `-v` option to mount your custom certificate\nbundle into the container's default location (`/etc/ssl/certs`).\n\nTo do this, modify the\n[`docker run` command](/storage-transfer/docs/managing-on-prem-agents#docker-run)\nby adding the following flag: \n\n -v \u003cvar translate=\"no\"\u003ePATH_TO_LOCAL_CERT\u003c/var\u003e:/etc/ssl/certs/ca-certificates.crt\n\nReplace:\n\n- \u003cvar translate=\"no\"\u003ePATH_TO_LOCAL_CERT\u003c/var\u003e with the path to your custom certificate file."]]