Docker – Service Not Starting on New WSL2

You should use the User= directive in your systemd service.

User=, Group=

Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is "root", but User= may be used to specify a different user. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the user's service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with "+".

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#User=

I would also recommend moving your script from a home directory to a standard path, like /usr/local/bin or something of the like.

You should also ensure the ordering of your connectdocker.service by giving it the After=docker.service and Requires=docker.service. As it is written the connectdocker.service is probably trying to start around the same time as the docker.service, and you'd need to wait for docker.service to be up before you can connect to it.

Requires=

Configures requirement dependencies on other units. If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated. This option may be specified more than once or multiple space-separated units may be specified in one option in which case requirement dependencies for all listed names will be created. Note that requirement dependencies do not influence the order in which services are started or stopped. This has to be configured independently with the After= or Before= options. If a unit foo.service requires a unit bar.service as configured with Requires= and no ordering is configured with After= or Before=, then both units will be started simultaneously and without any delay between them if foo.service is activated. Often, it is a better choice to use Wants= instead of Requires= in order to achieve a system that is more robust when dealing with failing services.

Note that this dependency type does not imply that the other unit always has to be in active state when this unit is running. Specifically: failing condition checks (such as ConditionPathExists=, ConditionPathExists=, … — see below) do not cause the start job of a unit with a Requires= dependency on it to fail. Also, some unit types may deactivate on their own (for example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not propagated to units having a Requires= dependency. Use the BindsTo= dependency type together with After= to ensure that a unit may never be in active state without a specific other unit also in active state (see below).

Note that dependencies of this type may also be configured outside of the unit configuration file by adding a symlink to a .requires/ directory accompanying the unit file. For details, see above.

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=