An interactive terminal and a DSM scheduled task may run the same-looking command under different conditions. Before changing the script to use an administrator account, compare the task's actual user, paths and shell. A permission or working-directory difference can explain the failure without a broader access change.

Match the execution context

In the task's General settings, inspect the selected user. Confirm that this account can read the required input and write to the intended output folder. Use the exact shared-folder paths involved; access to a parent share does not by itself demonstrate every operation the script attempts.

Synology's scripting guidance recommends absolute paths for commands and an accessible working directory. It also advises specifying the intended shell. Review relative filenames, commands found through an interactive PATH and assumptions about where the script starts. Preserve the current script before editing so the investigation has a stable reference.

For example, a script that expects input.txt in its current directory may work after someone manually changes folders in a terminal. The scheduled task needs that location made explicit. Correct the path assumption using the real approved directory rather than copying a sample path from an online guide.

Capture the failure in the scheduler

Task Scheduler offers Save output results in Settings and View Result under Action. Use the saved output from the relevant task run to identify the failing command or missing location. Store user scripts and their outputs in appropriate shared folders, as Synology recommends, rather than filling the system partition.

Prepare a harmless test scope before manually running the task through the scheduler. If the original script can delete, move or overwrite files, review those effects first and use disposable data. A successful run against a sample should show the expected output content, not just an absence of an error message.

Compare one corrected condition at a time and retain the execution account with only the access the task requires. Once the scheduler test produces the intended result, document the paths, shell, user and output location. That record makes the next failure easier to diagnose without treating every scheduling problem as a reason to grant root access.

Sources: Synology documentation 1, Synology documentation 2.