There are a few issues with Finder still but there are simple workarounds e.g. Have observed through windows open file utility that when a user traverses into a directory the directory considered locked but when they back out it indeed unlocks right away thus allowing folder naming and deleting capability. The previous folder lockout issue appears to be resolved on 10.14.x. We are moving toward all endpoints to be 10.14.3 (or latest). 10.13.x was a non starter even when attempting to edit /etc/nf with suggested fixes. We are again running a WS 2016 SMB3 fileserver for our mac clients in production.
Greetings….just want to follow up on the smb issue If we then select the open files and force them to close on the server, everything starts working again (until the open files build up and build up). It’s the thousands of Read only file handles that’s causing these problems. We also see some files that are opened with Write + Read access – this is to be expected when people are working off the server. Nor can you do anything to any folder directly above this file (e.g. You can’t rename it, you can’t move it, you can’t delete it. Windows on the other hand won’t do anything to any file with an open file handle. Unix is able to move, rename and delete files that are opened with a read-only file handle. These files opened in Read only mode are not an issue on a server running a Unix-type operating system. The symptoms are most apparent when we go into the Computer Management > Shared Folders > Open FilesĮven on a small network (10-20 workstations) there will often be thousands and thousands of open files, all open in Read mode. I’m still seeing this issue with macOS High Sierra 10.13.1 and 10.13.2 – it did look like it was initially fixed in 10.13, and the issue was definitely better, however now with more heavy use and newer updates, we’re back where we were before.
0 kommentar(er)
