Hi all- We're being asked to run MC 2018.12.15 along with Mimiq (now owned by Hedge) to facilitate bin locking on third-party storage. Mimiq only runs on MacOS 10.15 (Catalina) or later, while Avid's compatibility docs claim that 2018.12.15 is only supported up to MacOS 10.14 (Mojave) and doesn't list any later OS versions. Is anybody successfully

Thanks for confirming! I'm not a developer, so I'm just speculating, but it would seem the issue is related to or caused by small file I/O operations. Is anybody from Avid on this thread? Any Nexis product managers? I have a support ticket open with Avid now about this issue, but would love to know that somebody's paying attention. We desperately

We're still on an older Dell switch, but I can't see how that could precipitate a kernel panic (I'm open to explanations.) For what it's worth, I can tell you that I was able to change the problem behavior by removing extended attributes attached to files on the MacOS filesystem. In our case, we could reliably crash the machine by attempting

Hi all- Just want to confirm whether anyone else is seeing this behavior: Apple Mac Studio, M1 Max, 64GB RAM, MacOS 12.4 (build 21F79) with Avid Nexis Client version 22.5.0 installed, using the built in Ethernet interface to connect to the Nexis subnet Server version 21.12.0.85 The Mac Studio kernel panics during Finder copy operations... so far, just

When working on Nexis shared storage, Media Composer creates folders inside /Avid MediaFiles/MXF/ that are named after the computer you're working on. This prevents confilcts with other computers accessing that same Nexis workspace and creating their own media folders. For example, if your computer is named "edit1", Media Composer will

Thanks for posting this! Does v2022.5 still require kernel extentsion approval? I believe this can be accomplished with certain MDMs with Intel machines... -Ryan

Hi Jon- Thanks for the update... In our application we can't spontaneously unmount/mount the workspaces without breaking another service, so we'll have to wait for a fix. In the meantime, I think I'm running up against the same kernel panic behavior in MacOS that you described. Seems to be related to lots of fast, small, I/O, but not entirely

Hello again- Just want to confirm that I've replicated those same steps (create file, move file, read file) and I'm seeing the same behavior. I've rolled back our version from 2021.12.0.85 all the way back to 2019.2.2 and it's still doing the same thing. If there's a fix or a workaround, I'd love to hear it. Are there any fuse

I don't have an answer, but I wanted to chime in to say I've seen the same behavior on a Linux client. Same version: 2021.12.0.85 In my case, it seems like some file system updates made by other clients don't appear on the Linux client until the workspace is unmounted and mounted again. I haven't been able to establish a pattern- whether

Hi Brad- You can use the Nexis API to retrieve a list of workspaces, then mount them on the Linux machine. Depending on how often you create/remove workspaces, you may consider mounting each workspace one at a time, backing it up, then unmounting it beofre proceeding with the next one. The Nexis System Director will allow you to delete a workspace even