nbdkit man page

nbdkit — A toolkit for creating NBD servers


 nbdkit [-e EXPORTNAME] [--exit-with-parent] [-f]
        [--filter=FILTER ...] [-g GROUP] [-i IPADDR]
        [--newstyle] [--oldstyle] [-P PIDFILE] [-p PORT] [-r]
        [--run CMD] [-s] [--selinux-label LABEL] [-t THREADS]
        [--tls=off|on|require] [--tls-certificates /path/to/certificates]
        [-U SOCKET] [-u USER] [-v] [-V]
        PLUGIN [key=value [key=value [...]]]

 nbdkit --dump-config

 nbdkit PLUGIN --dump-plugin


Network Block Device (NBD) is a network protocol for accessing block devices over the network.  Block devices are hard disks and things that behave like hard disks such as disk images and virtual machines.

"nbdkit" is both a toolkit for creating NBD servers from "unconventional" sources and the name of an NBD server.

To create a new Network Block Device source, all you need to do is write a few glue functions, possibly in C, or perhaps in a high level language like Perl or Python.  The liberal licensing of nbdkit is meant to allow you to link nbdkit with proprietary libraries or to include nbdkit in proprietary code.

If you want to write an nbdkit plugin, you should read nbdkit-plugin(3).

Several plugins may be found in "$libdir/nbdkit/plugins".  You can give the full path to the plugin, like this:

 nbdkit $libdir/nbdkit/plugins/nbdkit-file-plugin.so [...]

but it is usually more convenient to use this equivalent syntax:

 nbdkit file [...]

$libdir is set at compile time.  To print it out, do:

 nbdkit --dump-config


Basic file serving

Serve file disk.img on port 10809 using nbdkit-file-plugin(1):

 nbdkit file file=disk.img

Run the nbdkit-example3-plugin(1) and connect to it using guestfish(1):

 nbdkit example3 size=1G
 guestfish --ro --format=raw -a nbd://localhost

Serve file disk.img on port 10809, requiring clients to use encrypted (TLS) connections:

 nbdkit --tls=require file file=disk.img

Combining plugins and filters

Serve only the first partition from compressed disk image disk.img.xz, combining nbdkit-xz-plugin(1) and nbdkit-partition-filter(1):

                        plugin name and parameter
 nbdkit --filter=partition xz file=disk.img.xz partition=1
                filter name and filter parameter

Display information

Display information about nbdkit or a specific plugin:

 nbdkit --help
 nbdkit --version
 nbdkit --dump-config
 nbdkit example1 --help
 nbdkit example1 --dump-plugin

Global Options


Display brief command line usage information and exit.


Dump out the compile-time configuration values and exit. See "Probing Configuration and Plugins" below.


Dump out information about the plugin and exit. See "Probing Configuration and Plugins" below.


If the parent process exits, we exit.  This can be used to avoid complicated cleanup or orphaned nbdkit processes.  There are some important caveats with this, see "Exit with Parent" below.  An alternative to this is "Captive Nbdkit" described below.

This option implies --foreground.

--export-name EXPORTNAME
--exportname EXPORTNAME

Set the exportname.

If not set, exportname "" (empty string) is used.  Exportnames are not allowed with the oldstyle protocol.


Don't fork into the background.

--filter FILTER

Add a filter before the plugin.  This option may be given one or more times to stack filters in front of the plugin.  They are processed in the order they appear on the command line.  See "Filters" and nbdkit-filter(3).

--group GROUP

Change group to "GROUP" after starting up.  A group name or numeric group ID can be used.

The server needs sufficient permissions to be able to do this. Normally this would mean starting the server up as root.

See also -u.

--ip-addr IPADDR
--ipaddr IPADDR

Listen on the specified interface.  The default is to listen on all interfaces.  See also -p.


Use the newstyle NBD protocol protocol.  This is the default in nbdkit ≥ 1.1.29.  In earlier versions the default was oldstyle.

See "New Style VS Old Style Protocol" below.


Use the oldstyle NBD protocol.  This was the default in nbdkit ≤ 1.1.28, but now the default is newstyle.  Note this is incompatible with newer features such as export names and TLS.

