You are not logged in.
I had a working system where I had set up /home/user using systemd-homed (with using an entire drive as the encrypted home). I wanted to move home to a different drive and found out that it is not easy to do that with homed (at least as I had set it up), so I did the following. First, I logged out of the user and logged in as root. I stopped the homed service. I created a new user (with default UID of 1000, which is different than what homed chooses as a default UID for homed users). I then setup the new disk (which is encrypted and automatically unlocked at login with pam and mounted with fstab, as per the wiki instructions) and copied all the old files to the new disk. I then had to chown all the files in home because of the change in UID. Everything works fine with the new setup except that none of the services that I had previously enabled using 'systemctl --user enable' work (specifically the offlineimap and onedrive services).
They do work perfectly if I start them after logging in with 'systemctl --user start ...' but even after reenabling the services, they won't start at login. If I check the status, they just say "inactive." If I use journalctl, it just shows what the service was doing the last time it ran successfully, it doesn't show any errors for the current session.
When I enable the services, it does create symlinks in ~/.config/systemd/user/default.target.wants. default.target is also running. However, when I run 'systemctl --user list-dependencies default.target' (which I saw had been suggested in response to someone else's problem) it doesn't show either of the services that I have enabled.
Any ideas about why these aren't working anymore or how to debug/fix?
Last edited by slamhound (2021-02-18 21:10:18)
Offline
Thinking back to other changes I had made from when this was working, I think I figured out a fix. When setting up my encrypted home, I followed this link from the wiki on using pam to automatically mount home at login. The old directions said to use x-systemd.automount in the fstab entry, but the wiki was updated to recommend against that option, I guess because the automount option can cause some other problems (that don't apply to me, I think). I got the sense from an issue on the systemd github that sometimes pam and systemd don't set things up correctly with encrypted drives, so that gave me the idea to check whether adding x-systemd.automount back in to the fstab entry would fix things, and it seems as though it has. So if anyone else has this problem with user services not working with an encrypted home, that may be the issue.
Offline