Folder monitors not starting jobs when FFAStrans is run from NAS

[Stef]

Hi there

Using FFAStrans version 1.2.1, folder monitors don't seem to start jobs when FFAStrans is started from a NAS. Jobs are being picked up, as they are shown "incoming" in the webinterface, but they never actually start processing. When running FFAStrans from a local disk, it seems to work properly. I think it did work in the past, but it's been a while since I've made a setup like this.

We're running from a NAS to be able to distribute jobs over a number of computers (and keep workflows synchronised).

Webinterface is ran as a sevice with proper login credentials and FFAStrans is started from a desktop shortcut, pointing to the .exe via UNC/IP address, instead of a mapped drive as per this post:

...
So basically you have to start ffastrans GUI from the full UNC path when installing the service AND whenever you open the workflow GUI.
Also, you must configure your service to run under credentials that have access to the UNC path, there is something in the wiki about it in installation section.
...

Neither UNC nor mapped drives seem to work as folder paths.

I'm not sure what causes this issue and after a few days of trying serveral things, I'm stumped as what to try next.

[emcodem]

Hey Stef,
so the files are shown as incoming... will they stay in that state forever? In that case i'd suspect the service credentials have only "list" permissions but no "read". Something i have seen very often e.g. on isilon, seems to be some kind of default config there (or our admins are just strange hehe)
What i do to debug such kind of issues is to log onto windows with the exact same credentials as you set as service credentials, open windows explorer to your NAS location, try to play a file in vlc or such. If that works you have read rights and the issue is very strange

Another good test would be to manually submit a file from the UNC path to some workflow and see if it's getting processed.

[Stef]

They stay shown as incoming. I have checked read/write permissions and those are all configured correctly. Manually submitting jobs works, so I would guess it's not an issue with file permissions.

I did stumble upon a workaround: creating a symbolic link on a local hard drive that points to the folder on te NAS where FFAStrans is located, and running it from that link does make watchfolder functionality work again (in a cmd window: mklink /D FFAStrans "\\NAS-IP\path-to-ffastrans-folder"). I'm not sure as to why this works, but for now this seems like a viable way to get it working.

[admin]

Hi Stef,

This is interesting" Honestly I have not looked into symbolic links myself but I will. It might help others having problems with getting FFAStrans to work properly of a NAS.

Thanks!

-steinar

[emcodem]

Hey Stef,
As we cannot explain whats Happening and this is Not expected behaviour, it would be really good if you work with getting down to the bottom of it.
You want to Do that or are you already satisfied and dont want to invest work here?

[Stef]

Sure, I'd be happy to help! Let me know what I can do to help sort it out.

[emcodem]

OK cool, thanks!

Could you zip and upload the whole /db folder for start please? It will tell us some infos we need to know before asking more detailed questions.

[Stef]

Zipped DB folder (too large to attach):
https://share.mailbox.org/ajax/share/02 ... zU/NzUvODM

All api, exe and job logs are included. It decompresses to about 190MiB, just a heads up.

[emcodem]

Thats great stuff, thanks!
Hm, it's hard to tell when you enabled which watchfolder and when/if there were files that have not been processed, we'll need to wait until steinar has some time, maybe he gets out more. If all don't work, we'd probably need to start by having you enable just a single empty watchfolder on a unc location, throw in some file so it gets into this incoming forever state and then send us the corresponding exe_manager log...

[admin]

Hi Stef,

Thanks for the logs. Very helpful

So, by looking at the logs we see on the 30. June and 1. July a lot of incoming "tickets" as we call them. They are basically a message for the system to kick of some job processing. This happens every time a new file has been discovered by the initial monitor. After that the new file goes through even more verifications steps (which takes longer) in order to finally decide if the new file is ready for further processing in order to complete.
Now, in the logs from the mentioned dates there are recurring tickets every few seconds and they are being closed again just a few seconds later. This is not normal. One thing that can cause this is if the new files from the monitor cannot be completely verified. Then I noticed all the new tickets come from the same workflows build for fetching youtube (etc.) media. I know some of these shortcuts can have very long and strange names. FFAStrans has been crafted to handle this but it might be the odd case where the shortcut is simply too obscure for FFAStrans to handle, even though it SHOULD be able to handle any valid files.
So, we need to know a little bit about that. Was the file that never was picked up some long/strange youtube shortcut?

-steinar