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 disabled leasing on my test Windows Server 2012R2 as described in the above MS article, leaving SMB2 and OpLocks enabled. Unfortunately, this did not affect the errors in the sort program that I'm testing, it still received numerous file status 93,00.
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 were anxious to let some users try the registry changes Doug passed along on SMB2 and OpLocks espeically since it was a simple change and server based versus having to do something to each client PC. However we got some mixed feedback on on those. We had one site that their IT guy said "We’ve run into quite a few issues after disabling SMBv2. As a workaround for these side effects, we then had to disable additional security functions on our Windows 10 machines that we really did not want to do. And so far it appears to have helped the situation only slightly. We are still in need of a manageable fix that less impactful." Does anyone know if that is to be expected - that is by making those registry changes it then causes other problems on the network and file sharing/access especially with newer versions of Windows like 10? I was really hopeful this might provide some relief to many of our clients having this problem, but have now got kind of afraid to try it based on feedback from a few and then it only seems to have helped the problem somewhat. It almost seems like this problem is worse for some than others, whether that is due to server/network performance or what.
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
Can these SMB2/OpLock values be shut off on the client side instead? That might give the granular control where needed while allowing normal, healthy speeds for other clients and Windows 10.
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
Seriously, thanks, I had been for two hours trying to get permission to copy a couple of files to the system32 directory and nothing worked, only the ownership hack. Great work admin
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 have discovered another potential workaround.
I have verified this with the one test program we have that demonstrates error 93,00 doing a COBOL SORT when running on a mapped drive.
On the Windows 7 client PC navigate in the File Explorer to the Runtime executable, wrun32.exe. Right-click on it and select Properties, go to the Compatibility tab, enable “Run this program in compatibility mode for:”, select Windows 95, and click OK. (You may need to use the “Change settings for all users” button.)
After this the 93,00 errors were drastically reduced, not completely gone but only 1 out of 500 runs produced the error. Before enabling compatibility mode about 15 out of 100 runs produced the error.
Please test this and let us know if it reduces or eliminates the errors in your application.
NOTE that you cannot set compatibility mode for an executable on a mapped drive. It must be local on the PC in order to implement this workaround.
There is no word from Development yet as to a cause of the 93,00 on the SORT program, or a possible fix. I’ll keep you posted.
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
There is now a fix for the file errors when running on Windows 7 (or 2008) mapped drives!
If you have a support contract in place then raise a support incident requesting a patch for ECN-4545, and attach a screen shot of the version dialog displayed after executing "wrun32 -vv".
