Skip to main content

SMB Features and Settings

Access Control Lists (ACLs) Storage​

In Windows environments, Access Control Lists (ACLs) define the permissions that users and groups have on files and directories. When a user creates a new file or directory, Windows assigns it a default set of permissions, which can then be modified to allow or deny access to specific users or groups.

When a user attempts to access a file or directory, Windows checks its ACL and the ACLs of parent directories to determine whether the user has the necessary permissions to perform the requested operation. If the required permissions are missing, access is denied.

In standard Windows environments, ACLs are stored as part of the NTFS file system.

Since Fusion File Share Server operates in a Linux environment, where the shared file system may not support ACLs natively, Fusion File Share Server offers multiple mechanisms to store Windows Access Control Lists (ACLs) regardless of the underlying file system. ACL storage mechanisms can be configured on a per-share basis.

Share Parameter ACL Storage Mechanism

Value Type: string

Value Format: <method>[,<method>,...]

  • Values are separated by ,.

  • A <method> can be one of the following:

    • xattr[:<variant>]: Store the ACLs in a dedicated extended attribute. Optional argument <variant> specifies the name of the extended attribute and the format used to save the ACLs:
      • raw: Use the self-relative security descriptor in Fusion File Share-specific extended attribute user.tsmb.$sd (default).
      • v3: Use version 3 of the Samba extended attribute security.NTACL without duplication in POSIX ACL.
      • v4: Use version 4 of the Samba extended attribute security.NTACL without duplication in POSIX ACL.
    • native: Store the ACLs natively on the file system, if supported. Use this option if the underlying file system is NTFS, or another private VFS module that supports these attributes.
    • posix-acl[:map_full_control]: Attempt to convert Windows ACLs to POSIX ACLs with best-effort mapping. If map_full_control is specified, the rwx permission bits are mapped to Full Control.

Default Value: xattr:raw

Examples:

  • xattr:raw: Stores the ACLs in the default Fusion File Share-specific extended attribute.
  • native: Stores the ACLs natively on a supported file system.

Setting Up ACL Storage for a Share Using the Configuration File​

In the relevant[share] section of the configuration file, set the map_acls parameter to the desired value, as shown in the following example:

[share]
netname = MyShare
path = /export/share
map_acls = xattr:raw
[/share]

Adding a Share with ACL Storage Using the Command Line​

When adding a share using the command line, specify the ACL storage method using the map-acls parameter. For example:

sudo tsmb-cfg share add -n MyShare -p /export/share --map-acls xattr:raw

Administrative Shares​

Administrative shares, such as C$ and D$, are special hidden shares representing the root of a drive on a Windows machine. These shares are only accessible to members of the Administrators group.

In Fusion File Share Server, you can designate a share as administrative to simulate this behavior and potentially use it as a root for other shares.

Share Parameter Designating a Share as Administrative

Value Type: boolean

Value Format: true|false

  • true: Designates share as an administrative share.
  • false: Makes it a regular share.

Default Value: false

important

When designating a share as an administrative share, the netname parameter MUST be set to a single English letter followed by $ (e.g., C$, D$, etc.)

Additionally, the only other acceptable parameters for administrative shares are path and remark.

Setting Up an Administrative Share Using the Configuration File​

In the relevant[share] section of the configuration file, set the administrative parameter to true and configure the netname parameter with the desired administrative share name, as shown in the following example:

[share]
netname = C$
path = /mnt/drive-c
administrative = true
remark = Administrative share for drive C
[/share]

Adding an Administrative Share Using the Command Line​

When adding an administrative share using the command line, specify the administrative parameter and the netname parameter. For example:

sudo tsmb-cfg share add -n 'C$' -p /mnt/drive-c --administrative

Using an Administrative Share as a Root for Other Shares​

Administrative shares can be used as a root for other shares. For example, if you have an administrative share named C$, you can create other shares that are subdirectories of this share.

