Hey Markus. Thank you for providing details about your environment. Unfortunately we don't have any new ideas on how to solve home-at-nearly arbitrary path and we certainly didn't have time to push this idea forward.
One idea I had a while ago is to mount whatever the original location of HOME, at /var/home/$LOGNAME, offering unique path for any user. This is assuming the path cannot be represented in the original location. This technically could work, we would have a fixed extension of various key paths and the security subsystem would be able to handle that. What would not be optimal is the disconnect between what a snap application process thinks on the inside of the environment (e.g. HOME is /var/home/zyga) and what the system meta-data says (e.g. /home/zyga). We have a variation of that problem today (/home/zyga for real and /home/zyga/snap/$SNAP_NAME/$SNAP_REVISION) but we wanted to figure out how to avoid that as well. If the end user experience is acceptable, that would be something worth considering, especially if this makes the snap ecosystem usable. I cannot comment on the kerberos details. I think snapd could work in this environment as we have supported root squashing NFS home in /home/$LOGNAME before. I think we could only push forward (e.g. handle more paths via /var/home idea) and see what's missing. I can try proposing an experimental feature for /var/home and see if that helps you out. I could do this assuming you are willing to report back and share your experience and issues you've encountered. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1662552 Title: snaps don't work with NFS home To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1662552/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
