July 20, 2011 at 5:36 am
Solution found!
It turned out for mount points there are two 'security' tabs that you can set up access rights for different accounts.
Please see attachment "old_security_tabl.jpg": the first 'security' tab from right clicking the folder icon of 'S:\SQL\userdbdata01' and selecting ''properties". This is where I set up all the "full control"'s that I thought should have worked.
Please see attachment "properties_button.jpg": the property button that you can use to pop up another property setting dialog box when you can set 'security' again (see attachment 'new_security_tab.jpg').
And it turned out all the access right settings on the new security tab are substantially different from those configured on the old security tab. And unsurprisingly, the SQL Server service account (and the local windows group it belongs to) does not have full control over S:\SQL\Userdbdata01\ folder.
Bazinga!
July 20, 2011 at 5:42 am
S is a physical drive on the box and not a connected drive ?
strange .... verry strange
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
July 20, 2011 at 5:51 am
ALZDBA (7/20/2011)
S is a physical drive on the box and not a connected drive ?strange .... verry strange
By 'connected', you mean SAN?
Mount points are administered in my company by windows admins. And they appear in Windows as folders such as the one you've seen in the post S:\SQL\userdbdata01\.
Bazinga!
July 20, 2011 at 9:55 am
sqlapprentice (7/20/2011)
ALZDBA (7/20/2011)
S is a physical drive on the box and not a connected drive ?strange .... verry strange
By 'connected', you mean SAN?
Mount points are administered in my company by windows admins. And they appear in Windows as folders such as the one you've seen in the post S:\SQL\userdbdata01\.
On, that reply was my bad. You already stated it were mount points. :blush:
( Luns are handled as local drives )
I meant drives allocated with "net use ..."
Maybe you could check to log on with the service account and see what errors it comes up with when you try the drive.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
July 21, 2011 at 6:51 am
sqlapprentice (7/20/2011)
Solution found!It turned out for mount points there are two 'security' tabs that you can set up access rights for different accounts.
Please see attachment "old_security_tabl.jpg": the first 'security' tab from right clicking the folder icon of 'S:\SQL\userdbdata01' and selecting ''properties". This is where I set up all the "full control"'s that I thought should have worked.
Please see attachment "properties_button.jpg": the property button that you can use to pop up another property setting dialog box when you can set 'security' again (see attachment 'new_security_tab.jpg').
And it turned out all the access right settings on the new security tab are substantially different from those configured on the old security tab. And unsurprisingly, the SQL Server service account (and the local windows group it belongs to) does not have full control over S:\SQL\Userdbdata01\ folder.
Glad you found a solution for it, and thanks for posting what it was (so many people forget to do that).
The reason I asked what the type of drive was is because network and SAN mount-point drives behave differently than local and LUN drives.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 29, 2012 at 5:21 pm
Verify the SQL Server service and make sure its running under Administrator Accounnt.
Example:
I just completed installing SQL Server 2012 on one of our test server with NT Service\SQLSERVER.
I try to create a snapshot and it blows away.
So i have changed both SQLServer and SQLServer Agent services to appropriate Administrator Account and restarted both services and i am able to create a Snapshot.
Cheers,
Srihari
November 29, 2012 at 11:49 pm
This thread is over a year old!!
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
November 30, 2012 at 12:15 am
Srihari Kagita (11/29/2012)
Verify the SQL Server service and make sure its running under Administrator Accounnt.Example:
I just completed installing SQL Server 2012 on one of our test server with NT Service\SQLSERVER.
I try to create a snapshot and it blows away.
So i have changed both SQLServer and SQLServer Agent services to appropriate Administrator Account and restarted both services and i am able to create a Snapshot.
Cheers,
Srihari
Since this old post is brought back to life (probably because this gentleman encountered similar issues), I have to state that for security reasons not all organization will allow sql server service accounts to have local windows admin privileges. And in the case mentioned in my original post, the local windows admin account solution is obviously an overkill.
Bazinga!
December 24, 2015 at 11:58 am
You are a god amongst men....this has been driving me mad all day.
Cheers my friend...happy xmas!!
Viewing 9 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply