go to post Kevin Furze · Nov 16, 2020 Missed that, I'll read the notes again, thanks for the heads-up
go to post 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."
go to post 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
go to post Kevin Furze · Nov 15, 2020 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
go to post Kevin Furze · Nov 15, 2020 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.
go to post Kevin Furze · Nov 15, 2020 Julius, when I run the commands in order you suggest, I get Start Port: 49152No 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.
go to post Kevin Furze · Jan 15, 2020 that was fast, just 13 minutes for an answer, nice one I'll test it tomorrow, but in the mean time, looks like I'll accept this as the answer
go to post Kevin Furze · Jan 9, 2020 system currently in use so I can't immediately test. I get full access in 10 hours time. in the mean time, a 5 minute test failed in the same way as did a 30 minute and the 24hour test. Nothing created the html files in all cases. what's confusing here is that the log file happily go created, but the html file failed. in each case, there was only ever one single log file which contains the commands that will be executed, no other log files were created at any time strangely enough, the ^Buttons file did create the html file from exactly the same window terminal that we've just run the three test of ^pButtons
