Posted on 10-24-2013 11:24 PM
Casper Admin 9.2 gives an error when I tried to compile a configuration on OS X 10.9.
it says "The DMG could not be mounted. Please verify there is enough space on the distribution point."
Our Windows SMB distribution points have enough space on them.
I can compile configurations on OS X 10.8.x systems.
Posted on 10-26-2013 12:14 AM
Also compiled a 10.9 and tried to build but the machine doesn't boot or log in properly. I don't think JAMF tested this properly!
Posted on 10-26-2013 12:53 AM
What OS far you compiling it on? Via what method? (I thought you used InstaDMG).
Using 8.73 I was able to create a compiled config consisting of just the OS.
Boots fine. :)
Posted on 10-26-2013 09:44 PM
InstaDMG doesn't work with 10.9
Casper Admin 9.2 seeing as it's supposed to work with 10.9... It doesn't!
Posted on 10-26-2013 09:54 PM
InstaDMG doesn't work with 10.9
Casper Admin 9.2 seeing as it's supposed to work with 10.9... It doesn't!
http://www.afp548.com/2013/10/22/autodmg-a-modern-replacement-for-instadmg/
Posted on 10-27-2013 02:01 AM
Insta/Auto DMG .. Whatever.
I compiled on 8.73 using a mac running 10.8.5 from & to a Mac server hosted share running 10.8.5.
The config only had the InstallESD & the management account assigned.
Posted on 10-27-2013 02:57 AM
Off case Ben ;) this is Casper Admin 9.2 and OS 10.9
Posted on 10-28-2013 08:11 PM
JAMF identified it as a defect: D-005612
Posted on 11-10-2013 08:57 PM
Works on AFP share no problem for me
Posted on 04-09-2014 06:47 AM
I am having the same issue. Has this been resolved yet? I am using Casper 9.3 with AFP shares. @Kumarasinghe
Posted on 04-09-2014 04:30 PM
@bajankinch
I use AutoDMG now and it works really well.
Posted on 05-28-2014 12:56 PM
I have the same error on Casper Admin 9.31 and Mac OS X 10.9.3 with a Distribution Point on a Windows Server 2012 SMB share.
Is there a fix or work-around?
Thanks!
Posted on 06-11-2014 03:21 PM
Hey All,
Figured I'd toss an update here, since I noticed a case that is this same issue and found the thread through our notes.
This behavior is related to D-005612; it's something we see specifically with Windows SMB share points and is an issue between how Mavericks' SMB2 communicates with Windows SMB.
In some situations, when Mavericks is connecting to an SMB2 file share on a Windows machine, there can be problems with the permissions on the client side. This particular issue is almost universal on Windows Server 2008R2 SMB shares.
A common fix recommended online is to connect using CIFS:// instead of smb; this would force it to use the slower SMB1 protocol, but also would take care of the error. Currently, it looks as though this is the route our Development team is looking at to get the issue taken care of.
This thread on Apple's discussion forums goes into it a bit more: https://discussions.apple.com/thread/5467191
http://cammodude.blogspot.com/ has posted a workaround to force use of the SMB1 protocol, but it's a use at your own risk workaround, as we have not tested it thoroughly here. If you do try out that workaround and it's successful, please let us know!
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 07-24-2014 08:52 AM
Has there been any progress on getting this to work with SMB2?
Posted on 07-24-2014 09:00 AM
It's one we're still working on, as this is a third party issue; specifically, it's an issue with Mavericks' SMB2 not passing credentials in a way that the version of SMB Windows 2008R2 uses is willing to accept.
At the moment, development is still looking into ways to get around it, but as the issue appears to be at the OS level on both sides, unless something changes on Apple's side or Microsoft's side, it could take a bit more digging to find out how we can get it working reliably without messing anything else up or having to force it to use the slower SMB1. The way it looks right now, we may end up having to force it to use the older protocol unless Microsoft decides to release an update for 2008R2 (which isn't all that likely) to address it.
The error message Casper Admin gives isn't exactly the best in terms of wording, but it really has nothing to do with actually being out of disk space in this particular situation, it has to do with the Windows SMB share rejecting the way the credentials are passed down from Mavericks using SMB2, which is why the DMG can't be mounted.
As I'd mentioned in my reply on June 11th:
In some situations, when Mavericks is connecting to an SMB2 file share on a Windows machine, there can be problems with the permissions on the client side. This particular issue is almost universal on Windows Server 2008R2 SMB shares. A common fix recommended online is to connect using CIFS:// instead of smb; this would force it to use the slower SMB1 protocol, but also would take care of the error. Currently, it looks as though this is the route our Development team is looking at to get the issue taken care of. This thread on Apple's discussion forums goes into it a bit more: https://discussions.apple.com/thread/5467191 http://cammodude.blogspot.com/ has posted a workaround to force use of the SMB1 protocol, but it's a use at your own risk workaround, as we have not tested it thoroughly here. If you do try out that workaround and it's successful, please let us know!
If you have any additional questions regarding the defect (D-005612) behavior, or would like to have a case created to get it attached to the defect for tracking, please get in touch with your Technical Account Manager by giving them a call, sending an e-mail to support@jamfsoftware.com, or by using the My Support section of JAMF Nation.
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 07-24-2014 11:19 AM
Hey all,
Just to make sure it doesn't get totally missed, there's another JN thread going about the general issues with slowness, failure to mount SMB shares,...
For those who would prefer to not click the link, this info may be relevant to trying to get Casper Admin to be able to work a bit better in environments where we have a Windows share point:
https://discussions.apple.com/thread/5483728 One poster there mentioned that doing the following helped in their environment: - Set Lan Manager Authentication Level to "Send NTLMv2 response only" - Connect from the client without specifying a domain, just enter the shortname and password. There are some of the longer discussions on the matter on Apple’s discussion forums, most of them having been started last fall and a good chunk of them still being active until very recently; I haven’t had time to go through all of the pages, but mixed in with the ‘me too!’ replies, there are things others have tried to try and get it working in the thread below. It looks like the most common workarounds out there are the ones that have already come up here, but there were some Windows side workarounds that may be worth looking into. https://discussions.apple.com/thread/5500165 <— this one has a few different settings to change on the Windows side of things, usually through PowerShell. Sweetcider went into a little more detail on the changes made in PowerShell. A couple people there said enabling “Force NetBios over TCP/IP” on the Windows side helped the speeds in their environments. On page 6 of that thread, the user Jorge Secco Caetano posted a couple of registry keys to try changing as well; a couple users reported having success with that, so it may be worth looking into. User ncalliari expanded on that with the DWORD values that were necessary.
Amanda Wulff
JAMF Software Support
Posted on 07-24-2014 07:23 PM
I did use the SMB1 modification today and that got around the error, but after 8 hours of compiling I decided to revert back to autoDMG to compile my OS installer.
Posted on 09-05-2014 05:51 AM
http://cammodude.blogspot.com/ has posted a workaround to force use of the SMB1 protocol, but it's a use at your own risk workaround, as we have not tested it thoroughly here. If you do try out that workaround and it's successful, please let us know!
I can confirm that Workaround Option 2 worked for me.