Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, April 18, 2018 7:33 PM
Recently, I have added a couple of Windows 10 Pro machines to my network. All existing client machines are Windows 7 Pro, with the servers being a mix from Windows Server 2008 R2 to Windows Server 2012 R2.
One of my windows 10 client users complained of another user taking control of a file he was working on. That is, he had the file open in write mode, and at some point, another user on the network was able to ALSO open the file in write mode without notifying him. Hence, he was unable to save his work to the original file. It caused quite the mess.
First, the report I got from this user was because of this issue in AutoCAD. Naturally, I double checked this issue with another Windows 10 client on the network, and found the same issue. I brought the issue up with Autodesk support, and was given a link to the following knowledge base article:
Given that file locking was working perfectly fine between my Windows 7 clients and Windows Server 2012 R2, I decided to test also using Microsoft Excel. Indeed, Excel had the same problem. Windows 10 would dump the file locks within 2 hours.
I found one other post with a similar issue, linked here:
The suggested fixes in the above link do not help. These are not Excel "shared" workbooks. The issue is not limited to Excel, it is definitely OS level.
Once I determined that is was not AutoCAD specific, I chose to test whether it was server specific. I opened a file using a Windows 10 client on one of our older Windows Server 2008 R2 servers. Windows 10 did indeed retain its' file locks indefinitely as it should.
Based on my findings, I figure it's an issue with SMB version 3.0.2. I could just disable it, but I'd rather get the bug straightened out as opposed to working around the issue.
Does anyone have a suggestion as to the next step in getting this worked out?
All replies (7)
Wednesday, April 18, 2018 8:31 PM
Momo,
That is describing the opposite problem of the issue I am facing.
Here is a breakdown:
User 1 (using Windows 10) opens a file on the network share. An .XLSX file for example.
If user 2 (Using Windows 7 or 10, doesn't matter) attempts to open the same file, they get notified that the file is locked for editing. It can be opened read only, or the user can be notified. This is the expected functionality.
Wait 2 hours and 1 minute.
If user 2 attempts now to open the file, the file opens without any notification. This is NOT expected functionality. User 1 still has the file open; the server -should- disallow the connection, and the client should get the read only notify dialog. At this point, if user 1 attempts to save changes made to the file, they will get an error.
The problem described in that article is a very prevalent issue, and unfortunately, searching for this issue has given me pages and pages full of that kind of issue, which isn't even close to the issue I'm describing. I appreciate the effort, though.
Thursday, April 19, 2018 3:21 PM
Firstly, placing the documents on the local machine in Public Documents would take networking out of the equation. The 2 users in my above example are on 2 different machines. User 2 wouldn't even see the files.
Second, I've already displayed that hosting the files on an SMB share on an older server does not exhibit the issue. That shows that the applications are not at fault. It also rules out any 'network delay timing' possibilities, as that server is WAY slower than the newer Server 2012 R2 machine.
The Excel link you provided above details using file level protection, which has nothing to do with read-only protection at the file level - that is completely handled within Excel, and is outside of the scope of the issue with which I am dealing.
Friday, April 20, 2018 7:35 PM
I logged a second administrative user into the Windows 10 machine I'm using for testing. As that user, I copied an Excel file into the Public Documents folder, and opened it. I then used the 'Switch User' functionality to log in as the original administrative user on that machine (both are domain accounts) and attempted to open the same file. As expected, I received the read-only / notify dialog box. I waited a little over 2 hours, and tried again. Again, I received the read-only / notify dialog box. The file remained locked by the first user to open the file. That is expected functionality.
As for your question on LAN Manager, I have not set that parameter within Group Policy. However, all machines in question are members of the same domain, and as such, should be using Kerberos.
Monday, April 23, 2018 12:26 PM
The workbook being used for testing does not have the "Share Workbook" function enabled.
I thought I'd included that information in the initial post; I didn't, my apologies.
Tuesday, April 24, 2018 3:31 PM
Momo,
A basic file sharing tutorial is not going to help in this situation. I know how to create SMB shares, I have permissions set properly. 90+ other windows users can already access this share just fine.
Wednesday, April 25, 2018 12:17 PM | 1 vote
Sorry if I come off being difficult. I sometimes forget that, as a tech troubleshooting a problem, you have to start with the easiest possible solutions and work your way up. I have to do that with my users, and I suppose I'm lucky they don't treat me like I treated you.
In any case, I contacted the users in both of the similar posts I found, one on these forums, one on the Office forums. The guy that had the problem on the Office forums found what looks to be the issue. Here is a link to the forum post:
Long story short, the GPO for the mapped network drive was set to "Replace." By changing that setting to "Update," the Windows 10 machines now seem to be holding file locks indefinitely as they should.
Thank you for your assistance in figuring this out. I'm sorry I was such a difficult participant.
Tuesday, January 8, 2019 4:30 AM
Thanks for taking the time to tell us what fixed it for you. Having the same issue, here is hoping the same fix will resolve it. The mapped drives were all set to Replace, because i had the "remove this when no longer applied" feature selected.