Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

UNIX Installation

You will likely need to build Synchronet from source code for your Unix/Linux distribution, version, and platform architecture.

Before attempting to install/build Synchronet, insure that the prerequisites are installed.

You will to use a *nix terminal and command shell (e.g. sh/bash) to install and configure Synchronet.

Run-as User

It is recommended that you install Synchronet while logged-in with the user account that Synchronet will be run-as. If you install with one user account and then later run with another (non-root) user account, you could encounter permissions errors. Running the BBS servers/services (sbbs) as the root user is not recommended.

Use “adduser sbbs” (or “sudo adduser sbbs” if necessary) to create the user account and “su sbbs” to switch to it:

$ su sbbs
$ whoami

If you find it necessary to start the BBS servers/services as root, then you can have the BBS daemon (sbbs) automatically change to the Run-as User after it has bound the necessary TCP and UDP ports, by setting the User value of the [Unix] section of the ctrl/sbbs.ini file.

Creating the Synchronet Directory

You must create the directory where Synchronet will live. Some common locations would be the home directory of the Run-as User (e.g. /home/sbbs/sbbs) or the system root directory (e.g. /sbbs).

By default, Synchronet executables will look for files in the /sbbs/ctrl directory, so if you install Synchronet into a different directory you will need to either create a symbolic link in your root directory (e.g. ln -s /home/sbbs/sbbs /) or set the SBBSCTRL environment variable accordingly.

The remaining steps assume that the current working directory is your Synchronet installation directory:

$ pwd


If a specific step below causes problems (e.g. displays an error message), click the highlighted text for more details including common causes of errors.


Choose a build method (using Git or Tarball)1):

Using Git

Quick installation from Git (requires 100+MB of disk space):

To get and build the latest code:

  • $ make install SYMLINK=1

Or, if you want to build a stable release from Git, specify a valid release tag on the make command-line (e.g. sbbs319b):

  • $ make install SYMLINK=1 TAG=sbbs3xxx
  • NOTE: this does not work with release tags earlier than sbbs319b, use the Tarball install method instead for those.


  • These commands will make and install a RELEASE build of the software. To make and install a DEBUG build instead, pass DEBUG=1 on the make command-lines.
  • We don't support parallel builds (e.g. make -j) - so don't do that.
  • On Linux systems, your user password will be prompted for to execute the sudo setcap command during install. If this is a problem, you can include NOCAP=1 on the make command-line to bypass that step.


If you installed with the SYMLINK=1 option, the resulting installation directory tree should look like this:

drwxrwx---  3 rswindell sbbs  4096 Sep 30 18:47 ctrl
lrwxrwxrwx  1 rswindell sbbs    30 Sep 30 18:47 docs -> /home/rswindell/sbbs/repo/docs
lrwxrwxrwx  1 rswindell sbbs    30 Sep 30 18:47 exec -> /home/rswindell/sbbs/repo/exec
-rw-rw----  1 rswindell sbbs 10641 Sep 30 19:04 GNUmakefile
drwxrwx---  2 rswindell sbbs  4096 Sep 30 18:47 node1
drwxrwx--- 14 rswindell sbbs  4096 Sep 30 18:37 repo
lrwxrwxrwx  1 rswindell sbbs    30 Sep 30 18:47 text -> /home/rswindell/sbbs/repo/text
lrwxrwxrwx  1 rswindell sbbs    29 Sep 30 18:47 web -> /home/rswindell/sbbs/repo/web
lrwxrwxrwx  1 rswindell sbbs    32 Sep 30 18:58 webv4 -> /home/rswindell/sbbs/repo/webv4/
lrwxrwxrwx  1 rswindell sbbs    30 Sep 30 18:47 xtrn -> /home/rswindell/sbbs/repo/xtrn

Due to the symbolic directory links (represented with -> arrows above), subsequent git pull operations (in the sbbs/repo directory) will automatically update the docs, exec, text, web, webv4, and xtrn directories. This means that any local changes (configurations or customizations) of files in those directories may need to be merged with any upstream changes later. Most configuration files are located in the ctrl directory so they are automatically excluded from any update/merge issues.


  • You can safely remove the installation GNUmakefile once successfully installed; it has served its purpose.


