Skip to main content

Authentication and User Management

In the context of Fusion File Share Server, authentication is the process of verifying the identity of a user attempting to initiate an SMB session to access shares. This should not be confused with authorization, a process for determining which resources an authenticated user can access, and with what permissions.

This section covers the various methods of authenticating and managing users, their configuration, and their suitability for different use cases and environments. It also explains how Fusion File Share Server maps SMB users to UNIX users.

Authentication Methods​

The following are the authentication methods supported by Fusion File Share Server, and the considerations for choosing each:

  • File-Backed User Database:

    The file-backed user database is a text file located on your Fusion File Share Server's file system that stores usernames and password hashes for users managed entirely by Fusion File Share Server. Managing users in a locally-stored file is useful in environments without centralized user management, such as Active Directory or LDAP, or when granting access to additional users (e.g., UNIX users or a guest account).

    When Fusion File Share Server is configured to use LDAP, it uses NTLM for authentication.

    You would typically use the file-backed user database in the following scenarios:

    • Environments without centralized user management:
      If you're operating in an environment without centralized user management, such as small offices or organizations without Active Directory or LDAP, but still require rudimentary user management.

    • Isolated or edge environments:
      If you're setting up an isolated environment where "users" are primarily automated processes, operating in a location that might not have access to your Active Directory.

    • Allowing SMB access to UNIX users:
      In a predominantly UNIX environment, without Active Directory, you may need to add an SMB-compatible authentication layer to allow local UNIX (e.g., Linux or macOS) users to access your shares via SMB.

    • Allowing guest account access:
      If you want to enable guest account access to your shares.

    When the user tries to access Fusion File Share Server—such as by navigating to a UNC address on a Windows machine, or performing an SMB mount from a UNIX machine—they must provide a username and a password. When configured to use the file-based user database, Fusion File Share Server itself provides the SMB authentication layer, and will attempt to validate the user's password only against the password hash stored in it (unless other user database types are specified).

  • Active Directory:

    Microsoft Active Directory is a directory service that provides authentication and authorization services, primarily for Windows-based systems. It is a centralized platform that stores information about users, groups, and computers within a network, allowing administrators to efficiently manage access to resources.

    Most organizations with Windows environments rely on Active Directory for user authentication and authorization. Fusion File Share Server integrates seamlessly with Active Directory to validate user identities, secure their access to shares, and enable users to access shares from their Windows devices without disruption.

    You would typically use Active Directory integration when operating in a Windows domain environment. This allows users to access SMB resources using their Windows domain credentials or directly from their Windows sessions.

    When a user attempts to access Fusion File Share Server, such as by navigating to a UNC address on a Windows machine, Fusion File Share Server will use the Kerberos protocol to authenticate the user's identity:

    1. The user's credentials are sent to the domain controller, which validates them against the Active Directory database.
    2. If the credentials are valid, the domain controller issues a Ticket Granting Ticket (TGT) to the user's machine. The user's machine then uses the TGT to request a service ticket for Fusion File Share Server.
    3. The user's machine then sends the service ticket to Fusion File Share Server, which decrypts it using the the host key that were obtained when the server was joined to the domain, and validates it.
    4. If the service ticket is valid, the user is authenticated, and Fusion File Share Server proceeds to authorize access the requested resource.

  • LDAP:

    LDAP (Lightweight Directory Access Protocol) is an open standard protocol used to access and manage directory services over a network. It is typically used to centrally manage user accounts, groups, and other objects such as computers and printers.

    While Microsoft Active Directory is also LDAP-based, there is typically a distinction between it and "other LDAP" implementations. Active Directory is primarily used in Windows environments, while other LDAP implementations, such as OpenLDAP, are more generic and commonly used in non-Windows environments for centralized user management.

    When Fusion File Share Server is configured to use LDAP, it uses NTLM for authentication.

    You would typically use LDAP integration in a Linux or macOS environment with an LDAP directory (other than Active Directory) when you want to allow users to access SMB resources.

  • Apple Open Directory:
    Fusion File Share Server supports authentication against Apple Open Directory.

