Confusing behavior when using --ah-cli to generate hashes for another environment

[chinponya]

A lot of people seem to trip over the fact that in docker or systemd environments, the naive use of --ah-cli will produce incorrect hashes, due to the expectation that it will have access to the same generated ah-salt.

This can be solved by improving the documentation, but I am not certain what's the best solution here. So far I've been suggesting the following process:

1. add show-ah-salt to [global] section in the config
2. restart copyparty
3. check the log for a line that looks like effective ah_salt is O4nO7p1ACFnuFk/EpcDdDM7H
4. use the cli again to generate a password hash, using the same salt: copyparty-sfx.py --ah-cli --ah-alg argon2 --ah-salt [ah_salt_you_saw_in_the_log]

The alternative way could be to suggest setting $XDG_CONFIG_HOME in the call to --ah-cli, but the actual location seems to vary a lot depending on which systemd service implementation or docker is used. The file might also not be readable by the current user, making it not so straightforward.

[9001]

I think the most general solution might be to suggest setting a salt manually; that way you avoid all the uncertainties. I suppose that might be slightly less secure in certain environments, but off the bat I'm struggling to think of good examples... Maybe just suggest that in the readme in general?

[Bozhidar-A]

This goes deeper? I am currently trying to set this up in an a docker environment. Even after copying the salt and using the generate command it still fails? I have sanity checked by running installed with uv, raw file with python: same hash, same result, naw dude. Even 123 doesn't work? If they are not hashed all is good.

[chinponya]

@Bozhidar-A Some ideas:

• ensure that the salt displayed by show-ah-salt is the same across docker restarts - there's a possibility that the generated salt isn't persisted (by default it will dump it to /cfg)
• if that fails, you can generate the ah-salt yourself and add it to the config file