This is done by creating a share with its path pointing to C:/<dir>, where <dir> is the name of the subdirectory that exists in the directory shared as C$.

For example, given the directory tree:

/mnt
└── drive-c
    ├── shared
    └── private

You can create an administrative share for the drive-c directory as C$:

  • netname = C$
  • path = /mnt/drive-c

And a regular share for the shared directory

  • netname = shared
  • path = C:/shared – relative to the C$ share

Since the private directory is not explicitly shared, it will only be accessible to the administrators when using the administrative share C$.

Setting Up a Share Under an Administrative Share Using the Configuration File​
important

This can only be done when the parent administrative share is already configured.

In the relevant[share] section of the configuration file, set the path parameter to the desired path relative to the administrative share, as shown in the following example:

[share]
netname = shared
path = C:/shared
remark = Shared directory
[/share]
Adding a Share Under an Administrative Share Using the Command Line​
important

This can only be done when the parent administrative share is already configured.

When adding a share using the command line, specify the -p or --path parameter to the desired path relative to the administrative share. For example:

sudo tsmb-cfg share add -n shared -p C:/shared

Apple Extensions​

Fusion File Share Server supports Apple Extensions for SMB, enhancing interoperability with macOS clients. These extensions provide additional functionality, improve compatibility with macOS systems, and boost performance when accessing SMB shares from macOS devices. By enabling Apple Extensions, you can take advantage of features such as:

  • Improved Directory Enumeration: Enabled by the kAAPL_SUPPORTS_READ_DIR_ATTR capability, this allows the server to export macOS-specific metadata, such as resource forks and Finder information, improving performance.
  • Time Machine Support: Enabled by the kAAPL_SUPPORTS_FULL_SYNC capability, this feature allows macOS clients to use Time Machine for backup and restore operations on SMB shares.
Global Parameter Enabling Apple Extensions

Value Type: boolean

Value Format: true|false

  • true: Enables Apple Extensions for SMB.
  • false: Disables Apple Extensions for SMB.

Default Value: true

Enabling Apple Extensions Using the Configuration File​

In the [global] section of the configuration file, set the apple_extensions parameter to true to enable Apple Extensions for SMB, as shown below:

[global]
. . .
apple_extensions = true
. . .
[/global]

Case Sensitivity​

In Windows environments, file operations are case-insensitive by default, meaning the file system does not differentiate between uppercase and lowercase characters in file or directory names. For example, MyFile.txt is treated the same as myfile.txt.

However, on Linux, where Fusion File Share Server operates, file operations are case-sensitive. When enabled, Fusion File Share Server first attempts to rely on the underlying file system's support for case-insensitive file name resolution. If not supported by the file system, Fusion File Share Server will fall back on performing a case-insensitive comparison of the file name against all the files in the directory.

For use cases that require case-insensitive operations, Fusion File Share Server allows you to modify the default behavior. You can configure case sensitivity globally for all shares or override it on a per-share basis to meet specific requirements.

important

Fusion File Share Server shares are case-sensitive by default, since processing case-insensitive requests can introduce significant overhead, especially on large datasets or complex directory trees.

Case sensitivity is controlled with the following parameters:

Global Parameter Default Case Sensitivity Behavior for All Shares
Overridden by Per-Share Parameter: case_insensitive

Value Type: boolean

Value Format: true|false

  • true: Makes file operations case-insensitive by default.
  • false: Leaves file operations case-sensitive by default.

Default Value: false

Share Parameter Case Sensitivity for a Specific Share
Overrides Global Parameter: case_insensitive

Value Type: boolean

Value Format: true|false

  • true: Makes file operations on the share case-insensitive.
  • false: Leaves file operations on the share case-sensitive.

Default Value: as set in the global configuration.

Configuring Case Sensitivity for a Share Using the Configuration File​