Configuration​

Choosing the Authentication Method(s)​

The authentication method(s) are set in the [global] section of the configuration file. The userdb_type parameter defines the user database types that Fusion File Share Server will use for authentication, with additional parameters that are specific to the chosen user database type.

Global Parameter User Database Types
This parameter is required.

Fusion File Share Server will fail to start unless a value is specified.

Value Type: string

Value Format: <type>[,<type>][,<type>]
Where <type> is one of:

  • ad: Use Active Directory. This requires the domain parameter to be configured.
  • aod: Use Apple Open Directory. This requires the domain parameter to be configured.
  • text: Use the file-backed user database. This requires the userdb_file to be configured.
  • ldap: Use LDAP. This requires all the ldap_* parameters to be configured.

Default Value: none

Proceed to the following sections to learn how to configure each authentication method.

File-Backed User Database​

To enable the file-backed user database, you need to:

  1. Set text as (one of) the user database types in the global configuration:

    If you only want to use the file-backed user database, set the userdb_type in the [global] section to text:

    [global]
    . . .
    userdb_type = text
    . . .
    [/global]

    If you want to enable the file-backed user database in addition to Active Directory or another authentication source, add it to the existing value. For example:

    [global]
    . . .
    userdb_type = ad,text
    . . .
    [/global]

  2. Set the path to the file where the database will be stored:

    Global Parameter Path to the File-Backed User Database

    Value Type: string

    Value Format: <path>
    Where <path> is the path of the file-backed user database file. The file needs to exist before the starting Fusion File Share Server.

    danger

    The file-backed user database must be properly secured, since it contains password hashes. Some ways of securing it include:

    • Store it in a directory that is not accessible to non-privileged users.
    • Set appropriate permissions on the file to limit access (e.g., chmod 600 <path>).
    • Store it on an encrypted file system.

    Example:

    • /etc/tsmb-shadow would configure Fusion File Share Server to use /etc/tsmb-shadow as the file-backed user database file.

    Set the userdb_file parameter to the path of the file where you want your file-backed user database to be stored:

    [global]
    . . .
    userdb_type = text
    userdb_file = /etc/tsmb-shadow
    . . .
    [/global]
    warning

    The file must exist before starting Fusion File Share Server.

    important

    If you're using Fusion File Share Server in a clustered configuration, the file-backed user database file must be located on the shared storage.

  3. Initialize the database by creating an empty file at the specified path:

    Before starting the Fusion File Share Server for the first time with the file-backed user database enabled, make sure to initialize the file at the specified path. For example, if the file is at /etc/tsmb-shadow:

    sudo touch /etc/tsmb-shadow

To learn how to manage the users in the file-backed user database, see the Managing Local Users section below.

Active Directory​

To configure Fusion File Share Server to use Active Directory, you need to:

  1. Join the machine to the domain:
    Before you can configure Fusion File Share Server to use Active Directory, you need to join the machine to the domain. For a step-by-step guide on how to join your machine to a domain, see Howto > Active Directory Integration > Joining the Domain and Adding UPN.
  2. Configure Fusion File Share Server to use Active Directory:
    Set ad as (one of) the user database types in the global configuration, and configure the Active Directory settings – the domain name and the server name:
    Global Parameter Active Directory Domain Name

    Value Type: string

    Value Format: <domain>
    <domain>: specifies the name of the Active Directory domain (or in rare cases, Apple Open Directory domain). It should be a fully-qualified domain name (e.g., acme.local).

    Default Value: none.

    Examples:

    • acme.local specifies the Active Directory domain acme.local.
  3. (Optional) Set the Domain Controller Server Name(s):
    In rare cases, such as when Fusion File Share Server is member of multiple domains, but only some domains can be used for SMB user authentication, you can set the domain controller server name(s) in the global configuration.
    Global Parameter Domain Controller Server Name(s)

    Value Type: string

    Value Format: [<server>[,<server>,...]]
    If specified, the value should be in square brackets ([...]), containing comma-separated values <server>, where each <server> is a domain controller server name.

    Default Value: none. Fusion File Share Server will automatically discover domain controller server names by querying the DNS for the _ldap._tcp SRV records.

    Examples:

    • [dc1.acme.local, dc2.acme.local] will use the domain controller server names dc1.acme.local and dc2.acme.local to authenticate SMB users.

