permission error when switching configuration using a read-only persistent source

[rogarb]

I am using impermanence to setup different persistent files and folders from different filesystems, one of them being mounted read-only.

When running nixos-rebuild switch, I am running into an error from the activation script due to the line 62 in create-directories.bash, where the script ensures that the target folder has the same owner as the source folder.

The problem is that at that point in time, the target folder contains a read-only binding and is thus also read-only, leading to a error of chown.

I already wrote a fix which works with my setup, where I check if the target folder contains a read-only mounted filesystem/binding and unmount it.

As I would like to submit a PR for this issue, I am wondering if it is the right solution. I see 2 other alternative solutions:

• check for mounted fs/binding in target folder, regardless of read-only option. I guess that it would be logical for the script responsible to create the mountpoint and to ensure it has correct ownership/permissions that the source binding would not be mounted at that moment. The possible problem I can see is that if any file is currently used by any process (which is not unlikely to happen), it will throw an error (which is also the case of the solution I provided).
• conditionally ensure the ownership/permissions of target folder only when it doesn't contain a (read-only) binding. I think this is the safest solution, as it wouldn't attempt to do anything on a running system, but I might have overseen any subtility.

Any idea on which is a better way to fix this?

For the record, it is a really minor error which doesn't prevent the remaining steps of the activation script to be accomplished, but IMHO it should still be addressed.

[talyz]

Hi rogarb!

What target file / directory is mounted read-only? I've never heard of this being an issue before, so I'm a bit curious. If this is by design, what's the use-case?

To me, this sounds like an issue that should be solved on a local configuration level and failing on a read-only bound target could mostly be a good thing, but maybe I'm missing some crucial info. Either way, we don't mess around with already existing target files, as this can cause issues with running programs and services, so the only viable solution would be your second one. For a local solution to the issue, you could create a systemd service or activation script snippet that does the remounting before we see it.

[rogarb]

Hi,

I recently stopped to use impermanence with read-only mounts. FYI, my use case was to have a separate partition containing system related data: /etc/nixos and /etc/NetworkManager/system-connections (the only non declarative configuration I had). The idea was that /etc/nixos being a git repo owned by a regular user (because of git/gpg keys configuration), I wanted to explicitly allow writes to the repo when I was working on the configuration.

Now I switched my wifi configuration to declarative style using wpa_supplicant and I transfered /etc/nixos to its own btrfs subvolume, which I can mount with its own specific options (ro in my case). I keep using impermanence with my regular user account, as it gives the flexibility to have persistent files in non-persistent folders, but I would definitely be happy to get rid of the dotfiles mess in the home folder...

Anyway, I guess it is now time to close the issue, feel free to reopen it if you want more feedback from me.