I tried it without using the Variables on top of that file but ended in the same result.
When I start:
nixos-rebuild test
it results in:
A definition for option `systemd.mounts' is not of type `list of submodules'.
with different outputs when I comment out single lines to determine which one could be wrong.
is here a “module” missing?
{ config, ... }:
Can someone point me where I’m wrong? I don’t see it.
Would it be possible to replace the [servername] by a variable? This would make it easier to change a share location with editing a single variable, since I would mount several shares from a single server.
Nix is a quiet powerful technique. I just started digging around and have some machines replaced with nixos. One Laptop, a workstation and a pi400. This is a good way to unifi the configuration across these machines. I think this is great.
I had to setup some systemd mounts and automounts and stumbled upon your question. The issue with your suggested configuration is actually simple, NixOS options dictate the following for systemd.mounts:
Definition of systemd mount units. This is a list instead of an attrSet, because systemd mandates the names to be derived from the ‘where’ attribute.
As such, the following code should work for you:
{ config, ... }:
{
boot.supportedFilesystems = [ "cifs" ];
systemd.mounts = [{
description = "Mount for server ...";
what = "//[servername]/[share]";
where = "/server/[servername]/[share]";
type = "cifs";
options = "username=[MYUSER],password=[MySecretPassword],rw";
}];
systemd.automounts = [{
description = "Automount for server...";
where = "/server/[servername]/[share]";
wantedBy = [ "multi-user.target" ];
}];
}
So, besides the list thing I have 3 more tips to give you:
No need to define any requirement for the network target. According to the man page of systemd.mount:
Network mount units automatically acquire After= dependencies on remote-fs-pre.target, network.target and network-online.target, and gain a Before= dependency on remote-fs.target unless nofail mount option is set. Towards the latter a Wants= unit is added as well.
If you intend to use automount, then you should not set wantedBy = [ "multi-user.target" ]; to the mount, as this should take over any work of automount and mount the share permanently.
You need to explicitly set boot.supportedFilesystems = [ "cifs" ];, so that mount.cifs is available to systemd.
I did mean to write not, it was intentional. Let me refine this:
If the mount unit (not to be confused with the automount one) has the specific WantedBy attribute, then what is defined can get mounted by that unit. multi-user.target means that the mount should happen once systemd considers the system ready for multi-user use (source).
This is not something I want, though, for CIFS shares, I want them to be available on-demand, i.e., in case I try to access data from those specific mounts. For that reason, I define the automount units and set them available (wantedBy) on the multi-user.target.
@realloki’s example had wantedBy defined in both mount and automount units and I considered important to distinguish their use in my response.
Instead of using “multi-user.target” “default.target” can be used. This worked for me. In automounts of course, like you mentioned without setting this in mount.
I also replaced the options username and password with a credentials option with a file for the credentials. This way the credentials are only placed once in this file and must not be repeated for each share in mounts.
Note that you usually don’t need to make custom mount and automount units. You should usually just set your file systems normally and use the x-systemd.automount option. e.g.
systemd will correctly handle the unit dependencies and ordering on its own, including ordering around network targets for networked fsTypes. See the details in the systemd.mount(5) and systemd.automount(5) man pages.
I mention this partly because if changing multi-user.target to default.target works, you’re in the realm of strange magic because that shouldn’t make a difference. But systemd’s fstab parser will definitely get it right
@realloki Feels good to see that you managed to configure this.
As @ElvishJerricco pointed out, one could use the fileSystems options as well. AFAIK, this involves yet another systemd component, systemd-fstab-generator, which transforms the /etc/fstab file to systemd unit files. Since it is not hard to write those unit files on my own, I prefer the systemd units approach.
@ElvishJerricco as aforementioned, I think both approaches are almost identical, so service ordering should take place in both.
Regarding default.target and multi-user.target, please check systemd.special(7) - Linux manual page. My proposal is to keep using multi-user.target since this will not try to mount your network filesystems if you try to boot on single-user or rescue mode. But then again, how often are we using those modes?
@joko
between fstab and automount is one diffrence. automount mounts and unmounts automatically and when needed. Where fstab mounts are always mounted or must be manually mounted.
or am I wrong? Ohh, I see… combined with the automount… yes it’s an other way.
If I’m on single user mode I could imagine that it would be nice to be able to save some data off that machine?!? So it could be helpful to have a server share mounted.
@ElvishJerricco For (mostly) permanently USB attached disks, which should be remounted on spurious failures, is fileSystem still the way to go, or is systemd.mounts more appropriate for that situation?
There’s nearly zero reasons to ever write custom systemd.mounts units. Unless there’s something you actually cannot do with fstab / fileSystems, you should use it.