Alternatively, if you don't have a working Git client or are low on available disk space, you can use the following steps to install the latest nightly development build:

  1. $ tar -xzf sbbs_src.tgz
  2. $ tar -xzf sbbs_run.tgz
  3. $ echo RELEASE=1 > src/build/
  4. $ cd src/sbbs3
  5. $ SBBSEXEC=/sbbs/exec make symlinks2)
  6. $ SBBSCTRL=/sbbs/ctrl /sbbs/exec/jsexec update.js

If you want to build a stable release, replace the archive filenames above with valid release filenames:

  1. replace sbbs_src.tgz with ssrc318b.tgz
  2. replace sbbs_run.tgz with srun318b.tgz
Using System Libraries

On systems that are not properly supported by SpiderMonkey, you may be need to make use of a vendor supplied version. Doing so is not recommended or well supported, but it may be the only way to get Synchronet running on some platforms. The following steps have been reported to work on Debian Squeeze (6.0) armel (ARMv5te, EABI) on a Marvell Sheevaplug dev kit.

  1. $ apt-get install libmozjs185-dev
  2. Add JSINCLUDE=/usr/include/js JSLIB=mozjs185 to your make command line

On OpenBSD 5.5-current on 64-bit UltraSPARC:

  1. $ pkg_add -r spidermonkey-1.9
  2. $ ln -s /usr/local/lib/ /usr/local/lib/
  3. Add JSINCLUDE=/usr/local/include/js to your make command line.


  • The following error indicates that you failed to install the libncurses-dev (or libncursesw5-dev) prerequisite:
  fatal error: curses.h: No such file or directory
  • The following error indicates that you failed to install the libnspr4-dev prerequisite:
  configure: error: your don't have NSPR installed or your version is too old
  • Errors such as “C++ cannot create executables” and many others are generally caused by missing prerequisites.
  • The following errors occur when building the Mozilla JavaScript library (libmozjs), are normal and can be safely ignored:
  /bin/sh: 1: autoconf-2.13: not found
  GNUmakefile:52: recipe for target '../build/../../src/../3rdp/gcc.linux.x64.debug/mozjs/lib/libmozjs185-1.0.a' failed
  make[1]: [../build/../../src/../3rdp/gcc.linux.x64.debug/mozjs/lib/libmozjs185-1.0.a] Error 127 (ignored)
  • The following error indicates you specified a symlinks make target without the SBBSCTRL or SBBSEXEC environment variable set.
  make: *** No rule to make target 'symlinks'.  Stop.
  • The following error indicates you specified an install make target without the SBBSCTRL or SBBSEXEC environment variable set.
  make: *** No rule to make target 'install'.  Stop.
  • The following compilation error indicates that the wide character variant of the ncurses library has not been installed:
  error: unknown type name 'wint_t'
  • The following error indicates the Synchronet libraries (shared objects) are not in your system's library search path or in the directory from which sbbs was built. Set the LD_LIBRARY_PATH environment variable to point to your Synchronet exec directory to resolve:
  sbbs: error while loading shared libraries: cannot open shared object file: No such file or directory


Since both of the above installation methods create symlinks to (rather than copy) your Synchronet library and executable files from your Synchronet build directories to your Synchronet exec directory, you must not delete (or “clean”) your build directories or else Synchronet (e.g. sbbs) and its utilities will not run until you rebuild them.

Debug Builds

Both of the above build installation methods build a “release” (or non-debug) version of the Synchronet library and executable files. If you won't be using a debugger (e.g. gdb) to debug Synchronet (e.g. root-cause and report or fix bugs in the source code), then you probably should run the “release” binaries as they will be smaller and faster.

If you wish to build debug binaries, add DEBUG=1 to the make command-lines in the above steps.

Debug and release builds files are generated in separate output directories. If you created symlinks to your executables (i.e. specified SYMLINK=1 on the first make invocation) and switched between release and debug builds, you will need to remove or replace the symlinks in your Synchronet exec directory; this can be achieved using the symlinks build target of the src/sbbs3/GNUmakefile.

Graphical Utilities

Run make gtkutils in the src/sbbs3 directory to build the GTK utilities (e.g. gtkmonitor). Add the install or symlinks target to the command-line to get the GTK utilities symlinked or copied into your Synchronet exec directory.

JavaScript Library

As of October 8th, 2011, we are including the complete SpiderMonkey (JavaScript-C) library 1.8.5 source code in the Synchronet Source Repository (under 3rdp/dist) and the src/sbbs3/GNUmakefile will build it automatically. You should now not need to specify a JSLIB= value on your make command-lines.

JavaScript Issues for OpenBSD Users

Compiling of the 3rd party package providing mozilla's JavaScript support seems to need an extra flag passed to it, at least for OpenBSD 4.9-5.x running on i386. When doing the initial make, try it with EXTRA_JS_CONFIGURE_ARGS=–disable-tracejit to get the process a little further along.

Build System

The make-based build system is a complex and magical beast. Changing it's behaviour though environment variables such as CFLAGS or twiddling the various undocumented knobs is not supported. If you do fiddle with the knobs and something breaks, you will be expected to support yourself regarding these changes... ie: the answer you are likely to get from the devs is “don't do that then”. Partial documentation can be found here: options

Third Party Builds

Some third parties make unsupported tarballs available from their own sites. Using them is not recommended or supported. Whenever possible you should build yourself.

OS Platform Provided By Date Archive
Debian 9.1 (stretch) amd64 digital_man Every morning (PT) sbbs_dev.tgz sbbs_run.tgz


See nix for more details on configuring the Synchronet initialization file (ctrl/sbbs.ini) for Unix/Linux.


Choose one mode (Console or Daemon):

Console Mode

You can manually run the Synchronet sysop console (somewhat interactive, but not usually preferred):

Most of what is displayed in the console is not logged to disk in this mode.

You have some monitoring and control options from the console command prompt. Hit ? for a menu of available commands (e.g. Q to quit, stopping Synchronet).

Daemon Mode

You can install Synchronet to run as a daemon (background service, usually preferred).

You must be 'root' to install daemons on Unix/Linux.

Linux (System V Init style)

  1. # cd /etc/init.d
  2. # chmod +x sbbs
  3. # /etc/init.d/sbbs start

See syslog, umonitor, gtkmonitor and node for details on options for monitoring the Synchronet daemon while it's running in the background:

# /etc/init.d/sbbs status
Synchronet BBS services status: [running]
PID(s): 25171
Red Hat

If using a Red Hat based Linux (e.g. Fedora), you may need to add the Synchronet system service to your startup configuration for the sbbs daemon to start automatically during system startup:

# chkconfig --add sbbs
Debian (systemd)

Modern Debian-based Linux systems use systemd to start and control system services (daemons). See systemd for detailed instructions on configuring Synchronet as a daemon that is started automatically and controlled via systemd.

Debian (SysVinit)

If using an older Debian-based Linux which still uses a SysV/init.d daemon/service control system, you should use either of the following methods to add the Synchronet system service to your startup configuration for the sbbs daemon to start automatically during system startup:

# insserv -v sbbs


# update-rc.d sbbs enable 2 3 4 5


1) Get the Synchronet service run script (init file) from here.

2) Copy the run script (sbbs) into your /usr/local/etc/rc.d directory

3) Set up the sbbs settings: In one of /etc/rc.conf, /etc/rc.conf.local, or /etc/rc.conf.d/sbbs, add the line:

 sbbs_enable=YES      # Required to run Synchronet

4) In one of the files from step three, add appropriate lines from the following (Defaults are shown here):

 sbbs_flags=""                        # Additional command-line flags
 sbbs_pidfile="/var/run/"     # Path of pid from your .ini
 sbbs_dir="/sbbs/"                    # Root sbbs path
                                      # The rest of the sbbs_*dir derive
                                      # from this be default
 sbbs_program="${sbbs_execdir}/sbbs"  # Synchronet binary
 sbbs_procname="${sbbs_program}"      # Process name as seen by ps(1)
 sbbs_shell="/bin/sh"                 # SHELL variable
 sbbs_user="root"                     # User to START sbbs as.  If this is
                                      # not root, you cannot bind low ports
 sbbs_group="wheel"                   # Group to start sbbs as