If you want to use only Active Directory as the user authentication backend, set the value of userdb_type in the [global] section to ad, the value of domain to your Active Directory domain, and optionally the value of server_name to the name of your server:

[global]
. . .
userdb_type = ad
domain = acme.local
server_name = fusion-srv
. . .
[/global]

If you want to enable the file-backed user database in addition to Active Directory or another authentication source, add it to the existing value. For example:

[global]
. . .
userdb_type = ad,text
domain = acme.local
server_name = fusion-srv
. . .
[/global]

LDAP​

To configure Fusion File Share Server to use LDAP, in addition to setting the userdb_type to ldap, you must set values for all of the following parameters:

Global Parameter LDAP URI

Value Type: string

Value Format: <uri>

  • <uri>: the LDAP server URI.

Default Value: none

Examples:

  • ldap://ldap.acme.com: the LDAP server URI, without encryption.
  • ldaps://ldap.acme.com: the LDAP server URI, with TLS encryption.
important

If TLS is used, ensure that the system's certificate store contains the proper certificate chain to validate the LDAP server's certificate.

Global Parameter LDAP Bind DN

Value Type: string

Value Format: <dn>

  • <dn>: The distinguished name (DN) of the user account that has access to the NT hashes for the users.

Default Value: none

Examples:

  • cn=admin,dc=acme,dc=com: The user is admin in the acme.com domain.
Global Parameter LDAP Base DN

Value Type: string

Value Format: <dn>

  • <dn>: The distinguished name (DN) of the organization unit (OU) that contains the users.

Default Value: none

Examples:

  • ou=people,dc=acme,dc=com: The users are in the people OU in the acme.com domain.
Global Parameter LDAP Bind Password

Value Type: string

Value Format: <password>

  • <password>: The password for the user specified in the ldap-bind-dn parameter.

Default Value: none

Global Parameter LDAP Username Attribute

Value Type: string

Value Format: <attr>

  • <attr>: The name of the attribute that contains the users' username.

Default Value: none

Examples:

  • username: The username is stored in the username attribute.
Global Parameter LDAP NT Hash Attribute

Value Type: string

Value Format: <attr>

  • <attr>: The name of the attribute that contains the NT hash for the users. For most configurations, the value should be sambaNTPassword.

Default Value: none

Examples:

  • sambaNTPassword: The NT hash is stored in the sambaNTPassword attribute.
Global Parameter LDAP Timeout

Value Type: integer

Value Format: <seconds>

  • <seconds>: The number of seconds to wait for an LDAP operation to complete before timing out.

Default Value: none

Examples:

  • 30: Wait 30 seconds for an LDAP operation to complete before timing out.

The following example shows how to configure Fusion File Share Server to use LDAP as the user authentication backend:

[global]
. . .
userdb_type = ldap
ldap_uri = ldap://ldap.acme.com
ldap_bind_dn = cn=admin,dc=acme,dc=com
ldap_bind_pw = itsasecret
ldap_base_dn = ou=people,dc=acme,dc=com
ldap_username_attr = username
ldap_nthash_attr = tsmbNTHash
ldap_timeout = 30
. . .
[/global]

In the example above:

  • The LDAP server is at ldap://ldap.acme.com.
  • The bind DN is cn=admin,dc=acme,dc=com.
  • The bind password is itsasecret.
  • The base DN for the user search is ou=people,dc=acme,dc=com.
  • The username attribute is username.
  • The NT hash attribute is tsmbNTHash.
  • The LDAP timeout is set to 30 seconds.

Apple Open Directory​

