hashtopolis
[BUG]: "This file is not used for the specified task"
Version Information
0.14.3
Hashcat
No response
Description
Client spams
Got task with id: 1 Getting of file failed: {'action': 'getFile', 'response': 'ERROR', 'message': 'This file is not used for the specified task!'}
and server spams
[Sat Feb 15 06:26:04.871186 2025] [php:warn] [pid 29:tid 29] [client 192.168.1.177:53949] PHP Warning: Trying to access array offset on null in /var/www/html/src/inc/CSRF.class.php on line 14 192.168.1.177 - - [15/Feb/2025:06:26:04 +0000] "POST /api/server.php HTTP/1.1" 200 429 "-" "s3-python-0.7.2.4"
Client downloads one of two assigned dictionary files (the larger 4.5GB one) but seems stuck on the smaller (~200mb) one.
It seems to be something it doesn't like with the file, but it's odd that somehow it thinks the file is not assigned.
Hi thanks for your bug report. This error should only happen when the task does not have this file assigned. Can you send more details to reproduce this bug? For example the attack command you are trying
Hi, I ran into this issue as well. I created a supertask and assigned a number of nodes to it. Everything seemed to be processing fine, but then one of the nodes started throwing this error and would not proceed.
[2025-09-23 16:49:03 UTC +0000][WARN ]: Agent requested file not used in the task! ### {"agentId":25,"agentName":"xxxx","uid":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","os":0,"devices":"Intel(R) Xeon(R) Platinum 8468\nIntel(R) Xeon(R) Platinum 8468\nMatrox Electronics Systems Ltd. Integrated Matrox G200eW3 Graphics Controller (rev 04)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)\nNVIDIA Corporation GH100 [H100 SXM5 80GB] (rev a1)","cmdPars":"","ignoreErrors":0,"isActive":1,"isTrusted":1,"token":"xxxx","lastAct":"getFile","lastTime":1758646143,"lastIp":"x.x.x.x","userId":null,"cpuOnly":0,"clientSignature":"s3-python-0.7.4"}EOD {"fileId":2,"filename":"rockyou2021-extended_a.txt","size":3830768828,"isSecret":0,"fileType":0,"accessGroupId":1,"lineCount":321006999}EOD {"taskId":144,"taskName":"Crack rockyou2021-extended + rockyou2021-extended_A.txt","attackCmd":"#HL# rockyou2021-extended_A.txt -r OneRuleToRuleThemAll.rule","chunkTime":600,"statusTimer":5,"keyspace":0,"keyspaceProgress":0,"priority":54,"maxAgents":0,"color":"","isSmall":0,"isCpuTask":0,"useNewBench":1,"skipKeyspace":0,"crackerBinaryId":1,"crackerBinaryTypeId":1,"taskWrapperId":11,"isArchived":0,"notes":"","staticChunks":0,"chunkSize":0,"forcePipe":0,"usePreprocessor":0,"preprocessorCommand":""}EOD
Later another node started having the same issue
[2025-09-23 19:14:48 UTC +0000][WARN ]: Agent requested file not used in the task! ### {"agentId":19,"agentName":"xxxx","uid":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","os":0,"devices":"Intel(R) Xeon(R) Gold 5420+\nIntel(R) Xeon(R) Gold 5420+\nMatrox Electronics Systems Ltd. Integrated Matrox G200eW3 Graphics Controller (rev 04)\nNVIDIA Corporation GH100 [H100L 94GB] (rev a1)\nNVIDIA Corporation GH100 [H100L 94GB] (rev a1)\nNVIDIA Corporation GH100 [H100L 94GB] (rev a1)\nNVIDIA Corporation GH100 [H100L 94GB] (rev a1)","cmdPars":"","ignoreErrors":0,"isActive":1,"isTrusted":1,"token":"xxxx","lastAct":"getFile","lastTime":1758654888,"lastIp":"x.x.x.x","userId":null,"cpuOnly":0,"clientSignature":"s3-python-0.7.4"}EOD {"fileId":2,"filename":"rockyou2021-extended_a.txt","size":3830768828,"isSecret":0,"fileType":0,"accessGroupId":1,"lineCount":321006999}EOD {"taskId":144,"taskName":"Crack rockyou2021-extended + rockyou2021-extended_A.txt","attackCmd":"#HL# rockyou2021-extended_A.txt -r OneRuleToRuleThemAll.rule","chunkTime":600,"statusTimer":5,"keyspace":0,"keyspaceProgress":0,"priority":54,"maxAgents":0,"color":"","isSmall":0,"isCpuTask":0,"useNewBench":1,"skipKeyspace":0,"crackerBinaryId":1,"crackerBinaryTypeId":1,"taskWrapperId":11,"isArchived":0,"notes":"","staticChunks":0,"chunkSize":0,"forcePipe":0,"usePreprocessor":0,"preprocessorCommand":""}EOD
Looks like something in the chain is not cases sensitive and is changing "A" to "a" in the request, but then hashtopolis is (rightly) case sensitive and returning the list ending in "a" which is incorrect for the assigned task. I am running hashtopolis behind Caddy, but I believe that doesn't change case on any incoming requests. After renaming the wordlist files so they are all lowercase I did not have this issues.
Seems like you choose the wrong file name (Did you maybe write something manually into the attack line) ? We dont see a bug here. Please choose either the correct file name or click the file on the right pop-up.
I was able to recreate this at a smaller scale. I created two new dictionary files test.txt and TEST.txt each with just 1 word (test and TEST).
I then imported a supertask under the "Wordlist/Bulk Rule" section selecting an existing rule as the base, and the two word lists to iterate over with #HL# FILE -r OneRuleToRuleThemAll.rule in the base command field. This resulted in the supertask below:
I applied the supertask to a hashlist and it generated tasks. The tasks were assigned to an agent.
The task with lowercase "test.txt" completed, then the task with uppercase "TEST.txt" failed returning "[2025-10-22 09:58:46,734] [ERROR] Getting of file failed: {'action': 'getFile', 'response': 'ERROR', 'message': 'This file is not used for the specified task!'}"
I removed those tasks and created a new supertask with just TEST.txt. It returned the same error. I then deleted the test.txt wordlist and with no other changes the task for TEST.txt completed. Here is the output on the agent:
Getting of file failed: {'action': 'getFile', 'response': 'ERROR', 'message': 'This file is not used for the specified task!'}
Got task with id: 264
Getting of file failed: {'action': 'getFile', 'response': 'ERROR', 'message': 'This file is not used for the specified task!'}
Got task with id: 264
Getting of file failed: {'action': 'getFile', 'response': 'ERROR', 'message': 'This file is not used for the specified task!'}
Got task with id: 264
Downloading: [==================================================]
Client is up-to-date!
Got cracker binary type hashcat
Keyspace got accepted!
Benchmark task...
Server accepted benchmark!
Start chunk...
HC error: /sys/bus/pci/devices/0000:c2:00.0/hwmon/hwmon8/pwm1: No such file or directory
Progress:100.00% Speed: 225.66kH/s Cracks: 0 Accepted: 0 Skips: 0 Zaps: 0
finished chunk
Client is up-to-date!
No task available!
No task available!
I noticed in further testing after re-uploading test.txt that supertasks would complete TEST.txt and fail on test.txt. It seems that when there are two word lists that differ only in case, the lower ID wordlist is what is selected for the agent regardless of if it the correct file, and if it is not the correct file, the server correctly denies access.
Some more info about my environment: The agent in this test case was running in a distrobox container on my desktop with Fedora 42. The agents for the previous tests were running on bare metal running Rocky 8.9 and started with Slurm.
Hashtopolis is running under docker with the docker-compose.yml from this repo modified to map persistent storage to the local system, and to put everything behind caddy. Here is a diff of the docker-compose.yml I am using vs the one in the repo
[root@host hashtopolis]# diff docker-compose.yml <(curl https://raw.githubusercontent.com/hashtopolis/server/master/docker-compose.yml)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1219 100 1219 0 0 53000 0 --:--:-- --:--:-- --:--:-- 53000
8c8
< - /docker/data/hashtopolis/backend:/usr/local/share/hashtopolis:Z
---
> - hashtopolis:/usr/local/share/hashtopolis:Z
19,20c19,20
< # ports:
< # - 8080:80
---
> ports:
> - 8080:80
26c26
< - /docker/data/hashtopolis/db:/var/lib/mysql
---
> - db:/var/lib/mysql
40,51d39
< # ports:
< # - 4200:80
< caddy:
< image: caddy
< restart: always
< container_name: hashtopolis-caddy
< depends_on:
< - hashtopolis-frontend
< volumes:
< - /docker/data/hashtopolis/Caddyfile:/etc/caddy/Caddyfile:ro
< - /docker/data/hashtopolis/domain.chained.crt:/etc/cert.crt:ro
< - /docker/data/hashtopolis/domain.key:/etc/key.key:ro
53c41,44
< - 8443:443
---
> - 4200:80
> volumes:
> db:
> hashtopolis:
Here is the contents of my Cadyfile:
https://host.domain {
tls /etc/cert.crt /etc/key.key
reverse_proxy hashtopolis-backend:80
}
Let me know if there is anything else I can provide that may help track this down. Thanks!