Unable to create driver package - "specified folder doesn't exist or sms provider computer has no read, write or delete subfolders and files permissions to it". RRS feed

  • Question

  • When I try to create a drivers package I receive the error "The specified folder doesn't exist or SMS Provider computer has no read, write or delete subfolders and files permissions to it." I have added the system account to the share permissions with Full Control and that didn't resolve it.  I also added the SCCM server account into the share permissions with FC. Still no go.  I am running SCCM 2012 SP1 with a separate dedicated SQL server. Both servers are running Server 2008 R2.  Thanks in advance.

    Über Random

    Monday, April 8, 2013 6:53 PM

All replies

  • anything particular in the adminui.log?
    Monday, April 8, 2013 9:45 PM
  • Do you mean the SMSAdminUI.log file from E:\Program Files\Microsoft Configuration Manager\AdminConsole\AdminUILog ? If so the file hasn't been modified since 3/14. It has some items highlited in red that I have listed below.  That is the only AdminUI.log I could find.  Thanks.

    [14, PID:2232][03/14/2013 13:37:11] :Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException\r\nThe SMS Provider reported an error.\r\n   at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObject.Get(ReportProgress progressReport)
       at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlResultObject.Get()
       at Microsoft.ConfigurationManagement.AdminConsole.Conditions.MenuUtilityClass.EnableDisableCloseAlertMenuStatus(Object sender, ScopeNode scopeNode, ActionDescription action, ResultObjectBase selectedResultObject)\r\nConfigMgr Error Object:
    instance of SMS_ExtendedStatus
    Description = "Error retrieving object ID=16777224";
    ErrorCode = 2151811598;

    Über Random

    Monday, April 8, 2013 10:47 PM
  • Which system is hosting the share?

    Which system is hosting the SMS Provider?

    Jason |

    Tuesday, April 9, 2013 3:22 AM
  • The share is on a mounted NTFS volume (from our SAN) on our SCCM server (called SCCM2, which is running in a VM).  The SMS provider is also hosted on SCCM2.  Everything is hosted on the SCCM2 except for the reporting services which are hosted on a SQL server called SCCMDB2.  

    Über Random

    Tuesday, April 9, 2013 3:31 AM
  • What about NTFS permissions on the shared folder itself?

    For the driver import from location, The computer account needs read permissions on the share and the local System account needs read NTFS permission on the actual shared folder.

    For the driver package location, the computer account needs write permissions on the share and the local System account needs write NTFS permissions on the actual shared folder.

    Jason |

    Tuesday, April 9, 2013 4:17 AM
  • Everything is shared out from the Sources folder. The full path is E:\Sources\drivers\ with driverPackages and driverSource inside the drivers folder.  The sources folder has Full Control for Everyone, System, Administrators on the share and the Server account has read permissions.  For the NTFS permissions on sources System and the server account both have full permissions.  The driverPackages folder isn't share out but has inherited full permissions for system and the computer account.  Does the driverPackages folder need to be shared out separately? Thanks again for your help.

    Über Random

    Tuesday, April 9, 2013 11:19 PM
  • I am seeing the same error. "The specified folder doesn't exist or SMS Provider computer has no Read, Write or Delete subfolders and files permissions to it." 

    Everyone, SYSTEM, SCCM Administrators, the server with the SMS Provider installed (my SQL server) has been given Full Control permission to the share.

    It is running SCCM 2012 SP1 with remote SQL. All servers are running Win 2008 R2.

    Thursday, April 11, 2013 6:28 PM
  • I have exactly the same issue. I managed to solved it when I added a new package but I didn't take notes and now I'm facing again the same problem but I don't remember what I did to solve it ! Adding SYSTEM, SCCM Admin,... doesn't work. I tried to type the Ip address instead of the server name. No result... Any idea ?
    Monday, April 15, 2013 12:45 PM
  • I have also tried creating different shares on both the local C: and in a different location on the E: (not under the Sources share), and always receive the same error. Another admin in our group has a test SCCM 2012 server configured and he doesn't get any errors when he loads driver packages. I compared his permissions to mine and there were a few discrepancies:  his is shared out under E:\sources$\drivers, with the share permissions set to FC for everyone and the administrators group. He doesn't even have the system account listed in it. The NTFS permissions are set to Special (and then FC) for Creator Owner and admins. System has FC. He also has the users group added with read-execute, list folder content, read and special permissions. I have tried adding all of those permissions to my server (except for the Users group) and have tried using a hidden share as the root. Nothing has helped so far. I did notice that when I added the System account to the share permissions it had a little red up arrow indicating a Foreign Security Principle. I'm not sure if that is important or not. Anyone have any other ideas? Thanks.

    Über Random

    Wednesday, April 17, 2013 11:48 PM
  • I have the same issue.  I set up all the correct permissions on my server share "\\<My-SCCM-server-name>\Drivers\...", 

    I managed to work around it by setting the share path as "\\<My-SCCM-server-name>\E$\Drivers\..." (Where E is the drive letter where the share is physically located on my server).

    I realise that this isn't the cleanest, safest or most portable solution, but it worked for me when I was in a hurry.  Does anyone have a more permanent fix?

    Thursday, September 12, 2013 2:18 AM
  • I had the same issue it looks like an SCCM 2012 SP1 issue. As I tried bpeden's fix which worked.

    Friday, September 13, 2013 10:46 PM
  • Based on bpeden's workaround, I checked my share permissions (not NTFS perms).  I usually set it to Everyone:Change so I changed it to Everyone:Full Control and it worked.

    • Proposed as answer by Ridge111 Tuesday, April 7, 2015 8:04 PM
    Monday, October 7, 2013 10:25 PM
  • Had a similar issue just now on SCCM 2012 R2. Added SYSTEM to the share permissions on the share. Now it works again.
    • Proposed as answer by jcoltonj32001_ Wednesday, July 2, 2014 10:22 PM
    Friday, June 20, 2014 2:44 PM
  • Share permissions on the "Sources" folder (or whatever you have named your share) should give SYSTEM full control. Changed that and started working.
    • Proposed as answer by Kevin Saucier Thursday, July 30, 2015 1:08 PM
    Wednesday, July 2, 2014 10:23 PM
  • Share permissions on the "Sources" folder (or whatever you have named your share) should give SYSTEM full control. Changed that and started working.
    can confirm this, "Full control" for SYSTEM on share did the trick.
    Sunday, February 28, 2016 11:27 PM
  • Thank you so much, made my day ;)

    No reason for full access for everybody!

    Cheers Michael

    Wednesday, April 13, 2016 9:07 AM
  • Double confirmed!  Full control for SYSTEM on share.

    Shane Curtis

    Friday, October 28, 2016 8:12 PM
  • Same issue here, and thanks guys, it works like charm! :)

    Monday, April 17, 2017 3:06 PM
  • Did the full control worked for the problem. can anyone confirm.??
    Thursday, June 22, 2017 7:20 AM
  • I am also facing the same problem for the vlc application msi file deployment. the file is having the full control permissions. and given the right file path like \\server-name\share\file but again it is giving the same error. 
    Thursday, June 22, 2017 7:26 AM
  • First, this is meaningless: "the file is having the full control permissions."

    What has full control on the file? You need to specify the principals that have permissions on the file otherwise its meaningless.

    Also, this has nothing to do with this 14 month old thread, you need to start a new one and fully describe the technical details.

    Jason | | @jasonsandys

    Thursday, June 22, 2017 2:50 PM
  • I know this is an old thread but don't give "Everyone" full control on your share, it creates a security issue; just map the Admin$ and give the Server with the SMS provider role full control.
    Thursday, May 10, 2018 8:43 PM
  • That's incorrect. Everyone full is quite standard for share permissions because share permissions are not the only permission enforcement mechanism at play -- they are just the initial door. NTFS permissions are what you should actually use for your real security permissions -- they are the real security barrier.

    Using admin$ is the real security issue here -- admin shares should never be used for anything except one-off admin tasks.

    Jason | | @jasonsandys

    Thursday, May 10, 2018 9:47 PM
  • I'm afraid I must agree with Jason. Granting Everyone full control at the share level is quite common and standard practice for shares. You then apply ACL's using the NTFS permissions. This grants the granular control that you are desiring. And admin shares do carry inherent risks to them and should be used sparingly. 

    Über Random

    Thursday, May 10, 2018 9:53 PM
  • Don't be afraid.

    Jason | | @jasonsandys

    Thursday, May 10, 2018 10:05 PM
  • Can confirm this too, adding system on the NTFS and Share permission solved the problem
    Tuesday, November 13, 2018 9:47 AM
  • Thanks a lot! This works for me. 
    Tuesday, November 13, 2018 6:46 PM
  • Not sure if people are still having issues with this. 

    I'm new to SCCM and had the same issue with creating a driver package.  Checked all permissions and everything seemed to be correct, but still getting the same error, then spotted the following........

    I had moved the existing driver folder into the share I was planning to import to, I had then set the new folder name to be exactly the same! Thinking that this was the source location and not the destination.  Bit of a schoolboy error, but easy enough mistake to make for a newbie!

    Anyway I hope this helps anyone else looking at this thread in the future! 

    Wednesday, November 28, 2018 10:49 AM
  • Everyone Full on the share allows the owner of a folder to change permissions, even if NTFS permissions are only set to modify. This is not desirable.
    Wednesday, May 8, 2019 6:39 AM
  • No, that's incorrect. Share permissions dictate one thing and one thing one, the share and not NTFS permissions in any way. If you don't want someone to change NTFS permissions, don't make them the owner or allow them to create folders using *NTFS* permissions. Using share permissions to control and dictate NTFS based access is a problem waiting to happen.

    Jason | | @jasonsandys

    Saturday, May 11, 2019 2:16 PM
  • That worked for me as well... 


    Thursday, June 20, 2019 9:40 PM
  • If I give "Everyone Full Control" on the share, the owner of the folder then has Full Control NTFS permissions on the sub-folder he/she created (this, even when "CREATOR OWNER" has been removed from the ACL). It does not show up in the ACL, but the effective permissions exist. Therefore, I have had to place "Change" for Everyone on the share to prevent folder owners from having the ability to "Change Permissions".

    What do you mean by "Don't make them the owner"? Anyone who creates a folder is automatically the "Owner". Users do create folders using NTFS permissions, but that doesn't stop the folder owner from having "Full Control" NTFS permissions. The only thing that prevents this is by placing "Change" permissions for Everyone on the share.

    If you don't believe me, try it yourself.

    The "Owner" ALWAYS has the ability to change permissions on the object it owns.


    It's also mentioned several times here:

    So I was always taught to provide "Full Control" to everyone on the share, and then set NTFS permissions from there. It turns out to be incorrect, unless you want end users to be able to stuff permissions up everywhere.

    That is the problem waiting to happen.

    Thursday, September 12, 2019 7:04 AM
  • What end-users are relevant in this context?

    This thread is specific to drivers imported into ConfigMgr. If you are attempting to to make a point about anything other than this, then it's irrelevant for this thread.

    Thus, only a select set of admins responsible for making drivers available to ConfigMgr are the target of all discussions here. Anything else is off-topic as this isn't about some generic share, but a very purpose specific share that normal users don't have access to which should be restricted at an NTFS level.

    Also, this is incorrect: "Therefore, I have had to place "Change" for Everyone on the share to prevent folder owners from having the ability to "Change Permissions"." Changing NTFS permissions in dictated by the ownership of the files exactly as you pointed out and this has nothing to do with the share permissions. As noted, the context here isn't about random users creating files on a share, this is a purpose-specific shared folder.

    Jason | | @jasonsandys

    Thursday, September 12, 2019 3:20 PM
  • Giving users FULL CONTROL on a Share allows them to control the share, meaning if they want to they can delete the share. This is a common misconception about share permissions. Unless you want your users to be able to delete the share you never give them Full Control, you give them R/W and control afterwards via NTFS permissions what they actually can do.
    Thursday, January 23, 2020 4:03 PM
  • This is not correct. Deleting a share requires local admin permissions on the system hosting the share. Full Control on a share is about accessing the share itself and the folders/files behind it, not controlling the share's existence or properties.

    Jason | | @jasonsandys

    Thursday, January 23, 2020 4:41 PM