background processes cannot access network shares

Question

Question

Kevin Furze · Nov 15, 2020

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

Julius Kavay · Nov 15, 2020

Just to see things clearer, you do this test directly on Cache server (i.e. local)?
And you have logged in with your local (and not, for example with an domain\kevin) account? Cache runs also under the same local "kevin" account?

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

score 0 · Answer 1 · 2020-11-15T13:56:05-05:00

Julius,

when I run the commands in order you suggest, I get

Start Port: 49152
No of Ports : 16384

less than 6 pages when I look for the actual in use ports

and when I try to find the "bad guys", there's none.

the stats have been taken within 10 minutes of a reboot, and still I can't access the background network shares.

I'm guessing this isn't the problem.

score 0 · Answer 2 · 2020-11-15T13:49:00-05:00

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.

score 0 · Answer 3 · 2020-11-15T13:59:40-05:00

Eduard.

logging in as the current user within terminal is exactly what I thought was happening, but in this case, I have the Cache.exe service logging in as ".\kevin" and I've logged in as the user "kevin" so in theory, the background and terminal should be returning the same access rights and so returning the same results but it doesn't.

kev.

score 0 · Answer 4 · 2020-11-15T14:24:30-05:00

Yes it's run on the live server (where I'm having problems) with the local account "kevin" - in theory, the same as the cache.exe service

score 0 · Answer 5 · 2020-11-16T12:00:30-05:00

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

score 0 · Answer 6 · 2020-11-16T12:03:45-05:00

The first reference to setserviceusername is in the 2015.1 release notes, so yes I think this would apply to your version.

score 0 · Answer 7 · 2020-11-16T14:30:27-05:00

Kevin Furze · Nov 16, 2020

Missed that, I'll read the notes again, thanks for the heads-up

0 0

score 0 · Answer 8 · 2020-11-16T12:10:12-05:00

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."