To configure Fusion File Share Server to use Apple Open Directory, you need to:

  1. Allow anonymous LDAP bind to the Apple Open Directory LDAP server:
    Fusion File Share Server attempts to bind to the Apple Open Directory LDAP server anonymously. If your Apple Open Directory server does not support anonymous bindings, Fusion File Share Server will fail to start.
  2. Ensure Fusion File Share Server can find the Apple Open Directory LDAP server:
    By default, Fusion File Share Server attempts to resolve the Apple Open Directory LDAP server using DNS SRV records.If your Apple Open Directory server is not accessible via DNS, you must manually configure the LDAP settings.
  3. Configure the Kerberos CIFS SPN in your keytab file:
    To allow Fusion File Share Server to authenticate users with Apple Open Directory, generate a key on your Apple Open Directory server for the CIFS service, and add it to your /etc/krb5.keytab file.
  4. Configure Fusion File Share Server to use Apple Open Directory:
    Set aod as (one of) the user database types in the global configuration, and configure the domain name and the server name:
    Global Parameter Apple Open Directory Domain Name

    Value Type: string

    Value Format: <domain>
    <domain>: specifies the name of the Active Directory domain (or in rare cases, Apple Open Directory domain). It should be a fully-qualified domain name (e.g., acme.local).

    Default Value: none.

    Examples:

    • acme.local specifies the Active Directory domain acme.local.
note

Apple Open Directory only supports the NSS method for POSIX ID mapping.

If you want to use only Apple Open Directory as a user authentication backend, set the userdb_type in the [global] section to aod, and set the domain to your Apple Open Directory domain:

[global]
. . .
userdb_type = aod
domain = acme.local
. . .
[/global]

If you want to enable the file-backed user database in addition to Apple Open Directory or another authentication source, add it to the existing value. For example:

[global]
. . .
userdb_type = aod,text
domain = acme.local
. . .
[/global]

Managing Local Users​

When using the file-backed user database, you can manage users by using the tsmb-passwd command. This command allows you to add, modify, delete, disable, and enable users, as well as to set or change their passwords. User records are stored in a text file specified in the global userdb_file parameter.

The Structure of the File-Backed User Database​

The file-backed user database is a text file containing user records. Each record is a single line with the following fields, separated by colons (:):

  1. Username:
    The username of the user.
  2. NTLM Password hash:
    The user's password in MD4 hash form. If the user has no password, thise field is empty.
  3. Disabled flag:
    A flag indicating whether the user is disabled. If the user is disabled, the field contains the value d; otherwise, it's empty.
  4. Fusion File Share Server user ID:
    The user's Fusion File Share Server user ID, not to be confused with the UNIX user ID (UID). This field is for internal use and should not be modified by the user.
  5. POSIX ID mapping username:
    The username of the UNIX user to which the Fusion File Share Server user is mapped. If this field is empty, the user will be mapped to the UNIX user corresponding to the Fusion File Share Server user ID in the previous field.

Examples:

  • In the following record for a user named johndoe:

    johndoe:64f92a7257f6e6e48d2be10daa793463::1005:
    • The username is johndoe.
    • The password hash is 64f92a7257f6e6e48d2be10daa793463.
    • The user is enabled (the disabled flag is empty).
    • The Fusion File Share Server user ID is 1005.
    • The user is not explicitly mapped to a UNIX user, so it will be mapped to the UNIX user with the UID 1005.

  • In the following record for a user named janedoe, who is disabled:

    janedoe:64f92a7257f6e6e48d2be10daa793463:d:1006:smbuser
    • The username is janedoe.
    • The password hash is 64f92a7257f6e6e48d2be10daa793463.
    • The user is disabled (the disabled flag is d).
    • The Fusion File Share Server user ID is 1006.
    • The user is explicitly mapped to the UNIX user smbuser, whose UID will be used for the user's files.

Adding a User​

After configuring the file-backed user database, you can add a user by using the tsmb-passwd command.

For example, to add a user named johndoe, use the -a switch to add a user:

sudo tsmb-passwd -a johndoe

The example above assumes that your configuration file is at /etc/tmsb.conf. However, if your configuration file is in a different location (e.g., /mnt/shared/tsmb.conf), use the -c switch:

