V11.4 Docs

source/_generated/agents/docs/admin_guide.md

@@ -373,7 +373,7 @@ Currently integrations are limited to direct messages between users and the agen
 
 ## Model Context Protocol (MCP) Integration
 
-The Model Context Protocol (MCP) integration allows Agents to connect to external tools and services through standardized MCP servers. This [experimental](https://docs.mattermost.com/manage/feature-labels.html#experimental) feature enables expanding AI capabilities with custom integrations.
+The Model Context Protocol (MCP) integration allows Agents to connect to external tools and services through standardized MCP servers. This feature enables expanding AI capabilities with custom integrations.
 
 ### Configuration
 
@@ -430,7 +430,7 @@ For more information, see [Atlassian's documentation on MCP server settings](htt
 
 ## Mattermost MCP Server
 
-The Mattermost MCP Server enables AI agents and external applications to interact with your Mattermost instance through the Model Context Protocol (MCP). This [experimental](https://docs.mattermost.com/manage/feature-labels.html#experimental) feature is a standardized protocol that allows AI assistants to read messages, search content, create posts, and manage channels and teams programmatically. 
+The Mattermost MCP Server enables AI agents and external applications to interact with your Mattermost instance through the Model Context Protocol (MCP). This is a standardized protocol that allows AI assistants to read messages, search content, create posts, and manage channels and teams programmatically. 
 
 ### Overview
 

source/administration-guide/configure/environment-configuration-settings.rst

@@ -3095,7 +3095,10 @@ File log directory
 
 .. note::
 
-  The path you configure must exist, and Mattermost must have write permissions for this directory.
+  - The path you configure must exist, and Mattermost must have write permissions for this directory.
+  - From Mattermost v11.4, you can use the ``MM_LOG_PATH`` environment variable to restrict log file locations to a designated root directory. This security enhancement ensures that all log files configured via ``LogSettings.FileLocation`` or ``LogSettings.AdvancedLoggingJSON`` remain within an authorized logging directory. 
+
+    - If ``MM_LOG_PATH`` isn't set, the default ``logs`` directory is used. Paths outside the root directory generate error logs and are excluded from :doc:`support packet </administration-guide/manage/admin/generating-support-packet>` downloads. See the :ref:`log path restrictions <administration-guide/manage/logging:log path restrictions>` documentation for details.
 
 .. config:setting:: file-log-level
   :displayname: General file log level (General Logging)
@@ -3203,6 +3206,7 @@ Output logs to multiple targets
   - See the :doc:`Mattermost logging </administration-guide/manage/logging>` documentation for details. These targets have been chosen as they support the vast majority of log aggregators, and other log analysis tools, without needing additional software installed.
   - Logs are recorded asynchronously to reduce latency to the caller.
   - Advanced logging supports hot-reloading of logger configuration.
+  - From Mattermost v11.4, file paths specified in ``AdvancedLoggingJSON`` configurations should be within the directory specified by the ``MM_LOG_PATH`` environment variable. See :ref:`log path restrictions <administration-guide/manage/logging:log path restrictions>` for details.
 
 .. config:setting:: maximum-field-size
   :displayname: Maximum general log field size (General Logging)

source/administration-guide/configure/environment-variables.rst

@@ -40,4 +40,4 @@ Load custom configuration defaults
 This custom configuration applies only if the values are not already present in the current server configuration.
 
 1. Create a JSON file that contains the custom configuration defaults. For example, ``custom.json``.
-2. When starting the server, point the custom defaults environment variable to the defaults file: ``MM_CUSTOM_DEFAULTS_PATH=custom.json``.
+2. When starting the server, point the custom defaults environment variable to the defaults file: ``MM_CUSTOM_DEFAULTS_PATH=custom.json``.

source/administration-guide/configure/experimental-configuration-settings.rst

@@ -1811,6 +1811,10 @@ When running Mattermost in :doc:`High Availablity mode </administration-guide/sc
 
    We strongly recommend that you not change this setting from the default setting of ``true`` as this prevents the ``ClusterLeader`` from being able to run the scheduler. As a result, recurring jobs such as LDAP sync, Compliance Export, and data retention will no longer be scheduled. In previous Mattermost Server versions, and this documentation, the instructions stated to run the Job Server with ``RunScheduler: false``. The cluster design has evolved and this is no longer the case.
 
+.. tip::
+
+   From Mattermost v11.4, debug-level log messages are available to help verify that specific Recurring Tasks (Scheduled Posts, Post Reminders, and DND Status Reset) are executing correctly in a cluster. Non-leader nodes log messages when they skip execution of these Recurring Tasks, confirming that leader election is functioning as expected. These debug messages do not apply to other job types such as Elasticsearch indexing, SAML sync, or LDAP sync. See :ref:`Cluster job execution debug messages <administration-guide/manage/logging:cluster job execution debug messages>` for details.
+
 +-----------------------------------------------------------------------------------------------------------------------------------------+
 | This feature's ``config.json`` setting is ``"RunScheduler": true`` with options ``true`` and ``false``.                                 |
 +-----------------------------------------------------------------------------------------------------------------------------------------+

source/administration-guide/configure/manage-user-surveys.rst

@@ -22,11 +22,7 @@ The User Survey integration is compatible with Mattermost v9.11.2 or later.
 Install
 --------
 
-
-
-.. note::
-
-  From Mattermost v9.11.2 (ESR) and Mattermost Cloud v10, this plugin is pre-packaged with the Mattermost Server. If your Mattermost deployment is on a release prior to v9.11.2, download the `latest plugin binary release <https://github.com/mattermost/mattermost-plugin-user-survey/releases>`_, and upload it to your server via **System Console > Plugin Management**.
+From Mattermost v9.11.2 (ESR) and Mattermost Cloud v10, this plugin is pre-packaged with the Mattermost Server. If your Mattermost deployment is on a prior release, download the `latest plugin binary release <https://github.com/mattermost/mattermost-plugin-user-survey/releases>`_, and upload it to your server via **System Console > Plugin Management**.
 
 Upgrade
 ~~~~~~~

source/administration-guide/manage/admin/generating-support-packet.rst

@@ -11,7 +11,8 @@ Generate
 
 .. important::
 
-   Before generating a Support Packet, go to **System Console > Environment > Logging** and ensure **Output logs to file** is set to **true**, and set **File Log Level** to **DEBUG**.
+   - Before generating a Support Packet, go to **System Console > Environment > Logging** and ensure **Output logs to file** is set to **true**, and set **File Log Level** to **DEBUG**
+   - From Mattermost v11.4, support packet generation is recorded in the audit log (when :ref:`audit logging is enabled and configured <administration-guide/manage/logging:audit logging>`). The audit event includes the username, timestamp, success/failure status, whether logs were included, plugin packets requested, and the output filename. This audit trail helps track access to potentially sensitive log data for compliance purposes.
 
 .. tab:: Web/Desktop
 

source/administration-guide/manage/logging.rst

@@ -248,6 +248,104 @@ You can enable and customize advanced audit logging in Mattermost to record acti
 
 ----
 
+Log path restrictions
+---------------------
+
+From Mattermost v11.4, log file paths are validated to ensure they remain within a designated logging root directory. This security enhancement prevents log files from being written to or read from unauthorized locations on the file system.
+
+Configure the logging root directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+From Mattermost v11.4, use the ``MM_LOG_PATH`` environment variable to define the root directory for all log files:
+
+.. code-block:: sh
+
+   export MM_LOG_PATH=/var/log/mattermost
+
+If ``MM_LOG_PATH`` isn't set, Mattermost uses the default ``logs`` directory relative to the Mattermost binary location.
+
+Log path validation
+~~~~~~~~~~~~~~~~~~~
+
+All log file paths configured via the following settings are validated:
+
+- ``LogSettings.FileLocation`` - main :ref:`server log file location <administration-guide/configure/environment-configuration-settings:file log directory>`
+- ``LogSettings.AdvancedLoggingJSON`` - all :ref:`file targets in advanced logging configuration <administration-guide/configure/environment-configuration-settings:output logs to multiple targets>`
+- ``ExperimentalAuditSettings.AdvancedLoggingJSON`` - all :ref:`file targets in audit logging configuration <administration-guide/configure/environment-configuration-settings:output audit logs to multiple targets>`
+
+**How validation works**:
+
+1. Paths are resolved to absolute paths
+2. Symlinks are resolved to their actual locations
+3. The resolved path is validated against the logging root directory
+4. Paths outside the root directory generate error logs and are excluded from downloads
+
+**Validation occurs**:
+
+- When accessing log files via **System Console > Reporting > Server Logs**
+- When generating support packets
+- During configuration changes (warnings are logged for invalid paths)
+
+When a log file path is outside the allowed root directory, Mattermost logs an error and excludes the file from support packet downloads: ``"Blocked attempt to read log file outside allowed root"``. The error message includes the file path, configuration section, and validation failure details.
+
+Configuration requirements
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**If using default logging**: No action required. Logs are stored in the default ``logs`` directory.
+
+**If using custom log paths**: Ensure all log file paths in ``AdvancedLoggingJSON`` point to locations within your logging root directory.
+
+**Valid configuration example**:
+
+.. code-block:: sh
+
+   export MM_LOG_PATH=/var/log/mattermost
+
+In ``config.json``:
+
+.. code-block:: JSON
+
+   {
+     "file1": {
+       "type": "file",
+       "format": "json",
+       "levels": [
+         {"id": 2, "name": "error", "stacktrace": true}
+       ],
+       "options": {
+         "filename": "/var/log/mattermost/errors.log",
+         "max_size": 100,
+         "max_age": 7,
+         "max_backups": 10,
+         "compress": true
+       },
+       "maxqueuesize": 1000
+     }
+   }
+
+This configuration is valid because ``/var/log/mattermost/errors.log`` is within the ``/var/log/mattermost`` root.
+
+**Invalid configuration example**:
+
+If ``MM_LOG_PATH=/var/log/mattermost``, this configuration fails:
+
+.. code-block:: JSON
+
+   {
+     "file1": {
+       "type": "file",
+       "options": {
+         "filename": "/tmp/logs/app.log"
+       }
+     }
+   }
+
+This fails because ``/tmp/logs/app.log`` is outside the ``/var/log/mattermost`` root directory. 
+
+See the :ref:`troubleshooting <deployment-guide/server/troubleshooting:log files not accessible>` documentation for troubleshooting steps if logs aren't appearing in the System Console or support packets due to log path issues.
+
+----
+
 Advanced logging
 -----------------
 
@@ -435,7 +533,6 @@ Define advanced log output
             }
         }
 
-
     v10.12 or earlier
     ^^^^^^^^^^^^^^^^^^
 
@@ -638,7 +735,7 @@ File targets support rotation and compression triggered by size and/or duration.
 +-------------+----------+---------------------------------------------------------------------------------------------------------------------+
 | **Key**     | **Type** | **Description**                                                                                                     |
 +-------------+----------+---------------------------------------------------------------------------------------------------------------------+
-| filename    | string   | Full path to the output file.                                                                                       |
+| filename    | string   | Full path to the output file. From v11.4, should be within the directory specified by ``MM_LOG_PATH``.              |
 +-------------+----------+---------------------------------------------------------------------------------------------------------------------+
 | max_size    | number   | Maximum size, in megabytes (MB), the log file can grow before it gets rotated. Default is ``100`` MB.               |
 +-------------+----------+---------------------------------------------------------------------------------------------------------------------+
@@ -701,6 +798,66 @@ The TCP socket targets can be configured with an IP address or domain name, port
 
 ---- 
 
+Cluster job execution debug messages
+-------------------------------------
+
+.. include:: ../../_static/badges/ent-plus.rst
+  :start-after: :nosearch:
+
+From Mattermost v11.4, debug-level log messages are available to help system admins understand cluster job execution behavior in :doc:`high availability </administration-guide/scale/high-availability-cluster-based-deployment>` deployments for specific Recurring Tasks.
+
+These debug messages apply only to the following Recurring Tasks:
+
+- Scheduled Posts
+- Post Reminders
+- DND Status Reset
+
+.. important::
+
+  - These debug messages aren't available for other job types such as Elasticsearch indexing, SAML sync, LDAP sync, data retention, or compliance exports. The absence of these debug messages for other job types doesn't indicate a problem with job execution.
+  - These messages are only visible when debug logging is enabled. See `How do I enable debug logging? <#how-do-i-enable-debug-logging>`__ for details.
+  - In a cluster deployment, only the leader node executes these Recurring Tasks. Non-leader nodes skip these specific jobs and log debug messages to indicate this is expected behavior.
+
+Debug messages for job startup
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When a non-leader node starts up, it skips initialization for these specific Recurring Tasks and logs one of the following debug messages:
+
+- ``Skipping scheduled posts job startup since this is not the leader node``
+- ``Skipping unset DND status job startup since this is not the leader node``
+- ``Skipping post reminder job startup since this is not the leader node``
+
+These messages indicate normal operation. In a high availability cluster, these Recurring Tasks should only run on the leader node to prevent duplicate execution.
+
+Debug messages for leadership changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When a node loses leadership status while these Recurring Tasks are running, it cancels the running tasks and logs:
+
+- ``This is no longer leader node. Cancelling the [job name] task``
+
+Where ``[job name]`` is one of: ``scheduled posts``, ``DND status reset``, or ``post reminder``.
+
+This indicates the cluster is performing leader election correctly. The new leader node will take over execution of these Recurring Tasks.
+
+Troubleshooting with cluster job debug messages
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If you're investigating why Recurring Tasks (Scheduled Posts, Post Reminders, or DND Status Reset) aren't running on a specific node:
+
+1. Enable debug logging if not already enabled.
+2. Check the logs for the debug messages listed above.
+3. If you see these messages, the node is correctly identified as a non-leader and is behaving as expected.
+4. These Recurring Tasks will be running on the leader node instead.
+
+.. note::
+
+  These debug messages only apply to Recurring Tasks. For other job types (Elasticsearch indexing, SAML sync, LDAP sync, data retention, compliance exports), different logging mechanisms apply. The absence of these specific debug messages for other job types is expected and does not indicate a problem.
+
+For more information about leader election and cluster configuration, see :doc:`High Availability cluster-based deployment </administration-guide/scale/high-availability-cluster-based-deployment>`.
+
+----
+
 Frequently asked questions
 --------------------------
 

source/administration-guide/scale/high-availability-cluster-based-deployment.rst

@@ -450,6 +450,10 @@ A cluster leader election process assigns any scheduled task such as LDAP sync t
 
 The process is based on a widely used `bully leader election algorithm <https://en.wikipedia.org/wiki/Bully_algorithm>`__ where the process with the lowest node ID number from amongst the non-failed processes is selected as the leader.
 
+.. note::
+
+  From Mattermost v11.4, debug-level log messages help identify which node is executing specific Recurring Tasks (Scheduled Posts, Post Reminders, and DND Status Reset). Non-leader nodes log messages like ``Skipping scheduled posts job startup since this is not the leader node`` to indicate they are correctly deferring execution of these Recurring Tasks to the leader. These are normal operational messages, not errors. These debug messages do not apply to other job types such as Elasticsearch indexing, SAML sync, or LDAP sync. See :ref:`Cluster job execution debug messages <administration-guide/manage/logging:cluster job execution debug messages>` for details.
+
 Job server
 ^^^^^^^^^^^
 
@@ -459,14 +463,16 @@ Mattermost runs periodic tasks via the :ref:`job server <administration-guide/co
 - Data retention
 - Compliance exports
 - Elasticsearch indexing
+- Scheduled posts
+- DND status reset
+- Post reminders
 
 Make sure you have set ``JobSettings.RunScheduler`` to ``true`` in ``config.json`` for all app and job servers in the cluster. The cluster leader will then be responsible for scheduling recurring jobs.
 
 .. note::
 
-  It is strongly recommended not to change this setting from the default setting of ``true`` as this prevents the ``ClusterLeader`` from being able to run the scheduler. As a result, recurring jobs such as LDAP sync, Compliance Export, and data retention will no longer be scheduled.
-
-In previous Mattermost Server versions, and this documentation, the instructions stated to run the Job Server with ``RunScheduler: false``. The cluster design has evolved and this is no longer the case.
+  - We strongly recommend not changing this setting from the default setting of ``true`` as this prevents the ``ClusterLeader`` from being able to run the scheduler. As a result, recurring jobs such as LDAP sync, Compliance Export, and data retention will no longer be scheduled. In previous Mattermost Server versions, and this documentation, the instructions stated to run the Job Server with ``RunScheduler: false``. The cluster design has evolved and this is no longer the case.
+  - From Mattermost v11.4, you can verify that Recurring Tasks (Scheduled Posts, Post Reminders, and DND Status Reset) are running on the correct node by enabling debug logging. Non-leader nodes will log messages indicating they are skipping execution of these specific Recurring Tasks, which is expected behavior. These debug messages don't apply to other job types. See :ref:`Cluster job execution debug messages <administration-guide/manage/logging:cluster job execution debug messages>` for more information.
 
 Plugins and High Availability
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^