Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, April 8, 2013 6:53 PM | 1 vote
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
All replies (35)
Monday, April 8, 2013 9:45 PM
anything particular in the adminui.log?
Monday, April 8, 2013 10:47 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
Tuesday, April 9, 2013 3:22 AM
Which system is hosting the share?
Which system is hosting the SMS Provider?
Jason | http://blog.configmgrftw.com
Tuesday, April 9, 2013 3:31 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 4:17 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 | http://blog.configmgrftw.com
Tuesday, April 9, 2013 11:19 PM
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
Thursday, April 11, 2013 6:28 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.
Monday, April 15, 2013 12:45 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 ?
Wednesday, April 17, 2013 11:48 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
Thursday, September 12, 2013 2:18 AM | 2 votes
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?
Friday, September 13, 2013 10:46 PM
I had the same issue it looks like an SCCM 2012 SP1 issue. As I tried bpeden's fix which worked.
Monday, October 7, 2013 10:25 PM | 5 votes
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.
Friday, June 20, 2014 2:44 PM | 4 votes
Had a similar issue just now on SCCM 2012 R2. Added SYSTEM to the share permissions on the share. Now it works again.
Wednesday, July 2, 2014 10:23 PM | 9 votes
Share permissions on the "Sources" folder (or whatever you have named your share) should give SYSTEM full control. Changed that and started working.
Sunday, February 28, 2016 11:27 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.
Wednesday, April 13, 2016 9:07 AM
Thank you so much, made my day ;)
No reason for full access for everybody!
Cheers Michael
Friday, October 28, 2016 8:12 PM
Double confirmed! Full control for SYSTEM on share.
Shane Curtis
Monday, April 17, 2017 3:06 PM
Same issue here, and thanks guys, it works like charm! :)
Thursday, June 22, 2017 7:20 AM
Did the full control worked for the problem. can anyone confirm.??
Thursday, June 22, 2017 7:26 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 2:50 PM
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 | http://blog.configmgrftw.com | @jasonsandys
Thursday, May 10, 2018 8:43 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 9:47 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 | https://home.configmgrftw.com | @jasonsandys
Thursday, May 10, 2018 9:53 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 10:05 PM
Don't be afraid.
Jason | https://home.configmgrftw.com | @jasonsandys
Tuesday, November 13, 2018 9:47 AM
Can confirm this too, adding system on the NTFS and Share permission solved the problem
Tuesday, November 13, 2018 6:46 PM
Thanks a lot! This works for me.
Wednesday, November 28, 2018 10:49 AM
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, May 8, 2019 6:39 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.
Saturday, May 11, 2019 2:16 PM
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 | https://home.configmgrftw.com | @jasonsandys
Thursday, June 20, 2019 9:40 PM
That worked for me as well...
MCSE
Thursday, September 12, 2019 7:04 AM
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.
See:
https://arstechnica.com/civis/viewtopic.php?f=21&t=1157573
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 3:20 PM
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 | https://home.configmgrftw.com | @jasonsandys
Thursday, January 23, 2020 4:03 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:41 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 | https://home.configmgrftw.com | @jasonsandys