What is the motivation for copying and not symlinking, as we do with /etc, which you've mentioned. Is it so users have something to edit?

Pretty sure it's so users can tweak it to their likings themselves and programs that require the ability to change them won't have problems

It depends a bit on the use-case I guess. For some use-cases you'd want the home directory to be read-only (and a symlink to) /nix/store. For instance when using the home directory for system services. In this case you'd want to set home yourself.

For most users you'd want a writable home directory. Since many applications will presume they can write there it makes sense to copy the actual file contents and make sure all files are writable for the user, thus not relying on /nix/store.

Seems like also when a new user is created, it isn't getting chmodded correctly, leaving me unable to login through SDDM (Xauthority unable to be written?). Chmodding my home directory non-recursively to 700 does fix the issue.

Properly chmodded home (isaac) vs. what it's getting chmodded to when user is created (testing14).

I'm not sure if it's related to this PR or not but I didn't seem to start having issues until I applied the patch to a local copy of the nixos-18.03 channel.

Possibly related to this? https://github.com/bobvanderlinden/nixpkgs/blob/e406c2d95d497da3ca6d05ac0c0a84188d372bed/nixos/modules/config/update-users-groups.pl#L218

I understand this change is intended to mimic the functionality of useradd --skel but how about making it so that new files can be added after the initial creation of the home directory?

The module could use an option similar to environment.etc to define the configuration at build time and then at runtime a systemd one-shot service (or an activation script) can copy any of the missing configurations to the user's home directory. In fact, the option can be used to define whether the file should be symlinked into the Nix store or copied.

  users.users.testuser = {
    isNormalUser = true;
    homeContents = {
      ".config/openbox/rc.xml" = {
        source = openboxConfig;
      };
    };
  };

This means that like with environment.etc other modules would be able to add content after-the-fact.

@emmanuelrosa Yes, that's what I was thinking as well. Is it possible to make files writable in etc? Most of the files are being symlinked afaik. That is often not what you want. On the other hand having writable files will not be very nice when combining with the one-shot service.

Also, this idea ties in with home-manager (https://github.com/rycee/home-manager) and nixuser (#9250). It's a bit messy since people cannot agree on a single solution it seems.

@tenten8401 It should now be fixed in the latest commit.

Fixed it locally on my end before I ran the tests with the bad chmod. I can try wiping nixos-18.03 and applying the patch again if you'd like.

This kind of imperative, one-time configuration mechanism seems pretty incompatible with the declarative approach in NixOS. As a general rule, the configuration resulting from a reconfiguration (nixos-rebuild) should be the same as from a install from scratch (nixos-install), but that's not the case here. For example, adding .config/openbox/rc.xml to initialHomeContents won't apply to existing users, so you get a divergence between configurations.

Only real good way I can think of doing this while remaining declarative is to look at the diff of the previous revision and the current revision and applying it to all the files in the home directory, that way it'd update files as needed to comply with the central declarative configuration file. I don't know of a good way to go about this however.

@edolstra I agree that this is not declarative and it won't work when changing things up. That's why I named it initialHomeContents, just like initialPassword. I do agree it would be nice to make it declarative, but I cannot find a good middleground. If a user wants ad-hoc writable files, how can these files also be maintained by Nix without getting into some weird state where half of the Nix-declared still have contents of the declaration and half of them don't? This is why I made initialHomeContents.

@tenten8401 I think applying only changes would be confusing, as it has the same issues as described above. initialHomeContents would at least suggest that it is only applicable to the creation of home, but with a solution that allows declaring of home it would cause confusion if those files are still writable.

The alternative is still to use the same setup as etc. This makes the declared files read-only, just like etc. It will work for the applications that are compatible with read-only files, which is fine for some use-cases. Support for writable files could perhaps be added later on, depending on how well the read-only files will work.

Would this (handling home as we do with etc) be a viable alternative? (= does it have the potential to be merged?)

Closing this one, because there is not much incentive to merge this.

@edolstra Should we close #33586, with the rationale you gave? (I'm personally of the opinion that it makes as much sense as initialPassword does, though)