You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This seems to be a re-occurrence of #3 and was introduced somewhere between image revision 948e90e (works) and latest 7d735cc (has the error).
Setting HOME in startapp.sh doesn't seem to be sufficient for borg to look up the ssh config. I appears to be using the app user's actual home dir in passwd, which is /dev/null.
2026-05-15 09:28:39,254 - vorta.borg.borg_job - INFO - Running command: /usr/bin/borg create <snip parameters>
2026-05-15 09:28:41,030 - vorta.borg.borg_job - WARNING - Remote: hostkeys_find_by_key_hostfile: hostkeys_foreach failed for /dev/null/.ssh/known_hosts: Not a directory
2026-05-15 09:28:41,031 - vorta.borg.borg_job - WARNING - Remote: ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory
2026-05-15 09:28:41,032 - vorta.borg.borg_job - WARNING - Remote: Host key verification failed.
2026-05-15 09:28:41,037 - vorta.borg.borg_job - ERROR - Connection closed by remote host. Is borg working on the server?
This might be a bug in borg that I can't address. Can you reach out there and see what they say?
In the meantime, I'll see if I can come up with a solution but I don't have one yet. You may need to us the old image for now.
I ended up adding usermod back into my image and that isn't working yet
Was that in a separate change to #35? I don't see anything in that PR that would install usermod. (Or am I misunderstanding what you're saying there/the nature of the problem? I'm not super familiar with the approach the base image is using.)
Did a bit more digging and it definitely seems to be borg (or openssh itself?) ignoring the HOME environment variable and only looking at /etc/passwd for the app user's home directory.
sed -i -r s/app\:\:\([0-9]+\):\([0-9]+\)::[^:]+:\(.+\)/app\:\:\\1\:\\2\:\:\\/config\:\\3/ /etc/passwd
...then it resolves this issue.
It doesn't seem wrong for an application to use the user's canonical home directory rather than the environment variable, so I'd guess this is a base image issue to solve rather than an application bug.
The usermod change was something I tried but since it didn't work, I didn't push it up.
It sounds like it may be addressed in the baseimage, and it definitely is an app bug I think.
For now, as both of you have suggested, I'm pushing up an instance with the above sed. I was trying to avoid manual manipulation but 🤷
Activity
Ranbato commentedon May 15, 2026
I think it is fixed with the above change. If you can, please confirm and let me know.
The image is ghcr.io/borgbase/vorta-docker:f989d72
IntermittentlyRupert commentedon May 16, 2026
I wasn't able to pull that image, sorry. But I built and tested #35, and I saw the same error as before.
Ranbato commentedon May 16, 2026
This might be a bug in borg that I can't address. Can you reach out there and see what they say?
In the meantime, I'll see if I can come up with a solution but I don't have one yet. You may need to us the old image for now.
IntermittentlyRupert commentedon May 17, 2026
Sure, I'll also see if I can put together a standalone minimal reproduction.
Just to double check something - in jlesage/docker-baseimage-gui#190 you say:
Was that in a separate change to #35? I don't see anything in that PR that would install
usermod. (Or am I misunderstanding what you're saying there/the nature of the problem? I'm not super familiar with the approach the base image is using.)IntermittentlyRupert commentedon May 17, 2026
Did a bit more digging and it definitely seems to be borg (or openssh itself?) ignoring the
HOMEenvironment variable and only looking at/etc/passwdfor the app user's home directory.The base container doesn't let you set the app user's home dir in
/etc/passwdbut if I manually sed replace it in50-init.sh:...then it resolves this issue.
It doesn't seem wrong for an application to use the user's canonical home directory rather than the environment variable, so I'd guess this is a base image issue to solve rather than an application bug.
Ranbato commentedon May 18, 2026
The
usermodchange was something I tried but since it didn't work, I didn't push it up.It sounds like it may be addressed in the baseimage, and it definitely is an app bug I think.
For now, as both of you have suggested, I'm pushing up an instance with the above
sed. I was trying to avoid manual manipulation but 🤷IntermittentlyRupert commentedon May 18, 2026
Yeah, I agree it's definitely not ideal. IMO if the base image sets the home dir in
/etc/passwdthat'd be much cleaner.Really appreciate how responsive and helpful you've been on this! Thanks! 🙏