sudo tsmb-passwd -a johndoe -c /mnt/shared/tsmb.conf

Alternatively, if you want to supply the password in a form of an MD4 hash, add the -H flag:

sudo tsmb-passwd -a -H johndoe

Disabling and Re-Enabling a User​

To revoke user's access to Fusion File Share Server shares, you can disable the user. Once disabled, the user can be re-enabled to regain access.

To disable a user, use the -d switch:

sudo tsmb-passwd -d johndoe

To re-enable a previously disabled user, use the -e switch:

sudo tsmb-passwd -e johndoe

POSIX ID Mapping​

Since Fusion File Share Server is designed to behave as a Windows file server, it authenticates users against its file-backed user database or external sources such as Active Directory. However, because the shares are backed by a UNIX file system, the files and directories created by users are owned by UNIX users and groups.

POSIX ID mapping, when enabled, maps authenticated SMB users to corresponding UNIX users and groups (UIDs and GIDs). This ensures that files created on a share are owned by the UNIX user mapped to the SMB account.

note

In Fusion File Share Server, POSIX ID mapping is optional and can be left unconfigured unless specifically required for your use case.

If ID mapping is not enabled, files and directories created by users will be owned by the UNIX user and group under which the Fusion File Share Server server is running as (typically root). In these cases, file access authorization is managed through Windows ACLs.

ID Mapping Methods​

Fusion File Share Server supports multiple methods for mapping SMB users to UNIX users, which are explored in this section.

System Name Service Switch (NSS)​

The default method for ID mapping is the system's Name Service Switch (NSS), which attempts to match the SMB user to a UNIX user through a username lookup in the databases defined in the /etc/nsswitch.conf file.

The username lookup follows these rules:

  • If using the file-backed user database, the username is matched to the UNIX user with the same username, unless explicitly mapped to another UNIX user.
  • If using Active Directory, it is assumed that the user database defined in the /etc/nsswitch.conf file is set up to query the Active Directory. Typically this is done by setting the passwd and group databases to files sss, which will leverage the System Security Services Daemon (SSSD) to query the Active Directory as follows:
    • If SSSD is configured with the following parameters in /etc/sssd/sssd.conf: 
      . . .
      ldap_id_mapping = True
      ldap_schema = ad
      . . .
      SSSD maps the Active Directory user to a UNIX user based on the user's objectSID attribute, which is part of the user's Security Identifier (SID).
    • If SSSD is configured with the following parameters in /etc/sssd/sssd.conf: 
      . . .
      ldap_id_mapping = False
      ldap_schema = rfc2307bis
      . . .
      SSSD maps the Active Directory user to a UNIX user based on the user's uidNumber attribute, as defined in the RFC 2307bis schema.

RFC 2307 Schema​

The RFC 2307bis schema is a standard schema for representing UNIX users and groups in an LDAP directory. When using the RFC 2307 schema for ID mapping, Fusion File Share Server maps the SMB user to a UNIX user based on the uidNumber attribute of the user's LDAP entry.

Fusion File Share Server can be configured to query Active Directory either directly, or through NSS, to use the RFC 2307 schema for ID mapping. When querying Active Directory directly, this ID mapping method can be scoped to a specific domain.

Dynamic Mapping Based on the RID​

With the RID method for ID mapping, Fusion File Share Server maps the SMB user to a UNIX user based on the Relative Identifier (RID) portion of the user's Security Identifier (SID). This method is useful in environments with multiple trusted domains, allowing user mapping from these domains to UNIX users based on their RIDs.

The RID is contained in the last part of the SID, after the last hyphen:

S-1-5-21-3623811015-3361044348-30300820-10133
\_____________________________________/ \___/
              Domain SID                 RID

When using the RID method for ID mapping, you can optionally specify the domain to which the ID mapping is scoped, and the range of UIDs to use for mapping. If the domain is not specified, the ID mapping defaults to the domain of the Fusion File Share Server server as set in the domain parameter.