See "New Style VS Old Style Protocol" below.

--pid-file PIDFILE
--pidfile PIDFILE

Write "PIDFILE" (containing the process ID of the server) after nbdkit becomes ready to accept connections.

If the file already exists, it is overwritten.  nbdkit does not delete the file when it exits.

--port PORT

Change the TCP/IP port number on which nbdkit serves requests. The default is 10809.  See also -i.


The export will be read-only.  If a client writes, then it will get an error.

Note that some plugins inherently don't support writes.  With those plugins the -r option is added implicitly.

Copy-on-write (or "snapshot") functionality is not supported by this server.  However if you are using qemu as a client (or indirectly via libguestfs) then it supports snapshots.

--run CMD

Run nbdkit as a captive subprocess of "CMD".  When "CMD" exits, nbdkit is killed.  See "Captive Nbdkit" below.

This option implies --foreground.


Don't fork.  Handle a single NBD connection on stdin/stdout.  After stdin closes, the server exits.

You can use this option to run nbdkit from inetd or similar superservers; or just for testing; or if you want to run nbdkit in a non-conventional way.  Note that if you want to run nbdkit from systemd, then it may be better to use "Socket Activation" instead of this option.

This option implies --foreground.

--selinux-label SOCKET-LABEL

Apply the SELinux label "SOCKET-LABEL" to the nbdkit listening socket.

The common — perhaps only — use of this option is to allow libvirt guests which are using SELinux and sVirt confinement to access nbdkit Unix domain sockets:

 nbdkit --selinux-label system_u:object_r:svirt_t:s0 ...
--threads THREADS

Set the number of threads to be used per connection, which in turn controls the number of outstanding requests that can be processed at once.  Only matters for plugins with thread_model=parallel (where it defaults to 16).  To force serialized behavior (useful if the client is not prepared for out-of-order responses), set this to 1.


Disable, enable or require TLS (authentication and encryption support).  See "TLS" below.

--tls-certificates /path/to/certificates

Set the path to the TLS certificates directory.  If not specified, some built-in paths are checked.  See "TLS" below for more details.


Enables TLS client certificate verification.  The default is not to check the client's certificate.

--unix SOCKET
-U -
--unix -

Accept connections on the Unix domain socket "SOCKET" (which is a path).

nbdkit creates this socket, but it will probably have incorrect permissions (too permissive).  If it is a problem that some unauthorized user could connect to this socket between the time that nbdkit starts up and the authorized user connects, then put the socket into a directory that has restrictive permissions.

nbdkit does not delete the socket file when it exits.  The caller should delete the socket file after use (else if you try to start nbdkit up again you will get an "Address already in use" error).

If the socket name is - then nbdkit generates a randomly named private socket.  This is useful with "Captive Nbdkit".

--user USER

Change user to "USER" after starting up.  A user name or numeric user ID can be used.

The server needs sufficient permissions to be able to do this. Normally this would mean starting the server up as root.

See also -g.


Enable verbose messages.

It's a good idea to use -f as well so the process does not fork into the background (but not required).


Print the version number of nbdkit and exit.

Plugin Configuration

After specifying the plugin name you can (optionally, it depends on the plugin) give plugin configuration on the command line in the form of "key=value".  For example:

 nbdkit file file=disk.img

To list all the options supported by a plugin, do:

 nbdkit --help file

To dump information about a plugin, do:

 nbdkit file --dump-plugin

Magic script parameter

As a special case, if the first plugin argument does not contain an '=' character then it is assumed to be "script=value".

That allows scripting language plugins like nbdkit-perl-plugin(1) to do:

 nbdkit perl foo.pl [args...]

which has the same meaning as:

 nbdkit perl script=foo.pl [args...]

Shebang scripts

