Workflow Script with automated tagging

What I want to do:
Every office and pdf file uploaded into a specific directory or one of its subdirectories should be copied to a different location, preserving part of the directory structure.

The problem:
The script itself seems to work as it does what its supposed to when I execute it manually, under circumstances I cant seem to properly replicate it also executes the script successfully but I dont know how to properly debug it as the flow.log has no content (0byte) I changed the path of the flow.log and it created the file but its still 0bytes.
Within the script, the first thing I do is touch a file for a simple check that the script was executed (so for me it looks like the issue is the triggering).

Here is a screenshot of the configured flows:
image

and here is the script which does not seem to be executed anyhow:
touch /tmp/ppl-start &>> /config/log/scripts.log
fdst=${1/$2/$3} &>> /config/log/scripts.log
mkdir -p “${fdst%/*}” &>> /config/log/scripts.log
cp -p “$1” “$fdst” &>> /config/log/scripts.log
touch /tmp/ppl-end &>> /config/log/scripts.log

Is my workflow configuration incorrect, should I do this some other way?
How can I make the workflowengine log to flow.log so I can troubleshoot this?

This post went unanswered for 9 months.

Nevertheless, I would like to dive into the issue a bit and explain why this did not work, because others may end up here using the search function.

Lets start with the screenshot:
the script-string of the last (4th) rule is

echo "%f" /config/log/test1

this doesn’t do anything except echoing %f /config/log/test1 into /dev/null

If the value of %f is to be written at the end of the log file /config/log/test1, then this must be done with “>>”:

echo "%f" >> /config/log/test1

This having said, the most common fault people make with this app, is that they forget, that the script will be executed by the web-server user (www-data for debianoids like ubuntu).

Many people write and test their scripts as root, because it’s easy. That laziness is the reason why they forget about the normal restrictions other users have.

This Script:

is totally ok but when first run as root, the file “/config/log/scripts.log” got created with root as owner and 644 rights. All attempts from the script, when invoked by www-data wil fail.

The default umask value on most Linux systems is typically 022, which means that newly created files will have permissions of 644 (read-write for the owner, and read-only for group and others), and newly created directories will have permissions of 755 (read-write-execute for the owner, and read-execute for group and others).

So it’s likely that the script was run as root with the default umask value, which resulted in the log file being created with permissions of 644. If you want the log file to be writable by the webserver user, you will need to change the file’s ownership or permissions to allow write access for the appropriate user or group.

Here some tips, how to debug/learn to understand this app:

step 1

create this script /usr/local/bin/runscript-logger that will write your output into a log file:

#!/bin/bash
# /usr/local/bin/runscript-logger
# change path to logfile accordingly

echo "$(date +"%Y-%m-%d %H:%M:%S %Z") - $@" >>  /var/log/nextcloud/runscript.log
exit 0

and make it executable.

chmod +x /usr/local/bin/runscript-logger

If you run it before by another user as the web server user:

chown www-data.www-data /var/log/nextcloud/runscript.log

step 2

create your rules in the flow-admin section:

https://YOURDOMAIN.TLD/settings/admin/workflow

and enter this string in the field for the command:

/usr/local/bin/runscript-logger %e - %i - %a - %o - %n - %f - %x

step 3

Install the command-line JSON processor jq for logfile processing:

apt install jq

step 4

Set loglevel to “0” in config/config.php

step 5

open one terminal and run:

tail -f /var/log/nextcloud/nextcloud.log | jq '.| select(.app == "workflow_script" or (.message | contains("WorkflowScript")))'

and if you want, open a second terminal and run:

tail -f /var/log/nextcloud/runscript.log

Now make sure that the rule applies (upload a file or something)

In the first terminal you will see, what is happening under the motorhood, in the second, you will see the echo that should appear when the next cron job is executed.


Do not forget, to set the loglevel back to 2, because 0 (debug) level creates a lot of output and will bloat your logfile.


website of Nextcloud Workflow Script app


I hope I could help

Even though I have created this post with the greatest possible care, I know with certainty that I (as usual) made at least small mistakes. If you find any inaccuracies please point them out to me, I will correct them immediately if possible or your comment will be the correction.

Happy hacking