Configuring the ID Mapping Method​

To configure the ID mapping method, set the userdb_idmap.

Global Parameter ID Mapping Method

Value Type: string

Value Format: <method>[,<method>,...]
Where <method> is one of the following:

  • nss: Specifies that the ID mapping is performed using the system Name Service Switch (NSS), as defined in the /etc/nsswitch.conf file. This is the default method. When using nss, other methods cannot be specified.
  • rfc2307[:<domain>]: Specifies that the ID mapping is performed using the RFC 2307 schema. Optionally, you can specify the <domain> to scope the ID mapping to a specific domain.
  • rid:[<domain>]:<uid_min>[:<uid_max>]: Indicates that the ID mapping is done dynamically based on the RID portion of the user's SID:
    • If <domain> is specified, the ID mapping is scoped to that domain.
    • <uid_min> and <uid_max> define the range of UIDs to use for the mapping. If <uid_max> is not specified, the range extends from <uid_min> to the maximum UID value.
    • <uid_max> is required when multiple trusted domains are specified.

Default Value: nss.

Examples:

  • nss specifies that the ID mapping is done using the system Name Service Switch (NSS).
  • rfc2307:acme.local specifies that the ID mapping is done using the RFC 2307 schema.
  • rid:acme.local:1000:1999,rid:example.com:2000:2999 specifies dynamic ID mapping based on the the RID portion of the user's SID, with the UID range of 1000 to 1999 for the acme.local domain, and 2000 to 2999 for example.com.

As mentioned above, the default method for ID mapping is the system Name Service Switch (NSS). Therefore, if your server is part of a domain, and you're using Active Directory as the user authentication backend, you don't need to configure the userdb_idmap parameter.

For example, to configure Fusion File Share Server to use the RFC 2307 schema for ID mapping, set the userdb_idmap parameter to rfc2307:

[global]
. . .
userdb_idmap = rfc2307
. . .
[/global]

To configure Fusion File Share Server to use the RID method for ID mapping for users with UIDs above 1000, set the userdb_idmap parameter to rid::1000::

[global]
. . .
userdb_idmap = rid::1000:
. . .
[/global]

ID Mapping for File-Backed User Database​

Default ID Mapping Behavior​

When using the file-backed user database, Fusion File Share Server maps SMB users to UNIX users as follows:

If a user with the same name already exists in the UNIX user databases (as defined in /etc/nsswitch.conf), the SMB user is mapped to that UNIX user. For example, if the UNIX user johndoe already exists, and you create a Fusion File Share Server user johndoe, the Fusion File Share Server user johndoe is mapped to the UNIX user johndoe.

You can observe this by cross-referencing the output of id johndoe and sudo grep johndoe /etc/tsmb-shadow (or the path specified for the file-backed user database):

  1. Create the SMB user and set the password for them: Run the following command:

    sudo tsmb-passwd -a johndoe

    Type and confirm the password for the user:

    New SMB password: 
    Retype SMB password:

  2. Check their UNIX user ID:

    id johndoe

    The output should resemble:

    uid=1005(johndoe) gid=1005(johndoe) groups=1005(johndoe)

  3. Lookup the user in the file-backed user database:

    sudo grep johndoe /etc/tsmb-shadow

    The output should resemble:

    johndoe:64f92a7257f6e6e48d2be10daa793463::1005:

In the example above, you can see that the user johndoe is assigned the UID 1005, both in the UNIX user database and in the file-backed user database.

If the user doesn't exist in the UNIX user databases, tsmb-passwd will create a record for the user in the file-backed user database, and assign a Fusion File Share Server user ID, starting from 1000. The Fusion File Share Server user ID will increment for each new user created, unless the username created matches an existing UNIX user (except in rare cases where the assigned Fusion File Share Server user ID is already taken by another user in the file-backed user database).

This may lead to situations wherein SMB users are mapped to non-existent UNIX users. This is acceptable, as long as there is no need to examine or determine file ownership from the UNIX side (e.g., by running ls -l). In this case, the files created by these users will be owned by the user running Fusion File Share Server (usually root).

