i assume this does not work if using docker?
It does, but it’s a bad idea on a production node 
My nodes, my rules. 
Also we were told not to run hardware dedicated to storj… So what is a production node?
Of course you’re allowed to do what you want, but it does not seem like OP is completely in tune with why nodes update the way they do, and when. That’s fine, but if you don’t know what you’re doing, perhaps you should not be running quality assurance nodes. They will inevitably be in a state where the quality is not assured
Regarding a production node … it’s a node that’s not used for testing. Is that unclear, or are you just trying to poke holes in my ever so hardened defence of the StorJ mentality? 
The latter of course. I forgot the 
.
After update, i got this error on 2 nodes on different server on windows
2025-11-11T19:50:27+02:00 ERROR failure during run {“error”: “Failed to create storage node peer: hashstore: read D:\hashstore\12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S\s1\meta\hashtbl-000000000000000e: Data error (cyclic redundancy check).\n\tstorj.io/storj/storagenode/hashstore.(*roBigPageCache).ReadRecord:622\n\tstorj.io/storj/storagenode/hashstore.(*HashTbl).Range:293\n\tstorj.io/storj/storagenode/hashstore.OpenHashTbl:175\n\tstorj.io/storj/storagenode/hashstore.OpenTable:117\n\tstorj.io/storj/storagenode/hashstore.NewStore:276\n\tstorj.io/storj/storagenode/hashstore.New:100\n\tstorj.io/storj/storagenode/piecestore.(*HashStoreBackend).getDB:252\n\tstorj.io/storj/storagenode/piecestore.NewHashStoreBackend:117\n\tstorj.io/storj/storagenode.New:604\n\tmain.cmdRun:84\n\tmain.newRunCmd.func1:33\n\tstorj.io/common/process.InitBeforeExecute.func1.2:389\n\tstorj.io/common/process.InitBeforeExecute.func1:407\n\tgithub.com/spf13/cobra.(*Command).execute:985\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:1117\n\tgithub.com/spf13/cobra.(*Command).Execute:1041\n\tstorj.io/common/process.ExecWithCustomOptions:115\n\tstorj.io/common/process.ExecWithCustomConfigAndLogger:80\n\tstorj.io/common/process.ExecWithCustomConfig:75\n\tstorj.io/common/process.Exec:65\n\tmain.(*service).Execute.func1:107\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:93”, “errorVerbose”: “Failed to create storage node peer: hashstore: read D:\hashstore\12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S\s1\meta\hashtbl-000000000000000e: Data error (cyclic redundancy check).\n\tstorj.io/storj/storagenode/hashstore.(*roBigPageCache).ReadRecord:622\n\tstorj.io/storj/storagenode/hashstore.(*HashTbl).Range:293\n\tstorj.io/storj/storagenode/hashstore.OpenHashTbl:175\n\tstorj.io/storj/storagenode/hashstore.OpenTable:117\n\tstorj.io/storj/storagenode/hashstore.NewStore:276\n\tstorj.io/storj/storagenode/hashstore.New:100\n\tstorj.io/storj/storagenode/piecestore.(*HashStoreBackend).getDB:252\n\tstorj.io/storj/storagenode/piecestore.NewHashStoreBackend:117\n\tstorj.io/storj/storagenode.New:604\n\tmain.cmdRun:84\n\tmain.newRunCmd.func1:33\n\tstorj.io/common/process.InitBeforeExecute.func1.2:389\n\tstorj.io/common/process.InitBeforeExecute.func1:407\n\tgithub.com/spf13/cobra.(*Command).execute:985\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:1117\n\tgithub.com/spf13/cobra.(*Command).Execute:1041\n\tstorj.io/common/process.ExecWithCustomOptions:115\n\tstorj.io/common/process.ExecWithCustomConfigAndLogger:80\n\tstorj.io/common/process.ExecWithCustomConfig:75\n\tstorj.io/common/process.Exec:65\n\tmain.(*service).Execute.func1:107\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:93\n\tmain.cmdRun:86\n\tmain.newRunCmd.func1:33\n\tstorj.io/common/process.InitBeforeExecute.func1.2:389\n\tstorj.io/common/process.InitBeforeExecute.func1:407\n\tgithub.com/spf13/cobra.(*Command).execute:985\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:1117\n\tgithub.com/spf13/cobra.(*Command).Execute:1041\n\tstorj.io/common/process.ExecWithCustomOptions:115\n\tstorj.io/common/process.ExecWithCustomConfigAndLogger:80\n\tstorj.io/common/process.ExecWithCustomConfig:75\n\tstorj.io/common/process.Exec:65\n\tmain.(*service).Execute.func1:107\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:93”}
But 1.139.6 works OK there, so i downdraded it for now
I sugest you uncheck that box in drive properties about indexing.
You don’t need indexing of storagenode’s pieces. It takes up space and resourses. One of the first things I do with a new drive or new Win install is to disable that indexing.
Uncheck that box and click OK, not Apply, just to autoclose the Properties tab when finishes.
If it gives you an error, just click Ignore all.
This seems to be an error message from Windows, complaining about data corruption issues / CRC error.
Might be a disk failure.
Try to copy the file hashtbl-000000000000000e and see if windows can read it. Also: check the disk health (chkdsk?).
checkdisk was first thing to check, All show OK.
I downgraded to 1.139 and not see this error any more.
Does 1.139 not cheking metadata file integrity?
Is it possible to rebuild metadata file?
I rebuild hashtbl couple a days ago
looks like it is for linux, on windows it will not work like this
I think that go-written application would be works for windows too
Just install go for windows and then do:
go install storj.io/storj/cmd/write-hashtbl@latest
This will create the executable.
Thank you this helped a lot, now i have Exe, will try to use it
how long it will rebuild it?
The rebuild is very slow, get a 
and wait.
S1 map contains 719GB of data, looks like i need very big drink.
I hope this will help, then I will be able to update node.
The write-hashtbl command is iterating all logfiles twice (byte by byte). The first iteration is only to count records. You can avoid this step by using the -s parameter.