New post
Question
· Nov 15, 2020

background processes cannot access network shares

#Terminal #Caché

version cache for windows, 2017.2.1 build 801_3 - windows 10

I had this system set up for 3+ years now, and background tasks such as converting emails,  have always worked, suddenly it's stopped working and I've tracked it down to any network references.

reading the emails, I look for any attachment files, and save them to a network drive before processing them within a class method,

I've been testing it by sending exactly the same email repeatedly and checking the saving of the attached file in both the background and in the terminal.

within the email fetch, if I say "save the attached file to \\10.0.0.25\my-directory\newfileName.doc" it fails IN THE BACKGROUND TASK

If I then run the same class method IN THE TERMINAL, it will happily save to the \\10.0.0.25\ location.

If I change the location to a local file ie "d:\my-directory\newfileName.doc"   IT WORKS IN THE BACKGROUND AND TERMINAL

I've checked the cache.exe in services and I've logged in using exactly the same user account (my name)

I've tested the cache service logging in as a different user, nothing.

I've rebooted the Cache machine and  I've rebooted the 10.0.0.25 machine

I've checked the user access rights as the interactive user within win10 and the access rights within the remote server, Bothe are correctly set

we are on the latest update of win10

question: which user does the Cache-terminal login as, is this different to the win10-services cache.exe settings.

anybody got any ideas what else I can check please

 

kev

Discussion (11)0
Log in or sign up to continue
Julius Kavay · Nov 15, 2020

Hello Kevin,

in most of the cases (but not always) the reason for this is the exhaustion of TCP ports, see

https://docs.microsoft.com/en-us/windows/client-management/troubleshoot-...

too. Grab a windows command prompt and start with

netsh int ipv4 show dynamicport tcp

this shows you how many ports you have.

netstat -ano | find "TCP"

shows you all the TCP ports in use (including the process numbers) and

netstat -an | find "TCP" | find "CLOSE"

shows you all the bad guys.

If this is your problem then the solution is:

- increase the number of ports (if it's possible)

- reduce the cases, where a new port is needed and immediate closing of unneeded ports

0 0
Eduard Lebedyuk · Nov 15, 2020

Looks like a user permissions issue.

question: which user does the Cache-terminal login as, is this different to the win10-services cache.exe settings.

Yes, the terminal works under your OS user, Cache (and InterSystems IRIS) background jobs work under system account user (you can check services - Cache to see the user).

You need to give permissions to access the share to system account user.

0 0
Vic Sun · Nov 16, 2020

Hi Kevin,

Just as a quick note, the supported way to change the service user on modern versions is using the setserviceusername command, and not to change the service user manually.

https://docs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=GCI_windows#GCI_windows_nonadminperm_change

It wasn't clear to me from your description if you used this, so I'm not sure if manually changing the service could be a part of the problem.

0 0
Kevin Furze · Nov 16, 2020

looking at the docs quickly, this seems to be in the upgrade notes from 2018.1.3 moving to 2018.1.4

I'm currently still on 2017.2.1 so I'm not sure it applies to me yet??

late this afternoon ( 1hour ago), we got a bit further by dropping any shares under ".\kevin" then shutting down the live instance of cache,  before recreating some shares and getting prompted for the password of the remote machine, Once we got this bit working, and restarting Cache, the background cache->remote machine started working again.

we are still busy testing this, but perhaps there was some corruption in remembering the share name/password and re-setting the password has done something.

Still not sure if it's totally working and it will be overnight before the checking is complete.

thanks to all those folk who offered solutions, it's certainly had us puzzled for a while. 

kev

0 0
Kevin Furze · Nov 16, 2020

as a small side note to Vic Sun's reply, there is also a note in that same 2018.1.4 upgrade notes that says

( my username already has admin rights but just another thing to think of )

"If you select Minimal for your initial security setting, but Caché requires network access to shared drives and printers, you must manually change the Windows user account under which to run the Caché service, choosing an existing account or creating a new account that has local administrator privileges on the server machine."
0 0