Explicit POSIX ID Mapping​

To explicitly map a Fusion File Share Server user to a UNIX user, use the tsmb-passwd command with the -z switch, whether adding a new user or modifying an existing one. In the following examples, the user johndoe is mapped to the UNIX user smbuser:

When adding a new new user:

sudo tsmb-passwd -a johndoe -z smbuser

When modifying an existing user:

sudo tsmb-passwd -z smbuser johndoe

Requiring POSIX ID Mapping for Authentication​

You can require that all users logging in via SMB to your Fusion File Share Server server are mapped to UNIX users. This can be useful if you want to be able to determine the file ownership from the UNIX side, or enforce the file permissions for users. If the requirement is enabled, Fusion File Share Server will deny access to all users that do not have a valid UNIX user mapped to them.

Global Parameter Require POSIX ID Mapping for Authentication

Value Type: boolean

Value Format: true|false

  • true: Requires all users to have a valid POSIX ID mapping.
  • false: Allows all SMB users to connect, regardless of POSIX ID mapping.

Default Value: false

Guest Account Access​

The Guest account is a special local account in Windows, commonly used to grant access to shared resources for users who are unknown to the server. This account allows access without requiring a password (or with an empty password).

Fusion File Share Server supports creating a local guest account and allows guest access to shares on the server. However, access is still subject to the permissions set for each share.

warning

Enabling guest access can be a security risk, and is not recommended beyond testing purposes.

Furthermore, Microsoft discourages the use of guest accounts:

  • The built-in guest account is disabled by default in Windows.
  • Windows 10, Windows Server 2019, and later versions do not allow use of guest authentication by default even when the guest account is enabled.
  • Windows 11 24H2, Windows Server 2025, and later versions require SMB Message signing by default, which prevents guest authentication. 

Since the Guest account is a local account in Windows and Fusion File Share Server follows standard Windows behavior, guest access requires creating a local file-backed user database, and configuring a guest account within it. Once guest access is enabled, any unknown user will be treated as a guest by Fusion File Share Server and authenticated using the guest account's password (if one is set).

The feature is controlled by the global allow_guest parameter.

Global Parameter Allow Guest Access

Value Type: boolean

Value Format: true|false

  • true: Enables guest access.
  • false: Disables guest access.

Default Value: false

Enabling Guest Access​

First, ensure that a file-backed user database exists. If you typically authenticate users against an Active Directory domain, you can add a local user database by appending ,text to your current userdb_type value. Specify the path for the local user database with the userdb_file parameter. Finally, enable guest access by setting the allow_guest parameter to true:

[global]
...
userdb_type = ad,text
userdb_file = /etc/tsmb-shadow
allow_guest = true
...
[/global]

In the example above, Fusion File Share Server is configured to authenticate against Active Directory, and also against a local user database stored in /etc/tsmb-shadow. But at this point, no local guest account has been created yet, so guest access will not yet work.

Now, create a guest account in the local user database using the tsmb-passwd command. Since the guest account is special, created it with the -G flag, instead of specifying a username:

sudo tsmb-passwd -a -G

You will be prompted to set and confirm the password for the guest account. You can either set a password, or leave it empty by pressing Enter.

At this point, any unknown user (i.e., a user not in any of the user databases–in this example, Active Directory and a local file) will be treated as a guest.

However, since the account hasn't been explicitly mapped to any UNIX user, Fusion File Share Server will attempt to map this user's activities to a UNIX guest account. If such account doesn't exist, you may want to map the guest user to the nobody account, which is a rough equivalent of the Windows Guest account, and is predefined on most Linux systems (see POSIX ID Mapping for more information):

sudo tsmb-passwd -z nobody -G

Disabling and Re-Enabling Guest Access​

Once configured, you can disable guest access without restarting Fusion File Share Server by disabling the guest account with the tsmb-passwd command:

sudo tsmb-passwd -d -G

To re-enable guest access, simply re-enable the guest account:

sudo tsmb-passwd -e -G