Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Yes I did (Incident # 3139992) on 01/02/18 and they referred me to this forum saying that several other users had reported it. They said removing this KB seemed to be the work around and if any other news about it came up, they would update me, but looks like the incident closed automatically due to no further action on my part or Micro Focus.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
That is a frustrating response. MicroFocus should be the party dealing with MicroSOFT to get this resolved, since they are at the center of the affected users. Is the expectation that we should all individually be trying to get Microsoft to resolve the problem?
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Yes, we agree that the issue is frustrating. While we have logged support incidents from Wayne's report and from Dale as well, we have not received a reproducible test case in either and we have not yet been able to reproduce any of these reported errors in house. Those of you who are experiencing the errors, which appear to be caused by a specific Windows Update, please report the issue to Microsoft if you haven't already. Microsoft will need to work directly with you in order to troubleshoot the issue. If they are aware of the problem then there is at least a chance they will address it in a future update.
You can report it on Microsoft's Support Page,
support.microsoft.com/en-us, or the TechNet Forum,
social.technet.microsoft.com/.../home
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Oh, dangerous reasoning!
Is a problem I do not have a problem at all?
Is my customer's problem mine?
I think the topic is fortunately discussed here in this forum in such detail because no one else feels responsible.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Hi all,
There is no dangerous reasoning here.
Yes, I agree that the issue is frustrating.
But like Doug already mentioned we can investigate more only if we have a reproducible sample.
We have tried internally to reproduce the issue with the samples provided by customers but we have not been able to reproduce it.
Even the customers canāt reproduce it themselves due to the random nature of this problem.
We are always taking into account customers issues and always trying to solve them when it is possible.
We are still trying to reproduce this issue in different sites across the world, but until now without success.
If a customer is able to isolate the issue and reproduce it on a consistent manner, we will make progress in our investigations and find a solution.
Best regards,
Dominique SacrƩ
Product Director
Micro Focus
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
We know it has something to do with the latest MS patches, starting with KB405518 on a Windows 7 client accessing a mapped 2012 file server. It is very sporadic, and can't be easily recreated. Uninstalling KB4054518 from the client PC resolves the problem. KB4054518 was a rollup patch, containing 3 items: KB4051034, KB4048957, and KB4055038
KB4054518 was replaced by KB4056894, which contained 2 patches, KB4054518 and KB4055038. When KB4056894 was installed, the problem came back. We have since uninstalled that patch also.
We are trying to get a PC with a clean Win7 image, and will try to narrow this down to a particular patch, installing them one-by-one. I'm not sure it will help us get any closer to the problem, but it might help recreating it.
KB4054518 contained:
KB4051034
KB4048957
KB4055038
www.catalog.update.microsoft.com/Search.aspx
ALSO, KB4056894 replaces
KB4055038
KB4054518
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
I just wanted to let everyone know that we have had two different locations setup to do a file trace to see if that would give us any additional information. Since they turned this feature on they have not received the 3707 error. Before this they were getting it at least twice a day. They currently have the FILE_TRACE set to 9, so they are experiencing a bit of a performance hit. We have not changed the trace level yet to see if a lesser value will continue to "stop" the errors or not.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Yesterday (2-1-18) I was able to get connected to a customer who was able to keep duplicating the error. The file that was getting the error was a temporary file that we are creating to generate a print preview. The error appeared to be occurring like all of the other during the deletion. The odd thing is that it appears that the delete is actually occurring because the files are getting removed sometimes. Every 2 or 3 times they previewed a report they would get the 3707 error. (there are also other files that are users are getting the error on, not just this one) I then decided to try the FILE_TRACE option with this customer. In their configuration file I added the following options "FILE_TRACE 3", "FILE_TRACE_FLUSH 1", "FILE_TRACE_TIMESTAMP 1" and "MAX_ERROR_LINES 100". I then had their script to run our application changed to "wrun32 -lxe errorfile -swc config program". We then executed the updated script and they have run ever since with out getting the error again. I did mess the FILE_TRACE level to get it to the lowest number that stopped the errors. When I had it set to a 1 or 2 we were still getting the 3707 error, when we got to 3 the errors stopped.
There are some performance considerations with using the file trace, but hopefully having it set as a 3 will minimize the affect. We are happier to slow our window 7 users down a bit to get them to stop with the frustrating 3707 errors. If any of users start having the errors come back with the trace turn on, I will let everyone know.
Scott
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Dale's test results show that repeating the DELETE FILE operation works. It sometimes required up to 14 repeats before success, but it works. Therefore a request has now been submitted to Development that they consider the feasibility of modifying the Runtime to repeat the DELETE FILE upon error.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
One more suggestion would be adding a timer, it appears the OS is taking its sweet time to complete the actual deletion, and adding a timer might do the trick, either in the program doing the delete or the runtime.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
I wonder if the problem (ie change in behavior due to the OS patch) is in the close operation? Usually, with my temporary files, my code is CLOSE/DELETE one right after the other. Since logging "fixes" the issue, I agree the issue sounds like timing. If the close operation in cobol is triggering something in the operating system that is executing asynchonously, then the OS might still be working on the file when the DELETE gets executed under normal timing, meaning it's not really closed yet. But with logging turned on, the runtime would launch the close, log that operation in the trace file, then do the DELETE - giving the operating system enough time to finish things off, leaving the file ready for another operation.
If this is the case, it implies that a slight change to the source code, separating the close from the delete, would work around this issue. eg) close the temp file, close other files, delete the temp file. This is worth considering if anyone gets desperate.
Full disclosure: We haven't been having this issue, most of our clients are linux.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
We also were wondering if it was possibly a speed issue, but not being able to duplicated with a program the write out lots of records, closed it and deleted all very quickly seemed to make us think that it could be something different. We were kind of wondering if the trace file was keeping the network connection active. What we found odd is that a trace level of 2 was still allowing the error to occur, but a level 3 was stopping the problem. I wonder what the difference is between a 2 and 3 trace level? The documentation does not seem to indicate what the different levels are. We just know that 9 has the most detail.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Linux OS is lighting compared to Windows anything, so I am not surprised at that at all, especially if Windows is using mapped drives, remember in Windows the program is executing the code on the users desktop (unless you are using Acuserver, Acuconnect, RDP, or RDS), and Linux everything is running from the server.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Development notes that you will likely be able to implement one of the workarounds long before any enhancement is completed. After re-reading this thread, my understanding is that there are currently 5 known workarounds (in no particular order):
1. Uninstall the Update that broke it.
2. Repeat the delete using declaratives.
3. Turn on level 3 file tracing.
4. AcuServer.
5. Upgrade Client PCs to Windows 10.
(There may be other ways.)
Is there any reason that you cannot implement one of these workarounds? What we're looking for are detailed descriptions of impediments that would prevent implementation of the workarounds.
Thank you.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
1. Uninstall patch that broke it. NOT A good solution, as it keeps getting re-installed.
2. Repeat the delete using declaratives. NOT A good solution; too many programs need changed
3. Turn on level 3 file trace. POSSIBLE, will test.
4. AcuServer. NOT a quick solution unless you rely 100% on file prefix (ie: no fully qualified file names)
5. Upgrade client PCs to Win10. NOT a good solution; can't require our customers upgrade their equipment
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Hi Doug
I have a few questions just to catch up on the situation.
1) Given that Dale apparently can replicate the issue can we rule out the idea that it is the Anti Virus software that is being invoked by the operating system?
2) Our clients are running ACu4GL and we get error 9107 ... it sounds exactly the same as 3707 ... what are these others guys executing to get 3707?
3) Our failing code is performing OPEN I-O, CLOSE, DELETE. We are doing this to prevent failure if we were to simply delete and the file does not exist. The code has been in place for a great many years. Howeer my most recent testing showings that we DO NOT GET AN ERROR if we simply DELETE, even if the file does not exist. Has something changed over the years with the compiler. My point being that we are not getting problems on DELETEs ...but rather on the OPEN I-O, CLOSE, DELETE on the bounce. It seems the creation of the new temporary file attracts the unwanted attention of either the Operating system or the anti virus.
A work around for us would be to replace the 3 operations by the single delete. However there is SOOOoo much code to change.
4) Note also that a batch processes have not been impacted as they run on the same server as the data files. Only users accessing the data from a Citrix server are impacted.
Of the work-arounds suggested:
1. Uninstall patch that broke it. NOT A good solution, as it keeps getting re-installed. [Agreed and besides clients are saying this it strictly not permissible at their sites - Jim]
2. Repeat the delete using declaratives. NOT A good solution; too many programs need changed
3. Turn on level 3 file trace. POSSIBLE, will test. [Interesting idea, obviously our online users might be impacted with undesirble performance issues, but better than9107 - Jim]
4. AcuServer. NOT a quick solution unless you rely 100% on file prefix (ie: no fully qualified file names) [The suggestion of Acuserver is something I thought might work ...but I cannot test as I cannot replicate the issue. Has Dale or others proven that Acuserver prevents the issue? - Jim]
5. Upgrade client PCs to Win10. NOT a good solution; can't require our customers upgrade their equipment [ ditto - Jim]
If this issue is actually proven to be linked to the Operating System has anyone been able to get explanation as to what on earth the Op Sytstem has been change to do? ...and do Microoft intend to correct this?
Regards
Jim
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Jim,
I agree that none of the "workarounds" are practical, especially for an ISV with a large codebase. We are having the problem with SORTs, so we don't even have control over option 2.
I'm not sure anyone has actually contacted Microsoft for help with this.
This has basically turned into a stand-off, since everyone (including MicroFocus support) are saying that they can't reproduce the issue to actually troubleshoot it. We have asked MicroFocus to help us and their response is to call Microsoft ourselves or totally rewrite every program that uses a SORT. The situation is frustrating to say the least.
-Chris
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Unfortunately, I am coming in late to this issue, so, I am not sure what all has been suggested/tried. However, I do provide support for the ACUCOBOL extend products at Micro Focus, so, I might be able to provide some guidance in regards to this problem.
As a first step, has anyone been able to determine what actual Windows error is occurring when the 37,07 failure is encountered. For example, has anyone tried to capture the failure using a tool like Microsoft's Process Monitor, or, tried enabling Windows auditing for the the affected directory?
For more information in regards to Process Monitor, or, Windows auditing, please see the following links:
https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
https://social.technet.microsoft.com/Forums/windowsserver/en-US/ed46b837-007f-474b-9a68-454c7f76f192/how-to-audit-delete-filesfolders-action-on-shared?forum=winservergen
The Windows OS error might help point us the direction of the underlying cause of this issue, either in the extend runtime or the Windows networking environment.
Also, how are the network offline caching, and file indexing, options configured for the affected network shares?
There are some known issues in regards to delete operations failing, depending upon how these options are configured. For more information in regards to this subject, please see the following Microsoft article:
https://support.microsoft.com/en-us/help/3196524/renaming-or-deleting-a-folder-on-a-network-share-fails-with-0x8007003b
**If this information has already been discussed in the prior posts, I apologize.
Regards,
-Steve
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
It looks like February Microsoft updates have maybe installed another roll-up KB that may have superseded the KB's listed previously so our customers just keep chasing these down. We have tried the FILE-TRACE level 3 on 1 customer that it seemed to have helped but unfortunately without any success on a couple of others, so we are getting beat up pretty bad with this. Clients are nervous about turning off all future MS updates. They are not crazy about upgrading to Windows 10 and AcuServer is just a hard sell because of the price when they never had to have it to begin with even though we have recommended it. If this was consistent enough, I would not mind changing a few programs that could use the %TEMP% folder to do so, but we have 2 major issues with this. First we have over 1,800 DELETE FILE commands in our application. And secondly, some or these actually do need to be server based where they can be shared by multiple users such as journal file to hold entries for multiple users until posted and updated and deleted. Is anyone else having any luck with the FILE-TRACE level 3 or I have even tried a few notches higher on one client without luck? Thanks to all for the help!
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
As of now, we have had one 1 customer that may have had the 3707 with the trace turned on, but I an not exactly sure they had everything setup correctly. But we have lots of other customers who were getting the error all the time and they are no longer getting the 3707 errors. When I first was testing to see if the trace would work, we had a customer that could duplicate the problem pretty consistently, It would usual crash with in 3-5 attempts. I first started with a trace level of 9 and worked our way back until we started getting the error again and for us 3 was the magic number. I would just try a few notches higher or just set it to 9 and see if it stops the error. As of now, it seem like it is the "best" option to stop the issue. I am sure there is a bit more of a performance hit the higher trace number that you use, but its better than the error. Good Luck!!
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Thank you for the reply and update on this on-going issue. I do think as per your suggestion I will bump the trace level up a notch at a time until we either see if it resolves the 3707's as a work-around or the client complains about it being too slow. I know I have tried level 9 a couple of times before when trouble-shooting AcuServer issues and clients complained it was almost unbearable the speed, so I will try working my way up I think. Thanks again for your feed-back on your experiences on this.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
UPDATE:
Thanks to Lou at CF Data, Micro Focus now has a test case that reproduces an error. My test environment is a Windows 7 with current updates applied and a drive mapped to a virtual Windows Server 2008R2. The test program consists of a tiny COBOL SORT which sometimes gets a file status 93,00. Out of a cycle of 100 executions there are between 5 and 15 failures. That program is now in Development's hands .
Dale also provided a test case which unfortunately did not reproduce any errors in any of my test environments. If you all can provide us with a test case to reproduce your error it will help in Development's investigation.
Note that after reproducing the file status 93 on the SORT program I disabled SMB2 and OpLocks on the server (then rebooted). After this the error did not reproduce. So it seems that the Windows Update may have tweaked the SMB2 and/or Opportunistic Locking features. It will be helpful if you all could do the same test - disable SMB2 and Oplocks on the server and report your results.
In the Registry Editor go to:
HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanmanServer\\Parameters
Create a new DWORD named SMB2 and another named EnableOpLocks, both should be set to 0 (zero).
Reboot the server for them to take effect.
JimmyBoy, you reported that your users are seeing errors with Acu4GL. I'm not sure that is related to the errors in this thread as Acu4GL is accessing a database rather than a disk file over a mapped drive. A trace file may reveal something helpful for troubleshooting that. Please raise a support incident if you'd like us to look into that further.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
This seems to have eliminated the 3707 error for us which is a huge step in right direction. Unfortunately we have seen some increased latency which I'm assuming relates to the disabling of SMB2. Is disabling that an absolute requirement or will the OpLocks suffice? Or do the two values work in tandem?
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
Thank you crsturges for testing this. Yes, SMB2 does not allow OpLocks to be disabled; you must disable both.
Hello,
I just wanted to throw this out there and see if any other users are having similar issues. Our applications are on the 10.1.0 and after the latest windows update quite a few of our customers on Windows 10 are getting 3707 errors [user does not have appropriate access permissions to the file (open)] when we are creating some temporary files. The odd thing is that it is not happening every time, they go back into the same process and everything works fine. Some of these routines that create the temporary files have been in place for a very long time and have never had problems till this week. We have not been able to duplicate the problem yet, so I just wanted to see if anyone else was having the same problem and if they have been able to solve it. It seems like the last update has messed something up, just not sure what yet.
Thanks,
Scott Meiners
From some recent research, it appears as though "Leasing" is the newer, updated form of OPLOCKS in SMB2 and SMB3. We have come across a number of places where the suggestion is to leave SMB2/SMB3 enabled, but disable leasing. We haven't had the opportunity to test this yet, but at some sites where we tried disabling SMB2 and OPLOCKS, other network problems have cropped up that have made it impossible to leave this as the solution (at some sites we have seen strange permissions problems or workstations that couldn't access network shares when SMB2/SMB3 are disabled).
support.microsoft.com/.../cannot-access-shared-files-or-folders-on-a-drive-in-windows-server-201
blogs.msdn.microsoft.com/.../
