the bad mount errors appeared earlier because of restarting the pc - it is the problem that cures by Alexey method:
this time that won’t go and I’ve made the disk install of Windows (this not helped), then clean install of Windows with full format of Win directory (this let me go further but one node works ONLINE and UPTIME, the 2nd with OFFLINE and UPTIME).
You should remove the OWNER-CREATOR group from the folder with data (or from the whole disk), add user SYSTEM and change owner recursively to the SYSTEM, then add full rights to it recursively.
Then restart (or re-create) the storagenode.
The offline is more like related to the network problems.
It shares drives automatically on wsl2’s level. All your drives will be automatically mounted into /mnt folder inside the wsl2 distro, i.e. the N: disk will appear as /mnt/n
If you want to. It’s useful if you use more than a one distro. Just make sure that your default distro is v2:
2021-01-03T04:52:40.391Z ERROR servers unexpected shutdown of a runner {"name": "debug", "error": "debug: http: Server closed", "errorVerbose": "debug: http: Server closed\n\tstorj.io/private/debug.(*Server).Run.func2:108\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}
This is mean, that your network doesn’t allow to contact the satellite - something blocking the traffic. One of the reasons - your port is closed and your node can’t receive a response.
Please, check that node with this checklist:
This suggest that docker do not have an access to the storage, please, fix the permissions issue by removing OWNER-CREATOR recursively from the storage and adding a user SYSTEM, make it owner recursively and add with full rights permissions recursively. Then stop and remove the container and run it back.
Made an SYSTEM;
Removed an OWNER-CREATOR;
Owner: Administrators (with mark of subcontainers);
the situation have not changed.
Maybe need to erase all the users from permissions and get them back?
After run back a container I get the next message:
You should make SYSTEM as owner recursively too, not Administrators. And SYSTEM must have write, read, delete, etc. or Full access to all files in the storage folder.
Yes, this is expected and “normal” for the wsl2. I have tested, it’s much faster than SMB used in Docker desktop with Hyper-V engine though.
not needed, only change the owner to the SYSTEM and give it full rights should be enough.
Please, show access rights for the
I think you can remove them.
I need to see an access rights of that file, not its content.
Please, show result of the command (PowerShell), replace D:\trust-cache.json to your path for trust-cache.json file:
This suggest that your external address is wrong and satellite cannot answer to ping request to your node.
You should check your port forwarding rule, firewall for the forwarded port and your identity.
Is your storage configured for the first node exactly like this one?
Because right now we have a permissions issue. This often happens with Windows when you do something manually with data folders - copy it from somewhere and such.
Sometimes Windows is very weird with default settings: you have CREATOR-OWNER by default, this is mean, that when you start any service and it creates files, the owner of these files would be a SYSTEM. However, if you modify or create a folder - your user will be an owner of that folder. During inheritance it’s propagated to all subfolders and files inside the parent folder.
Since you used a whole disk, not the folder, the permissions is propagated from disk’s permissions configuration.
With default Windows configuration for the disk and if you didn’t change anything on the disk, the setup will create all needed folders structure and owner will be correct.
But if you created folders manually - the owner will be your user (or Administrators in your case, because you seems is logged in as an Administrator) and now the SYSTEM user cannot access data because of different owner.
By the way, did you setup a node? Storage Node - Storj Docs
Such a configuration often have permissions issue, especially if you re-installed Windows and GUIDs for accounts have changed. You will have wrong permissions on the disk. The today’s Windows updated itself to the next release via automated re-install. So, it could have this problem after update to the next version. But you would notice it only after restart (postponed installation have applied when you rebooted).