With CMD [ ] "exec" format, Docker will try to look at the arguments and give its opinion about their usefulness. "Unable to access jarfile" is a Docker message, and it just means Docker has some (unspecified) issues with a jarfile. I've encountered it when the name of the jarfile contained an ENV variable, for instance. Docker couldn't handle that, apparently.

There's also the CMD "shell" format, CMD java -jar jar-runner.jar "some param" "some param". This is known as the shell format because Docker hands of the arguments to /bin/sh -c. As a result, it's not trying to second-guess what the arguments mean. sh in turn doesn't try to be smart either. And java is entirely capable of using jar-runner.jar.

Mind you, if you've got a typo in jar-runner.jar, or you put it in the wrong location, then Docker's message might be right. The shell workaround is useful when Docker guesses wrong.

It looks like you have the volume mounted, so assuming that you are correct that the jar file is available in the container via that volume, you probably just need to specify the path to it so java can find it.

CMD ["java", "-jar", "/home/selfbot/jar-runner.jar", "some param", "some param"]

You can check whether the file is really available by running a different command to just show you the contents of a given directory. Change the command (in Portainer) to something like

ls -la /home/selfbot

And then you can verify whether the jar file is actually where you think it, whether it is readable, etc. This command will exit right away, but its output will be available in the container log.

Try
ENTRYPOINT ["java","-jar","jar-runner.jar"] CMD ["some param"]

I had a similar issue here on my post: Error: Unable to access jarfile when running docker container