![]() Process took 0 minutes and 1.092 secondsĠ2:38:38.475 : Filament required: 398.4mm (1.0cm3)Ġ2:38:38.585 : Unable to find an entry point named 'glGenBuffers' in DLL 'opengl32.dll'.Ġ2:38:42.609 : Communication timeout - reset send buffer blockĠ2:39:22.686 : Communication timeout - reset send buffer blockĠ2:40:02.762 : Communication timeout - reset send buffer blockĠ2:40:42.839 : Communication timeout - reset send buffer blockĠ2:41:22.915 : Communication timeout - reset send buffer blockĠ2:42:02.983 : Communication timeout - reset send buffer blockĠ2:42:43.060 : Communication timeout - reset send buffer blockĠ2:42:46.289 : Starting object analyser. Cheers.02:38:30.971 : Starting object analyser. I then added the other users that might use the Linux or Win11 systems and poured myself a cold one. Sudo dscl /Local/Default append Groups/.23 GroupMembers īAM!! The Linux system mounted right up! Then the Win11 system too! I also found that I didn't need to add users to every share, both raids mounted fine. sudo dscl /Local/Default append Groups/.23 GroupMembership ![]() On a whim I chose one of these 'raid' groups and substituted its RecordName in the dscl commands from the solution above. The Solution: I used the Mac Directory Utility to look into the Local Groups directory and saw that there indeed was NOT a SMB entry with RecordName = _smb, but rather a bunch of (8-9) entries for each shared resource, which had in the RecordName .NN (NN=2-digit number). ![]() ![]() I circled back to it today and decided to look harder at why they didn't work. I had run across this SE topic, but the dscl commands failed, so I moved on. I tried for 2 days to fix, but couldn't find a solution. Most machines were able to mount the shares, except for the one Win11 and Linux machines. The Problem: We upgraded the Mac Mini to Monterey (12.5) and that's when the trouble started. Two exceptions were one win11 machine and the Linux machine, both of which could only mount using the ip addr. Prior to the problem, most network machines mounted the drive using the qualified machine name (e.g. The Linux machine is listed in the AD system and uses the Azure DNS server, but is not joined to the domain for auth purposes - it uses local auth only. We use the AzureAD that comes with O365 for authentication of the Win machines and also have an Active Directory server in Azure that is synced with the O365 AD and also serves as our DNS master, which is used by the Macs and some other devices. We have Mac clients on several different OS versions, Win clients on several OS versions and a Linux client running Ubuntu 20.04 on the network. My config: I have a 2014 Mac Mini server with 2 raid shares that we use on various machines within our company network. My problem manifested a little differently, but I think it had the same underlying cause (whatever that may be). I want to chime in here, in case this can help someone else! I tried the solution above from but it didn't work for me HOWEVER, it did lead me to a similar solution that did work for me.
0 Comments
Leave a Reply. |