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.
Smbup remove share mac#
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). Confirm, that the lock has NOT been released.Ĭan anyone else confirm this behaviour on OS X 10.13.1?Ĭan anyone else confirm that this is NOT behaviour on versions of OS X older than 10.13.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.
Smbup remove share pdf#
Confirm there is a lock on the file on the fileserver.Ħ: Close the Preview application viewing the pdf file. Confirm that the lock has been released on the Samba server (smbstatus -locks").ĥ: Open the pdf from the Samba server with the default Preview application. Confirm there is a lock on the Samba server with "smbstatus -locks".Ĥ: Close the application (not Preview) with the PDF file open.
Open it with something other than Preview (The default). So, the real problem, is the Finder's lack of response to the user, but locks not getting released, makes the problem much worse.ġ: Disable all preview functionality in the Finder.Ģ: Browse to a PDF on you Samba fileserver.ģ. Often none of the user's data actually gets uploaded to the server (But they think it has been). To the users, it looks like the operation was completed, but it was not. If there are any locks on files/folders below the top folder, the request can not be completed, and the Finder (OS X) does not inform the user. Some users have a workflow, were they overwrite entire folder structures on the Samba server. This appears to be new behaviour to OS X 10.13.1. I think I have made sense of it: In OS X 10.13.1 the Preview application & preview functionality in the Finder, does not release locks (DENY_NONE) on files it has previewed from a (Samba) file server.
0 kommentar(er)