Define the default behavior for all shares in the [global] section. You can override this behavior in specific [share] sections.

  • Example 1: Enabling Case-Insensitivity Globally but Keeping a Specific Share Case-Sensitive

    [global]
    . . .
    case_insensitive = true
    . . .
    [/global]

    [share]
    netname = MyShare
    path = /export/share
    case_insensitive = false
    [/share]

  • Example 2: Disabling Case-Insensitivity Globally but Enabling it for a Specific Share

    [global]
    . . . # no change - case-insensitivity is disabled by default
    [/global]

    [share]
    netname = MyShare
    path = /export/share
    case_insensitive = true
    [/share]

Adding a Case-Insensitive Share Using the Command Line​

When adding a share using the command line, specify the --case-insensitive parameter. For example:

sudo tsmb-cfg share add -n MyShare \
    -p /export/share \
    --case-insensitive true

Change Notifications​

SMB change notifications enable clients to subscribe to events that alert them to changes in files and directories on a share. This functionality is particularly useful for applications that need to monitor file changes in real-time, such as the Windows File Explorer or collaborative editing tools. Clients can receive notifications about both data changes and metadata updates, such as modifications to a file's name or attributes.

Global Parameter Change Notification Behavior

Value Type: string

Value Format: smb|kernel|none

  • smb: Generates change notifications based on file operations performed by SMB clients against the Fusion File Share Server. This option does not detect changes made by other means, such as direct access to the storage, or changes made by other protocols (e.g., NFS shares enabled for the same data). Use this setting for custom VFS modules that don't trigger inotify events.
  • kernel: Generates change notifications for clients based on notifications Fusion File Share Server receives from the kernel's inotify interface. This includes changes made via any method, including direct access to storage, or changes made by other protocols.
  • none: Disables change notifications.

Default Value: kernel

Configuring Change Notifications Using the Configuration File​

In the [global] section of the configuration file, set the change_notify parameter to the desired method for generating change notifications.

[global]
. . .
change_notify = kernel
. . .
[/global]

Compression​

SMB Compression, introduced in SMB 3.1.1, enhances file transfer performance by minimizing the size of transmitted data. When enabled, it optimizes communication between Fusion File Share Server and supporting clients, reducing bandwidth usage by 20% to 70%, and achieving up to three times faster data transfer speeds, depending on the data type and network conditions.

Fusion File Share Server supports SMB Compression using the LZ77 algorithm. This feature allows you to configure the number of compression threads, the minimum SMB message size for compression, and specify files to exclude. Excluding files is particularly useful for pre-compressed files or directories containing many small files that would not benefit from compression but could incur unnecessary CPU overhead.

Required SMB Dialect: SMB 3.1.1

Enabling compression is done by specifying the compression algorithm you wish to use.

Global Parameter Enabling Compression and Specifying Compression Algorithms

Value Type: string

Value Format: <algorithm>[,<algorithm>,...]

  • <algorithm>: The compression algorithm to use for SMB compression. The supported algorithms are:
    • LZ77

Default Value: none (SMB compression is disabled))

Examples:

  • LZ77: Enables SMB compression using the LZ77 algorithm.

Additional compression parameters:

Global Parameter Number of Compression Threads

Value Type: integer

Value Format: <threads>

  • <threads>: A positive integer representing the number of threads to use for compression.

Default Value: 1

Examples:

  • 10 starts 10 threads for compression.
Global Parameter Minimum SMB Message Size for Compression

Value Type: integer

Value Format: <bytes>

  • <bytes>: A non-negative integer, representing the threshold size in bytes for SMB compression. Messages exceeding this threshold will be compressed if SMB compression is enabled.

Default Value: 4096

Examples:

  • 8192: Only messages larger than 8KB will be compressed.
  • 0: Compress all messages, regardless of size.
Share Parameter Excluding Files from Compression

Value Type: string

Value Format: <pattern>|<pattern>|...

  • Patterns are separated by |.
  • A pattern can include the ? wildcard to match a single character
  • A pattern can include the * wildcard to match any number of characters