You can use "#!" to run nbdkit plugins written in most scripting languages.  The file should be executable.  For example:

 #!/usr/sbin/nbdkit perl
 sub open {
   # etc

(see nbdkit-perl-plugin(3) for a full example).


One or more filters can be placed in front of an nbdkit plugin to modify the behaviour of the plugin, using the --filter parameter. Filters can be used for example to limit requests to an offset/limit, add copy-on-write support, or inject delays or errors (for testing).

Several existing filters are available in the $filterdir.  Use "nbdkit --dump-config" to find the directory name.

How to write filters is described in nbdkit-filter(3).

Socket Activation

nbdkit supports socket activation (sometimes called systemd socket activation).  This is a simple protocol where instead of nbdkit itself opening the listening socket(s), the parent process (typically systemd) passes in pre-opened file descriptors.  Socket activation lets you serve infrequent NBD requests using a superserver without needing nbdkit to be running the whole time.

Socket activation is triggered when both the "LISTEN_FDS" and "LISTEN_PID" environment variables are set.  In this mode using -i, -p, --run, -s or -U flags on the command line is illegal and will cause an error.  Also in this mode nbdkit does not fork into the background (ie. -f is implied).

Using socket activation with systemd

To use nbdkit with socket activation from systemd, create a unit file ending in ".socket" (eg. "/etc/systemd/system/nbdkit.socket") containing:

 Description=NBDKit Network Block Device server

There are various formats for the "ListenStream" key.  See systemd.socket(5) for more information.

Also create a service unit (eg. "/etc/systemd/system/nbdkit.service") containing:

 ExecStart=/usr/sbin/nbdkit file file=/path/to/serve

For more information on systemd and socket activation, see <http://0pointer.de/blog/projects/socket-activation.html>

Captive Nbdkit

You can run nbdkit as a "captive process", using the --run option. This means that nbdkit runs as long as (for example) qemu(1) or guestfish(1) is running.  When those exit, nbdkit is killed.

Some examples should make this clear.

To run nbdkit captive under qemu:

 nbdkit file file=disk.img --run 'qemu -drive file=$nbd,if=virtio'

On the qemu command line, $nbd is substituted automatically with the right NBD path so it can connect to nbdkit.  When qemu exits, nbdkit is killed and cleaned up automatically.

Running nbdkit captive under guestfish:

 nbdkit file file=disk.img --run 'guestfish --format=raw -a $nbd -i'

When guestfish exits, nbdkit is killed.

The following shell variables are available in the --run argument:


A URL that refers to the nbdkit port or socket.

Note there is some magic here, since qemu and guestfish URLs have a different format, so nbdkit tries to guess which you are running.  If the magic doesn't work, try using the variables below instead.


If ≠ "", the port number that nbdkit is listening on.


If ≠ "", the Unix domain socket that nbdkit is listening on.

--run implies --foreground.  It is not possible, and probably not desirable, to have nbdkit fork into the background when using --run.

Even when running captive, nbdkit still listens on the regular TCP/IP port, unless you specify the -p/-U options.  If you want a truly private captive nbdkit, then you should create a private random Unix socket, like this:

 nbdkit -U - plugin [args] --run '...'

Exit with Parent

The --exit-with-parent option is almost the opposite of "Captive Nbdkit" described in the previous section.

Running nbdkit with this option, for example from a script:

 nbdkit --exit-with-parent plugin ... &

means that nbdkit will exit automatically if the parent program exits for any reason.  This can be used to avoid complicated cleanups or orphaned nbdkit processes.

--exit-with-parent is incompatible with forking into the background (because when we fork into the background we lose track of the parent process).  Therefore -f / --foreground is implied.

This is currently implemented using a feature of the Linux kernel, so it requires a Linux build of nbdkit and won't work on other operating systems (patches welcome to make it work).

If the parent application is multithreaded, then (in the Linux implementation) if the parent thread exits, that will cause nbdkit to exit.  Thus in multithreaded applications you usually want to run "nbdkit --exit-with-parent" only from the main thread (unless you actually want nbdkit to exit with the thread, but that may not work reliably if we extend the implementation to other operating systems).

New Style VS Old Style Protocol

The NBD protocol comes in two incompatible forms that we call "oldstyle" and "newstyle".  Unfortunately which protocol you should use depends on the client and cannot be known in advance, nor can it be negotiated from the server side.

nbdkit defaults to the newstyle protocol since nbdkit ≥ 1.1.29. Use the -e or --exportname flag to set the optional exportname for the newstyle protocol.  Use the -o or --oldstyle flag to force the oldstyle protocol.

Some common clients and the protocol they require:

 Client                          Protocol
 qemu <= 2.5 without exportname  oldstyle
 qemu <= 2.5 with exportname     newstyle
 qemu >= 2.6                     client can talk either protocol
 nbd-client < 3.10               client can talk either protocol
 nbd-client >= 3.10              newstyle
 any TLS (encrypted) client      newstyle
 nbdkit nbd plugin               client can talk either protocol

If you use qemu ≤ 2.5 without the exportname field against a newstyle server, it will give the error:

 Server requires an export name

If you use qemu ≤ 2.5 with the exportname field against an oldstyle server, it will give the error:

 Server does not support export names

If you use the oldstyle protocol with nbd-client ≥ 3.10, it will give the error:

 Error: It looks like you're trying to connect to an oldstyle server.

If you want to claim compatibility with what the NBD proto.txt document says should be the case (which isn't based in reality), then you should always use newstyle when using port 10809, and use oldstyle on all other ports.


TLS (authentication and encryption, sometimes incorrectly called "SSL") is supported if nbdkit was compiled with GnuTLS.  This allows the server to verify that the client is allowed access, and to encrypt the contents of the protocol in transit over the network.

TLS can be disabled or enabled by specifying either --tls=off or --tls=on.  With --tls=off, if a client tries to use TLS to connect, it will be rejected by the server (in other words, as if the server doesn't support TLS).

--tls=on means that the client may choose to connect either with or without TLS.

Because --tls=on is subject to downgrade attacks where a malicious proxy pretends not to support TLS in order to force either the client or server to communicate in plaintext, you can also specify --tls=require, where the server enables TLS and rejects all non-TLS connection attempts.

TLS with X.509 certificates

When nbdkit starts up, it loads TLS certificates from some built-in paths, or from the directory specified by the --tls-certificates option.

Without --tls-certificates, if nbdkit is started as a non-root user (note this does not include use of the -u or -g options), nbdkit looks in each of these paths in turn:


Without --tls-certificates, if nbdkit is started as root, nbkit looks in:


(Use "nbdkit --dump-config" and look at the "root_tls_certificates_dir" setting to get the actual directory built into the binary.)

You can override both directories above by using --tls-certificates /path/to/certificates.

In this directory, nbdkit expects to find several files:


The Certificate Authority certificate.


The server certificate.


The server private key.


(Optional) The certificate revocation list.

Setting up the Certificate Authority

This step only needs to be done once per organization.  It may be that your organization already has a CA.

 $ certtool --generate-privkey > ca-key.pem
 $ chmod 0600 ca-key.pem

The ca-key.pem file is the CA private key and is extremely sensitive data.  With possession of this key, anyone can create certificates pretending to be your organization!

To create the CA certificate file:

 $ cat > ca.info <<EOF
 cn = Name of your organization
 $ certtool --generate-self-signed \
            --load-privkey ca-key.pem \
            --template ca.info \
            --outfile ca-cert.pem

Issuing a server certificate for the nbdkit server

Each nbdkit server (or host) needs a secret key and certificate.

 $ certtool --generate-privkey > server-key.pem
 $ chmod 0600 server-key.pem

The server key file is sensitive.  Setting the mode to 0600 helps to prevent other users on the same machine from reading it.

The server DNS name ("cn" below) must be the fully qualified hostname — and the only hostname — that the client connects to.

 $ cat > server.info <<EOF
 organization = Name of your organization
 cn = nbd-server.example.com
 $ certtool --generate-certificate \
            --load-ca-certificate ca-cert.pem \
            --load-ca-privkey ca-key.pem \
            --load-privkey server-key.pem \
            --template server.info \
            --outfile server-cert.pem

Issuing and checking client certificates

Note: You don't need to create client certificates unless you want to check and limit which clients can connect to nbdkit.  nbdkit does not check client certificates unless you specify the --tls-verify-peer option on the command line.

For each client you should generate a private key and a client certificate:

 $ certtool --generate-privkey > client-key.pem
 $ chmod 0600 client-key.pem

The client key file is sensitive.

The client DNS name ("cn" below) is the client's name that nbdkit sees and checks.

 $ cat > client.info <<EOF
 country = US
 state = New York
 locality = New York
 organization = Name of your organization
 cn = client.example.com
 $ certtool --generate-certificate \
            --load-ca-certificate ca-cert.pem \
            --load-ca-privkey ca-key.pem \
            --load-privkey client-key.pem \
            --template client.info \
            --outfile client-cert.pem

Client certificates do not need to be present anywhere on the nbdkit host.  You don't need to copy them into nbdkit's TLS certificates directory.  The security comes from the fact that the client must present a client certificate signed by the Certificate Authority, and nbdkit can check this because it has the ca-cert.pem file.

To enable checking of client certificates, specify the --tls-verify-peer option on the command line.  Clients which don't present a valid certificate (eg. not signed, incorrect signature) are denied.  Also denied are clients which present a valid certificate signed by another CA.  Also denied are clients with certificates added to the certificate revocation list (ca-crl.pem).

Default TLS behaviour

If nbdkit was compiled without GnuTLS support, then TLS is disabled and TLS connections will be rejected (as if --tls=off was specified on the command line).  Also it is impossible to turn on TLS in this scenario.  You can tell if nbdkit was compiled without GnuTLS support because "nbdkit --dump-config" will contain "tls=no".

If TLS certificates cannot be loaded either from the built-in path or from the directory specified by --tls-certificates, then TLS defaults to disabled.  Turning TLS on will give a warning (--tls=on) or error (--tls=require) about the missing certificates.

If TLS certificates can be loaded from the built-in path or from the --tls-certificates directory, then TLS will by default be enabled (like --tls=on), but it is not required.  Clients can choose whether or not to use TLS and whether or not to present certificates.

TLS client certificates are not checked by default unless you specify --tls-verify-peer.

Each of these defaults is insecure to some extent (including --tls=on which could be subject to a downgrade attack), so if you expect TLS then it is best to specify the --tls option that you require, and if you want to check client certificates, specify the --tls-verify-peer option.

Choice of TLS algorithms

TLS has a bewildering choice of algorithms that can be used.  To enable you to choose a default set of algorithms, there is a configure setting "--with-tls-priority".  This defaults to "NORMAL" which, to quote the GnuTLS documentation:

""NORMAL" means all "secure" ciphersuites.  The 256-bit ciphers are included as a fallback only.  The ciphers are sorted by security margin."

You could also set the TLS priority so that it can be configured from a file at runtime:

 ./configure --with-tls-priority=@SYSTEM

means use the policy from /etc/crypto-policies/config.

 ./configure --with-tls-priority=@NBDKIT,SYSTEM

means use the policy from /etc/crypto-policies/local.d/nbdkit.config and fall back to /etc/crypto-policies/config if the first file does not exist.

More information can be found in gnutls_priority_init(3).

Probing Configuration and Plugins

You can query information about nbdkit and available plugins from the nbdkit binary.

Query basic configuration

 nbdkit --dump-config

lists information about how nbdkit was configured.  The most important fields in the output are the name of the directory where nbdkit looks for plugins and the version of nbdkit, eg:


Query information about a particular plugin

 nbdkit pluginname --dump-plugin

(where pluginname is the name or full path of a plugin) will dump information about that plugin, eg:

 $ nbdkit file --dump-plugin

Plugins which ship with nbdkit usually have the same version as the corresponding nbdkit binary.  The nbdkit binary will always be able to utilize plugins compiled against an older version of the header; however, newer plugins may not be fully supported by an older nbdkit binary (for example, a plugin compiled with "NBDKIT_API_VERSION" of 2 fails to load with an older nbdkit that only knows "NBDKIT_API_VERSION" 1).

Detect if a plugin is installed

To find out if a plugin is installed (and working) in the plugin directory, use --dump-plugin as above:

 $ nbdkit foo --dump-plugin
 nbdkit: /usr/lib64/nbdkit/plugins/nbdkit-foo-plugin.so: /usr/lib64/nbdkit/plugins/nbdkit-foo-plugin.so: cannot open shared object file: No such file or directory

Note it is better to test for the existence of plugins this way rather than just seeing if the .so file exists, because nbdkit will load the plugin and check that all its dependencies can be satisfied, and also that plugin registration works.

List all plugins in the plugin directory

You could simply get the plugin directory (from --dump-config) and list all files in this directory called nbdkit-*-plugin.so.

However a better test is to run --dump-plugin (see above) on each one to check that it is working and all of its dependencies are installed.  A complete shell script which does this is:

 #!/bin/sh -
 plugindir=`nbdkit --dump-config | grep ^plugindir= | sed 's/[^=]*=//'`
 for f in $plugindir/nbdkit-*-plugin.so; do
     if nbdkit "$f" --dump-plugin >/dev/null 2>&1; then
         b=`echo "$f" | sed 's,.*/nbdkit-\(.*\)-plugin.so$,\1,'`
         echo "$b ($f)"


"nbdkit" responds to the following signals:


The server exits cleanly.


This signal is ignored.

Environment Variables


If present in the environment when nbdkit starts up, these trigger "Socket Activation".

See Also


nbdkit-curl-plugin(1), nbdkit-example1-plugin(1), nbdkit-example2-plugin(1), nbdkit-example3-plugin(1), nbdkit-example4-plugin(1), nbdkit-file-plugin(1), nbdkit-guestfs-plugin(1), nbdkit-gzip-plugin(1), nbdkit-libvirt-plugin(1), nbdkit-memory-plugin(1), nbdkit-nbd-plugin(1), nbdkit-null-plugin(1), nbdkit-split-plugin(1). nbdkit-streaming-plugin(1). nbdkit-tar-plugin(1). nbdkit-vddk-plugin(1). nbdkit-xz-plugin(1).


nbdkit-blocksize-filter(1), nbdkit-cache-filter(1), nbdkit-cow-filter(1), nbdkit-delay-filter(1), nbdkit-fua-filter(1), nbdkit-log-filter(1), nbdkit-nozero-filter(1), nbdkit-offset-filter(1), nbdkit-partition-filter(1).

For developers:

nbdkit-plugin(3), nbdkit-filter(3).

Writing plugins in other programming languages:

nbdkit-ocaml-plugin(3), nbdkit-perl-plugin(3), nbdkit-python-plugin(3), nbdkit-ruby-plugin(3).

Other manual pages of interest:

gnutls_priority_init(3), guestfish(1), qemu(1), systemd.socket(5).


Eric Blake

Richard W.M. Jones

Pino Toscano


Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:


Referenced By

guestfs-hacking(1), nbdkit-blocksize-filter(1), nbdkit-cache-filter(1), nbdkit-cow-filter(1), nbdkit-curl-plugin(1), nbdkit-delay-filter(1), nbdkit-example1-plugin(1), nbdkit-example2-plugin(1), nbdkit-example3-plugin(1), nbdkit-example4-plugin(1), nbdkit-file-plugin(1), nbdkit-filter(3), nbdkit-fua-filter(1), nbdkit-guestfs-plugin(1), nbdkit-gzip-plugin(1), nbdkit-libvirt-plugin(1), nbdkit-log-filter(1), nbdkit-memory-plugin(1), nbdkit-nbd-plugin(1), nbdkit-nozero-filter(1), nbdkit-null-plugin(1), nbdkit-ocaml-plugin(3), nbdkit-offset-filter(1), nbdkit-partition-filter(1), nbdkit-perl-plugin(3), nbdkit-plugin(3), nbdkit-python-plugin(3), nbdkit-ruby-plugin(3), nbdkit-split-plugin(1), nbdkit-streaming-plugin(1), nbdkit-tar-plugin(1), nbdkit-xz-plugin(1), virt-p2v(1), virt-v2v(1).

2018-04-06 nbdkit