Synology DSM Task Scheduler non-root user environment bug

bug-report.md

OS version

DSM 6.1-15047 Update 1

Problem explanation

There's bug/defect in task scheduler in that a user-defined script scheduled to run as a non-root user is executed in an environment where $USER is root, $HOME is /root, and the starting directory is /root, which shouldn't be readable by non-root users. This leads to permission errors when executing standard utilities like find(1).

Expected behavior: $USER is set to the user the script is scheduled to run as; $HOME and the starting directory are set to the home directory of $USER.

By the way, I know how to work around the issue. I'm reporting this to hopefully have this behavior fixed, rather than asking for a workaround.

Problem reproduction steps

Create the following script:

#!/bin/sh
echo -n "pwd: "
pwd
echo "USER: $USER"
echo "HOME: $HOME"
find /volume1

(The support form doesn't really support <pre> blocks; in case formatting is messed up, here's the script hosted on GitHub: https://gist.githubusercontent.com/anonymous/edb2df691b3df377d9e49554a78176db/raw/a7c074b03376c3b750a183112e5f06773a6d8fb2/synology-task-scheduler-script.)

Now, create a user-defined script in Task Scheduler, with user set to a non-root user, and put the path to the script above in the "Run command" section of "Task Settings". Enable email notification so that we can see the output.

Result:

Standard output/error:
pwd: /root
USER: root
HOME: /root
find: cannot get current directory: Permission denied

synology-task-scheduler-script

#!/bin/sh
echo -n "pwd: "
pwd
echo "USER: $USER"
echo "HOME: $HOME"
find /volume1

I don't think this ever got fixed. I ran into this issue today on the latest release of DSM (6.1.4-15217-5)

If you prepend your script with

export USER=<user>
export HOME="/var/services/homes/<user>"
cd $HOME

where user means the user under which account the task is scheduled (e.g. admin)
It seems to work at least for the tastk had problems with.

Thanks for this guys. The issue was driving me and others nuts 👍

Thank you very much. I was pulling my hair out over this one.

Thank you!

This bug is still in DSM 6.2...

work around is to put a "cd ~username" in front of the script.
so if your user is "admin", put

cd ~admin
script.sh

Sounds like a bug to me... It is reasonable to expect that when you configure a task to be run as user xxx, it starts at the user xxx home folder and that $HOME is set up accordingly.
Did someone ever turn this into a Synology ticket?

Seems the root problem is now fixed in DSM 6.2.2-24922 Update 4.
However, it appears the working directory doesn't match $HOME, which seems peculiar.

pwd: /volume1/homes/tommy
USER: 
HOME: /var/services/homes/tommy

Do i miss something? I execute the script with a non admin/root user

   #!/bin/sh
   echo -n "pwd: "
   pwd
   echo "USER: $USER"
   echo "HOME: $HOME"
   echo "whoami" $(whoami)
   echo "id" $(id)

pwd: /volume1/homes/rsyncUser
USER: 
HOME: /var/services/homes/rsyncUser
whoami root
id uid=0(root) gid=0(root) groups=0(root),100(users)

why its executed as root wtf?