Examples:

  • * matches all files.
  • *.tmp|*.bak matches files with the .tmp or .bak extension.
  • *.foo|*.bar|*foobar* matches files that have the .foo or .bar extension, or contain the string foobar.

Configuring Compression Using the Configuration File​

In the [global] section of the configuration file, ensure the SMB 3.1.1 dialect is enabled, enable compression using the LZ77 algorithm, and optionally configure the number of threads used for compression and the minimum message size for compression:

[global]
. . .
dialect_max = SMB3.1.1
compression_algorithms = LZ77
compression_threads = 10
compression_threshold = 1024
. . .
[/global]

Additionally, specify files excluded from compression in the relevant [share] section. The following example excludes common compressed file types from the MyShare share:

[share]
netname = MyShare
path = /export/share
compression_deny = *.zip|*.tar.gz|*.gz|*.tgz|*.rar|*.7z|*.cab|*.jar|*.z
. . .
[/share]

Distributed File System (DFS)​

The Distributed File System (DFS) in SMB simplifies the management and accessibility of network shares by consolidating multiple SMB file shares into a unified namespace. This functionality allows users to navigate shared folders without knowing which specific servers are hosting them.

To use DFS with Fusion File Share Server shares, the feature must be enabled both globally and on each share you want to include in the DFS namespace.

DFS behavior is controlled with the following parameters:

Global Parameter Toggling DFS Globally

Value Type: boolean

Value Format: true|false

  • true: Enables inclusion in DFS.
  • false: Disables inclusion in DFS.

Default Value: false

Share Parameter Toggling DFS Per-Share

Value Type: boolean

Value Format: true|false

  • true: Enables share's inclusion in DFS.
  • false: Disables share's inclusion in DFS.

Default Value: false

Enabling DFS Using the Configuration File​

In the [global] section of the configuration file, set the dfs parameter to true to enable DFS. Additionally, enable DFS for each share you want to include in the namespace by setting the dfs parameter to true in the respective [share] sections.

[global]
. . .
dfs = true
. . .
[/global]

[share]
netname = share1
dfs = true
path = . . .
. . .
[/share]

Durable Handles​

Durable handles enhance the reliability of file operations over network connections by enabling clients to maintain access to open files after temporary network disruptions. When a client requests a durable handle while opening a file, the SMB server assigns a unique handle identifier and retains its state. If the client disconnects unexpectedly, the server preserves the handle state for a defined timeout period, allowing the client to reconnect and continue operations without reopening the file or risking data loss.

  • Durable Handles V1, introduced in SMB2, provides a rudimentary mechanism for maintaining file handles during network disruptions.
  • Durable Handles V2, introduced in SMB3, extends functionality to support continuous and high availability scenarios, such as cluster failovers.

Fusion File Share Server allows you to configure the timeout period for durable handles requested by clients.

Clients using V1 and V2 durable handles are handled differently:

  • V1 clients cannot specify a timeout; Fusion File Share Server fully controls the timeout.
  • V2 clients can specify a timeout. If no timeout is provided, Fusion File Share Server controls the setting.

Durable handles behavior is controlled with the following parameters:

Global Parameter Durable Handles V1 Timeout

Value Type: integer

Value Format: <duration>

  • <duration> is a positive integer representing the number of seconds for the timeout of durable handles V1.

Default Value: 960

Examples:

  • 960 seconds (16 minutes) is the default timeout for durable handles V1.
Required SMB Dialect: SMB 2.002 or higher
Global Parameter Durable Handles V2 Timeout

Value Type: integer

Value Format: <duration>

  • <duration> is a positive integer representing the number of seconds for the timeout of durable handles V2.

Default Value: 180

Examples:

  • 180 seconds (3 minutes) is the default timeout for durable handles V2.
Required SMB Dialect: SMB 3.0 or higher

Setting the Timeout for Durable Handles Using the Configuration File​

In the [global] section of the configuration file, set the durable_v1_timeout parameter to the desired timeout value in seconds.