5) Start the Synchronet system service (FreeBSD 5.x+):

# /usr/local/etc/rc.d/sbbs start

Terminal Capabilities

As you may have noticed by now, most telnet clients designed for use with ANSI BBSes do not display full-screen Unix programs correctly. Included with Synchronet is a pair of terminal capability definition files that enable you to run native full-screen Unix programs and have the output displayed correctly in a standard ANSI-BBS terminal. These files are termcap and terminfo, located in your Synchronet install directory. Your system will use one or the other, and it won't hurt to install both. You will need to be logged in as root to install the files.

Installing the terminfo file

1) Get the Synchronet ANSI-BBS terminfo file from here.

2) Enter the command:

# tic terminfo

Installing the termcap file

1) Get the Synchronet ANSI-BBS termcap file from here.

2) Enter the command:

# cat termcap >> /etc/termcap

3) FreeBSD Only run the command:

# cap_mkdb -f /usr/share/misc/termcap /etc/termcap

Once the terminal capability files are installed, edit the ExternalTermANSI value in the [BBS] section of your sbbs.ini file to read:


Note: The default value of the ExternalTermANSI sbbs.ini key is pc3. If you get an error Unknown terminal: pc3 from external programs, it means that this key value has not been set to a valid terminal type.

Note: Once again, many Linux distros do not have a termcap. This is fine. You do NOT need to install the termcap-compat package. If termcap isn't installed, it means nothing uses it. Only if there is a termcap do you need to add the ansi-bbs termcap definition.

A note on SysOp paging

For most systems, the BBS must either have write access to the sound card via /dev/dsp, or run as root to page the SysOp. FreeBSD supports an alternative method which requires one of the following:

On FreeBSD 5.x and higher

One of:

  1. A custom kernel with the following option in the config device speaker
  2. The speaker module loaded by either:
    1. Running kldload speaker
    2. The line speaker_load=“YES” in /boot/loader.conf file

/dev/speaker should be read/writeable by the user the BBS runs as.


Updating/synchronizing the source files:

1. If you already have the Synchronet Git repository cloned to your local system, fetch and merge any upstream changes:

$ git -C /sbbs/repo pull

Or If you do not already have the Git repository cloned, clone it to your sbbs/repo directory:

$ git clone /sbbs/repo

Or download the latest source code and 3rd party library files and extract into your sbbs/repo directory tree:

$ mkdir /sbbs/repo; cd /sbbs/repo
$ wget
$ tar -xzf sbbs_src.tgz

2. Rebuild Synchronet (replace symlinks with install if you prefer to copy executable and library files to your exec directory):

$ cd /sbbs/repo/src/sbbs3; make RELEASE=1 symlinks

Or if you're using setcap to start sbbs as a Linux non-root user:

$ cd /sbbs/repo/src/sbbs3; make RELEASE=1 setcap symlinks

:!: If you get the error no rule to make target 'symlinks' or 'install', this is an indication that you do not have either the SBBSCTRL or SBBSEXEC environment variable set

3. Perform the steps listed here to update the run-time files (e.g. text.dat).

4. Shutdown and re-run sbbs (when daemonized):

$ systemctl restart sbbs


$ service sbbs restart


$ /etc/init.d/sbbs restart 

Clean Rebuild

Occasionally, you may need to perform a clean rebuild. A clean build can generally be achieved by going to the src/ directory and executing:


If you elect to build debug binaries (instead of release binaries), then you'll need to exclude the RELEASE=1 portion from the command. Otherwise, you'll be cleaning the *.release output directories when you really need to be cleaning the *.debug output directories. Likewise, if you're building and running release binaries, then you need to include the RELEASE=1 portion on the commands as well. Alternatively, you can set your default build type in the file The file should be created by you in either in the src/build directory (to apply to all builds), or within each directory you run make:


Now that you've completed the installation, move on to the initial setup instructions.

See Also

The Git install method is preferred/recommended
include the 'setcap' target if you intend to use Linux-capabilities to bind low ports

In Other Languages
Translations of this page: