Manual Pages

Table of Contents


sectrace - manages permission tracing filters


sectrace add [-ip <ipaddr>] [-ntuser <nt username> -unixuser <uid/unix username>] [-path <path>] [-a]

sectrace delete { [<index>] | all }

sectrace show [ <index> | all ]

sectrace print-status <status>

sectrace help <command>


When the filer determines that a user does not have permission to perform a specific operation, it usually returns a general Access denied error to the client request. There are a wide variety of reasons why the user might not have permission to do something which may have nothing to do with the security in place on the file system, often making it difficult to determine the source of the error.

Using the sectrace command, administrators can generate filters that track these requests and report the specific reason why it was refused. The requests can be filtered by any combination of IP address, user and path prefix. If any filter matches an incoming request, the results will be printed to the console.

Additionally, there may be instances where a user is granted access when it seems like they should not be. The sectrace command allows you to create filters that track these events as well, and you can print the full list of decisions that were made which allowed that request to proceed.

When active, these filters may have a minor impact on performance. They are designed to be used temporarily in order to help diagnose specific permission problems, and should not be used for any other purpose.

NOTE: sectrace functionality is currently limited to requests from the CIFS protocol. Support for additional protocols may be added in future releases


Adds a permission tracing filter and starts tracing requests that meet all the criteria specified in this filter. It also returns the index of the filter, which can be used to reference the filter in other sectrace sub-commands. Currently a maximum of 10 filters can be set per vFiler(tm).

-ip <ipaddr>
Specify the IP Address of a client. The filter would match only if the request is received from this client.

-ntuser <nt username>
Specify the NT(tm) user name. The filter would match only if the request is received with this user. The <NT username> can be of the form DOMAIN\USER or USER. This option cannot be used if -unixuser is provided.

-unixuser <uid/unix username>
Specify the UNIX(R) user name (uid). The filter would match only if the request is received with this user name credential. This option cannot be used if -ntuser is provided.

-path <path>
Specify a path prefix. The filter would match only if the request is received for a file or directory with this path prefix.

Specify whether to trace ALLOW requests as well, along with DENY requests that are traced by default.

Deletes one or all permission tracing filters based on the options provided. If a filter index is specified, the filter bearing this index is deleted. If all is specified, all permission tracing filters added in the vFiler(tm) are deleted.

print-status <status>
This takes in the <status> code logged corresponding to a request and provides detailed information about the reason for DENY or ALLOW of a request. The <status> code is marked with a Status: tag in the logged message.

This displays the permission tracing filters added in a vFiler(tm). If the index is specified, the filter bearing this index is displayed. If all is specified or no option is provided, all filters are displayed.

help <command>
This provides a brief reference on command usage.


Setting a simple deny filter for requests from a specific client:

sectrace add -ip

Setting a filter for both ALLOW and DENY requests for a UNIX user with login foo accessing home directory under /vol/vol0/home4 :

sectrace add -unixuser foo -path /vol/vol0/home4 -a

Displaying filter bearing index 5 :

sectrace show 5


If a very generic filter is set which results in a lot of requests being traced and logged:
Some events might get dropped and not get logged. The filer console might get spammed with log events.

It is recommended to add criteria to make the filters more specific. e.g.: limiting the filter match criteria to a specific user or IP Address.

Table of Contents