[global]
. . .
durable_v1_timeout = 540
durable_v2_timeout = 360
. . .
[/global]

The example above sets the timeout for durable handles V1 to 540 seconds (9 minutes) and the timeout for durable handles V2 to 360 seconds (6 minutes).

Setting the Timeout for Durable Handles Using the CLI​

To set the durable handles timeout using the CLI, use the tsmb-cfg global update command with the -t and -T options for V1 and V2 handles timeouts respectively:

sudo tsmb-cfg global update -t 540
sudo tsmb-cfg global update -T 360

In the example above:

  • The first command sets the timeout for durable handles V1 to 540 seconds (9 minutes).
  • The second command sets the timeout for durable handles V2 to 360 seconds (6 minutes).

IPC$ Shares​

The IPC$ share in Windows is a hidden, system-managed share managed by the Windows Server service (srvsvc) for remote administration and communication between networked computers via named pipes. It facilitates administrative tasks like listing available shares, enumerating users, and managing services through Remote Procedure Calls (RPC).

Fusion File Share Server provides an IPC$ share to enable share administration, which is enabled by default.

IPC$ shares behavior is controlled with the following parameter:

Global Parameter Enabling or Disabling the IPC$ Share

Value Type: boolean

Value Format: true|false

  • true: Enables the IPC$ share.
  • false: Disables the IPC$ share.

Default Value: true

Disabling the IPC$ Share Using the Configuration File​

In the [global] section of the configuration file, set the enable_ipc parameter to false to disable the IPC$ share.

[global]
. . .
enable_ipc = false
. . .
[/global]

Named Streams​

Named streams, also known as alternate data streams, allow files to contain multiple streams of data in addition to the default stream ($DATA). Both the default and alternate streams can be independently opened, written to, and read from.

Fusion File Share Server supports named streams by leveraging extended attributes provided by the underlying file system.

Required SMB Dialect: SMB 2.002 or higher
important

The named streams feature must be disabled for a share if the underlying file system does not support extended attributes (e.g., exFAT).

Named streams behavior is controlled with the following parameter:

Share Parameter Enabling or Disabling Named Streams for a Share

Value Type: boolean

Value Format: true|false

  • true: Enables named streams on the share.
  • false: Disables named streams on the share.

Default Value: true

Disabling Named Streams for a Share Using the Configuration File​

In the relevant[share] section of the configuration file for the share you want to configure, set the named_streams parameter to false, as shown in the following example:

[share]
netname = MyShare
path = /export/share
named_streams = false
[/share]

Adding a Share with Named Streams Disabled Using the Command Line​

When adding a share using the command line, enable or disable named streams by including the --named-streams parameter. For example:

sudo tsmb-cfg share add -n MyShare \
    -p /export/share \
    --named-streams false

Updating the Named Streams Setting for a Share Using the Command Line​

When updating a share using the command line, enable or disable named streams by including the --named-streams parameter. For example:

sudo tsmb-cfg share update -n MyShare --named-streams false

Server-Side Copy​

Server-side copy is a feature that allows the server to handle file copy operations within the same server internally, without transferring data to and from the client. Supporting clients initiate server-side copy operations whenever possible, significantly improving performance for large file transfers within the same server. This feature minimizes network traffic and reduces CPU usage on both the client and server, since the data does not need to be read by the client and re-sent to the server.

warning

macOS clients, including macOS 14.1 Sonoma, cannot display progress for server-side copy operations. This limitation can cause applications to appear unresponsive. To address this, server-side copy operations can be disabled specifically for macOS clients while remaining enabled for other client platforms.

Server-side copy behavior is controlled with the following parameters:

Global Parameter Toggling Server-Side Copy for All Clients
Possibly Overrides Global Parameter: apple_server_side_copy

Value Type: boolean

Value Format: true|false

  • true: Enables server-side copy for all clients.
  • false: Disables server-side copy (including macOS clients).

Default Value: true

Global Parameter Toggling Server-Side Copy for macOS Clients
Possibly Overridden by Global Parameter: server_side_copy

Value Type: boolean

Value Format: true|false

  • true: Enables server-side copy macOS clients (has no effect if server_side_copy is false).
  • false: Disables server-side copy for macOS clients.

Default Value: false

Configuring Server-Side Copy Using the Configuration File​

In the [global] section of the configuration file, set the server_side_copy and the apple_server_side_copy parameters to true to enable server-side copy for all clients:

[global]
. . .
server_side_copy = true
apple_server_side_copy = true
. . .
[/global]

Alternatively, you can enable server-side copy for clients except for macOS clients by setting the server_side_copy parameter to true and the apple_server_side_copy parameter to false:

[global]
. . .
server_side_copy = true
apple_server_side_copy = false
. . .
[/global]

Share Scoping​

Share scoping allows you to restrict access to a share based on the server name (or alias) the client uses to connect. When enabled, the share is only accessible if the client connects using the specified server name or alias. This feature is particularly useful for compartmentalizing access based on the server's DNS records, similar to the concept of virtual hosts in HTTP servers.

If share scoping is configured but the server is not accessible using the specified name (e.g., no DNS record resolves the name to any of the server's IP addresses), the share will not be available to clients.

Share scoping behavior is controlled with the following parameter:

Share Parameter Specifying the Server for a Share

Value Type: string

Default Value: none (the share will be visible through any hostname)

Examples:

  • filesrv01 specifies that the share is visible only to clients connecting to \\filesrv01.

Configuring Share Scoping Using the Configuration File​

In the relevant[share] section of the configuration file for the share you want to configure, set the server parameter to the desired server name, as shown in the following example:

[share]
netname = MyShare
path = /export/share
server = filesrv01
[/share]

Adding a Share with Share Scoping Using the Command Line​

When creating a share via the command line, use the --server parameter to specify the desired server name. For example:

sudo tsmb-cfg share add -n MyShare \
    -p /export/share \
    --server filesrv01

Volume Shadow Copy (VSS)​

Volume Shadow Copy Service (VSS) is a framework that enables manual or automatic snapshots of files or volumes, even while in use. This feature allows for point-in-time recovery (PITR), letting users browse the contents of a share as they were at a specific point in time.

Fusion File Share Server's support for VSS depends on the underlying file system's VSS capabilities (private VSS implementation), or by mounting snapshots in a directory accessible to Fusion File Share Server (default VSS implementation).

You can configure the default VSS behavior globally for all shares or override it on a per-share basis.

Required SMB Dialect: SMB 3.0 or higher

Controlling the Default VSS Behavior for All Shares​

You can configure the default VSS behavior for all shares. This setting applies to all shares unless overridden on a per-share basis.

This is particularly useful when shares are created out-of-band, and cannot be configured through the configuration file or CLI.

Global Parameter Enabling or Disabling VSS for Shares by Default
Overridden by Per-Share Parameter: vss

Value Type: boolean

Value Format: true|false

  • true: Enables VSS on all shares, except for shares for which it was explicitly disabled.
  • false: Disables VSS on all shares, except for shares for which it was explicitly enabled.

Default Value: false

Global Parameter Default Parameters for VSS Data Locations
Overridden by Per-Share Parameter: vss_params

Value Type: string

note

The following format applies only when when the default VSS implementation is used. If the underlying file system of the share has a different VSS implementation, use that file system's specific format to configure VSS.

Value Format: path=<path>[,share_root=<share_root>]

  • path=<path> (required): <path> is where the snapshot roots are located. Under this directory, subdirectories are expected named with the following timestamp format: @GMT-YYYY.MM.DD-hh.mm.ss (e.g., @GMT-2019.11.11-12.10.10, @GMT-2024.05.03-22.12.42, etc.). To allow for a consistent naming pattern across all shares, <path> can include the following variables:
    • ${share.netname}: refers to the share's name, as defined in the share's netname parameter.
    • ${share.path.dirname}: refers to the share's path, as defined in the share's path parameter, without the last component (e.g., /path/to for /path/to/share).
    • ${share.path.basename}: refers to the share's path, as defined in the share's path parameter, without the leading path (e.g., share for /path/to/share).
  • share_root=<share_root> (optional): This parameter is used when you have multiple shares on the same volume, and when a snapshot is taken, it's taken for the entire volume. Hence, <share_root> specifies the the directory inside each snapshot subdirectory that contains the files for this particular share at that point of time. If not specified, the share root defaults to the root of the snapshot subdirectory.

Default Value: none.

Examples:

  • path=/mnt/.snapshots/${share.netname},share_root=data, if the share's name is sh1 and its path is /mnt/data, specifies that the snapshot roots are located in the /mnt/.snapshots/sh1 directory, and the share's data for each snapshot is in the /mnt/.snapshots/sh1/@GMT-<timestamp>/data directory.
  • path=${share.path.dirname}/.snapshots,share_root=data, if the share's path is /mnt/data, specifies that the snapshot roots are located in the /mnt/.snapshots directory, and the share's data for each snapshot is in the /mnt/.snapshots/@GMT-<timestamp>/data directory.
  • path=${share.path.dirname}/.snapshots,share_root=${share.path.basename}, if the share's path is /mnt/data/public, specifies that the snapshot roots are located in the /mnt/.snapshots directory, and the share's data for each snapshot is in the /mnt/.snapshots/@GMT-<timestamp>/public directory.

Controlling VSS Behavior for a Specific Share​

If VSS is disabled by default, first enable VSS on the share.

Share Parameter Enabling or Disabling VSS on a Share
Overrides Global Parameter: vss

Value Type: boolean

Value Format: true|false

  • true: Enables VSS on the share.
  • false: Disables VSS on the share.

Default Value: as set in the global configuration.

When VSS is enabled, depending on the underlying file system and its VSS support, you may need to configure additional parameters.

Share Parameter Configuring Additional Parameters for VSS on a Share
Overrides Global Parameter: vss_params

Value Type: string

note

The following format applies only when when the default VSS implementation is used. If the underlying file system of the share has a different VSS implementation, use that file system's specific format to configure VSS.

Value Format: path=<path>[,share_root=<share_root>]

  • path=<path> (required): <path> is where the snapshot roots are located. Under this directory, subdirectories are expected named with the following timestamp format: @GMT-YYYY.MM.DD-hh.mm.ss (e.g., @GMT-2019.11.11-12.10.10, @GMT-2024.05.03-22.12.42, etc.).
  • share_root=<share_root> (optional): This parameter is used when you have multiple shares on the same volume, and when a snapshot is taken, it's taken for the entire volume. Hence, <share_root> specifies the the directory inside each snapshot subdirectory that contains the files for this particular share at that point of time. If not specified, the share root defaults to the root of the snapshot subdirectory.

Default Value: as set in the global configuration.

Examples:

  • path=/mnt/my-share-snapshots specifies that the snapshot roots are located in the /mnt/my-share-snapshots directory.
  • path=/mnt/snapshots,share_root=my-share specifies that the snapshot roots are located in the /mnt/snapshots directory, and the share root for each share is the /mnt/snapshots/@GMT-<timestamp>/my-share directory.

Setting Up VSS for a Share Using the Configuration File​

Setting Up a Share with VSS, Using the Default Behavior:​

In the [global] section of the configuration file, set the vss parameter to true to enable VSS for shares by default. Additionally, specify the path where the snapshot roots are located if necessary.

[global]
. . .
vss = true
vss_params = path=/mnt/.snapshots/${share.netname},share_root=data
. . .
[/global]

[share]
netname = sh1
path = /mnt/data
[/share]

In the example above, VSS is enabled for shares by default, and the snapshot roots are located in the /mnt/.snapshots/sh1 directory. The share's data for each snapshot is in the /mnt/.snapshots/sh1/@GMT-<timestamp>/data directory.

Setting Up a Share with VSS, Overriding the Default Behavior:​

In the relevant[share] section of the configuration file for the share you want to configure, set the vss parameter to true, and set the vss_params parameter to point to the directory where the snapshot roots are located, as shown in the following example:

[share]
netname = MyShare
path = /export/share
vss = true
vss_params = path=/mnt/my-share-snapshots
[/share]

Adding a Share with VSS Using the Command Line​

When adding a share using the command line, specify the --vss parameter and the --vss-params parameter. For example:

sudo tsmb-cfg share add -n MyShare \
    -p /export/share\
    --vss true \
    --vss-params "path=/mnt/my-share-snapshots"

Windows/DOS File Attribute Storage​

In Microsoft environments, file systems such as FAT and NTFS traditionally support file attributes that define how the operating system should handle a file. These attributes are Hidden, System, and Archive:

  • Archive (A): Indicates that the file has been modified since the last backup and should be included in the next backup operation. Backup software clears this attribute after backing up the file, and the operating system sets it again when the file is modified.
  • Hidden (H): Marks the file as hidden, preventing it from appearing in directory listings, such as when in the DIR command output or when browsing in Windows File Explorer and file dialogs.
  • System (S): Marks the file as a system file, protecting it from being modified or deleted. This attribute safeguards critical files from accidental changes. System files are typically treated as hidden as well.

Since Fusion File Share Server operates in a Linux environment, where the shared file system is most likely does not support file attributes natively, Fusion File Share Server offers multiple mechanisms to store these attributes, which can be configured on a per-share basis, depending on the underlying file system.

Share Parameter Specifying the Storage Method for File Attributes

Value Type: string

Value Format: <method>[,<method>,...]

  • Values are separated by ,.

  • A <method> can be one of the following:

    • native: Store attributes natively on the file system, if supported. Use this option if the underlying file system is NTFS, or another private VFS module that supports these attributes.
    • xattr[:<version>]: Use Samba-compatible extended attribute user.DOSATTRIB to store the attributes. The optional <version> parameter specifies the version of the extended attribute format to use:
      • v3: Use the Samba 3.5 to 4.10 format.
      • v4: Use the Samba 4.11 to 4.16 format (default).
      • v5: Use the Samba 4.17 or newer format.
    • filename:<attributes>:<pattern>: Treat files matching <pattern> as always having the attributes specified in <attributes>:
      • <attributes> is a non-delimited combination of:
        • A: Archive.
        • S: System.
        • H: Hidden.
      • <pattern> is a shell-style wildcard pattern that matches the file name.
      note

      The only currently supported <pattern> is .*.

    • posix-exec:<attributes>: Map attributes to POSIX execute permission bits, where <attributes> is a non-delimited combination of:
      • A: Archive, stored in the user's execute permission bit (u+x).
      • S: System, stored in the group's execute permission bit (g+x).
      • H: Hidden, stored in the other's execute permission bit (o+x).
      note

      This is a legacy method and should be used with care. This method doesn't affect directories, and assumes that the execute permission bits are not used for their original purpose, and are only modified by Fusion File Share Server.

Default Value: xattr:v4

Examples:

  • xattr,filename:HS:.*: Uses the default Samba v4 extended attributes format, and treat all dot files as having the Hidden and System attributes.

Setting Up Windows File Attributes Storage for a Share Using the Configuration File​

In the relevant[share] section of the configuration file for the share you want to configure, set the map_attributes parameter to the desired value, as shown in the following example:

[share]
netname = MyShare
path = /export/share
map_attributes = xattr:v4
[/share]

Adding a Share with Windows File Attributes Storage Using the Command Line​

When adding a share using the command line, specify the the storage method using the -m or --map-attributes parameters. For example:

sudo tsmb-cfg share add -n MyShare -p /export/share --map-attributes xattr:v4