qBittorrent/ipc-socket has an unsupported type (while updating flake)

[user@hostname:~]$ sudo nixos-rebuild switch --flake .#hostname
error:
       … while fetching the input 'path:/home/user'

       error: file '/home/user/.config/qBittorrent/ipc-socket' has an unsupported type
[user@hostname:~]$ sudo nixos-rebuild switch 
building the system configuration...
activating the configuration...
setting up /etc...
reloading user units for user...
restarting sysinit-reactivation.target
[user@hostname:~]$ nixos-version 
24.05.20240721.63d37cc (Uakari)

I’ve seen it a couple of times already but I don’t see a quick-fix for it yet.

Tried: deleting ~/.config/qBittorrent, changing to qbittorrent-qt5 (resulted in the same error)
and to qbittorrent-nox
which gave me this:

[user@hostname:~]$ sudo nixos-rebuild switch --flake .#hostname
error:
       … while updating the lock file of flake 'path:/home/user?lastModified=0&narHash=sha256-AyjUKdJ25Lqs6IM4vJcF9LUzXS2ons2QT1HWgeSF5ZU%3D'

       … while updating the flake input 'nixpkgs'

       … while fetching the input 'github:nixos/nixos-24.05'

       error: unable to download 'https://api.github.com/repos/nixos/nixos-24.05/commits/HEAD': HTTP error 404

       response body:

       {
         "message": "Not Found",
         "documentation_url": "https://docs.github.com/rest/commits/commits#get-a-commit",
         "status": "404"
       }

Try replacing that input’s URL with “nixpkgs/nixos-24.05” or “github:nixos/nixpkgs?ref=nixos-24.05”.

“github:nixos/nixos-24.05” would look for a repository literally called “nixos-24.05” under “nixos” on GitHub which does not exist.

The original error, however:

… while fetching the input 'path:/home/user'

       error: file '/home/user/.config/qBittorrent/ipc-socket' has an unsupported type

Means that you are using your entire home directory as an input to the flake. Before flakes are evaluated, they are copied into Nix store which is most likely not what you want. What’s the use case for that input?

1 Like

Tried the “github:nixos/nixpkgs?ref=nixos-24.05” and it worked! thanks!

Regarding the original error, the use case is personal, I am learning is there a problem with such approach? i thought i am allowed to do that? should i not do this? I am trying to fix this bug that is it

EDIT: @VTimofeenko
This original issue disappeared when the proper nixpkgs.url was inputted.

i thought i am allowed to do that?

While you can do this, does not necessarily mean you should :slight_smile:

A few things to be aware of:

Since

Before flakes are evaluated, they are copied into Nix store

This means:

  1. The nix store is world-readable, so this means that your user files now are world-readable.
  2. This would copy the entire home directory on every lock update and flake evaluation, so you might run out of disk space. See this thread for an example.
  3. Depending on the amount of stuff in your $HOME, locking would be much slower than usual

On top of that:

  1. Certain software (qbittorrent, evidently) likes to put its sockets into the user’s .config directory. Such files cannot be copied to the store and will lead to errors as you have observed. There’s probably a way to detect that (run something like find -t s and remove the sockets before doing anything else but that’s ugly). Usually software uses $XDG_RUNTIME_DIR to store sockets. Not sure if it’s not set in your case or qbittorrent just doesn’t care.
  2. A typical use case for paths as inputs for the flake is if you want to use them as a source for a package or use source of a specific file for an option or something like that. Again, you can do this the way you are doing it but I’d probably suggest using more narrow paths as the input – mostly for reasons 1-3.