background processes cannot access network shares
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
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
this shows you how many ports you have.
shows you all the TCP ports in use (including the process numbers) and
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
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.
Looks like a user permissions issue.
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.
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.
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?
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
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.
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
The first reference to setserviceusername is in the 2015.1 release notes, so yes I think this would apply to your version.
Missed that, I'll read the notes again, thanks for the heads-up
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 )
Social networks
InterSystems resources
To leave a comment or answer to post please log in
Please log in
To leave a post please log in