Re: Create simple file share on the fly

Using a system call to perform the cacls function was a good idea.
Thanks. While it did help in the long run, just adding it to my
previous script did not make the folder completely accessible as I'd
It did indeed seem to add the 'Everyone' group, but the folders
continued to be resistant to access from within the VMs.

The good news is that the call to the cacls tool is part of the
final solution. See my reply to Marty K.

On Sep 14, 4:54 pm, Vinson <Vin...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I believe you have provided the answer to this mystery. =D

If you programatically add the 'Everyone' Group to the Folder, I bet it
works. There are fancy coding methods to change security descriptors (as you
have seen), but why not shell out of your Perl script and run a DOS command
that will apply the group "Everyone" to your folder after you create your
share? I believe it would be easier than tinkering with Security
Descriptors, in WMI script.

CACLS.EXE <---- The Tool

cacls "c:\sampledir" /t /e /c /g Everyone:F

The sample command above would apply the group 'Everyone' to the folder
SAMPLEDIR with full NTFS permissions which would also be applied to all the
files in the directory. Be sure to always use the /E argument, or you will
replace all DACLs with a single entry rather than edit them. Be sure to
quote directories or files that have spaces such as "C:\Program Files."

Here is a reference for the command.

I bet this will do it. Good luck!


In the above sample,

"consultmac2" wrote:
Thanks for the idea of trying it between two computers rather than
using just between the VMs and the host computer.

Whether or not that's what made me discover another difference or
not.... I have discovered another difference between the permissions
on the two types of shares (created manually via the GUI versus
created through use of the script sub below...).
The handmade shares show four items under the 'Group or user
names:' pane in the Security tab of the properties sheet:
Administrators (xyz\Administrators), Barry (xyz\Barry), Everyone and
SYSTEM. These are shares that are accessed sucessfully from VMs and
other computers.
BUT.... The shares that are created by the script sub below are
missing the 'Everyone' entry in that 'Group or user names:'
When I manually add the everyone group to the list, those shares
are accessible from the VMs and other computers. What's going wrong
with the script, I wonder!!??!!

Below is the sub, in Perl, that I'm using.

sub processSharable{
my $dirtoshare = $_[0];
my $sharename = $_[1];

my $FILE_SHARE = 0;
#my $mynode = Win32::NodeName();
my $strComputer = '.';

my $objWMIService = Win32::OLE->GetObject('winmgmts:\\\\' .
$strComputer . '\\root\\cimv2');

my $objNewShare = $objWMIService->Get('Win32_Share');

my $errReturn = $objNewShare->Create ($dirtoshare, $sharename,
$MAXIMUM_CONNECTIONS, 'Public share for Fabrikam employees.');

On Sep 14, 2:20 am, Vinson <Vin...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Here is the script I was using...

Const FILE_SHARE = 0
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set objNewShare = objWMIService.Get("Win32_Share")
errReturn = objNewShare.Create _
("C:\test", "Test", FILE_SHARE, _
MAXIMUM_CONNECTIONS, "I nice new share.")
Wscript.Echo errReturn

"Vinson" wrote:
I accept that there must be a subtle difference when creating the share
manually versus WMI, but in tinkering, I cannot reproduce the problem. My
WMI share routine faithfully works. Of course, I am not using Virtual
Machines here to connect; I am using an actual XP Workstation. I wonder if
WMI is having a problem in creating the share, but it has no way to report it
to you. You can place the command line below as the final line in your WMI
script to report any latent errors. It should return 0 if all is well, and
some other number if it is not.

Wscript.Echo errReturn

Other errors:

2 = access denied
8 = unknown problem
9 = Invalid Name
10 = Invalid Level
21 = Invalid Parm
22 = Share Already Exists
23 = Redirected Path
24 = Missing Folder
25 = Missing Server
(Anything else means the operation could not be completed).

You might experiment with actual workstations to see if the script is
working, or if it fails in every instance. Since I cannot reproduce the
trouble, I am not sure what else to suggest. You might also post the salient
portions of your WMI script if you want others to test it or debug it with


"consultmac2" wrote:

Thanks again Vinson, especially for the "." alias.

I'm familiar with the concepts of security descriptors from other
platforms and remembering some experience I had with it under NT4.. I
went through most of the article whose URL you gave me , and a linked
article, as refreshers.
But no matter how I compare the shares made through the script with
the shares that I make from the Windows GUI, I can't find a difference
in any of the Security decriptor settings between them.... even down
in the advanced levels.

But I found another clue to a possible difference. As I said,
when using the script generated shares, none of the vmware virtual
machines (VMs) that reference said share can successfully read
anything in it. But one of the VMs attempts to map the share to a
drive letter (T:) to use instead. When it hits that line (A 'NET
USE...' command) it throws up an error that the username and password
for that share are invalid (I'm paraphrasing)... and the 'NET USE....'
command isn't including a username at all. But that command works
fine in that VM when attempting to map a share that I 'hand made' via
the GUI.
Soooo, I deduce that the script is creating shares that have at
least some subtle difference in the username and/or password
attributes when compared to the ones that I create via the GUI.
Perhaps the GUI-created ones make some assumptions that the script
does not.
Any ideas down that path? I can't see those attributes reflected
anywhere in the Security tabs of the Properties on those shares. If
the script can't be made to function differently in this regard,
perhaps there's a way to refer to the shares in the VMs in a more
flexible way... to account for the differences. ?

Thanks again.

On Sep 12, 11:26 pm, Vinson <Vin...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
There is a simple way to specifiy that the script use the name of the
computer it is being run on. Simply use a period instead of the computer's
name, like so:

strComputer = "."

There is also an environment variable called COMPUTERNAME in virtually every
version of Windows which can be pulled easily into any program. This
variable will obviously have the computer name in it. Drop to DOS, and type
SET to see all the environment variables, listed.

Security Descriptors (rights and permissions) gives me a headache, but
fortunately, there is an article for that, too. Shares have both rights and
permissions, and if you need to change them on the fly, this article should
help. Here ya go...


"consultmac2" wrote:
Thanks again for the reference. It does seem like it should be

Indeed, I've translated it to perl (ActivePerl) and it does create a
share by the name that I specify, on the folder that I specify. The
thing I'm doing differently than in the example is that I specify my
local computer's name in place of the 'remote' computer's name (since
the example called for creating the share on a remote computer, and my
requirement is different).
Follow-up question #1: Is there a more efficient way to do this for
a folder on the local computer than probing for the computer's name
and specifying it in the place of the 'remote' computer's name?
More important question #2: Could there be something to do with
privileges or rights that I'm not handling with that script? If I
create the share manually via the Windows GUI, the VMWare virtual
machines can access files within that folder/share. But when I have
the script create it, the VMWare virtual machines all fail to be able
to see inside it. Perhaps its related to referring to my local
computer in a 3rd-person fashion? or not?


On Sep 11, 10:06 am, Vinson <Vin...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I do see that the link wraps in my original post, but it still works for me.
The mechanics of these forums can be strange.

Below, I have cut the original link in half. You will have to reassemble
the link below by cutting and pasting the first half to the second. Hope
this works.



"consultmac2" wrote:

Thanks! However, I can't tell which issue you are especially
recommending since the URL was cut off. See below. Can you

On Sep 10, 10:48 pm, Vinson <Vin...@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I would suggest using WMI.


read more »


Relevant Pages

  • Re: Create simple file share on the fly
    ... using just between the VMs and the host computer. ... The handmade shares show four items under the 'Group or user ... The shares that are created by the script sub below are ... You can place the command line below as the final line in your WMI ...
  • Re: Create simple file share on the fly
    ... If you programatically add the 'Everyone' Group to the Folder, ... Descriptors, in WMI script. ... The sample command above would apply the group 'Everyone' to the folder ... The handmade shares show four items under the 'Group or user ...
  • Re: cant get access to disk share when connecting from a remote s
    ... "To set permissions for users who access this folder over the network, ... The origianl script attached here was my ... shares. ... >> account being used to the local administrators group on the DUT. ...
  • how to copy share permission to an other share
    ... I'm trying to make a script to migrate the shares from one server to ... so far i'm able to create the new folder and share but i can't seem to ...
  • [kde] Re: plasma-desktop (KDE factory) acting up?
    ... example is another logging plasmoid that shows the output of a little ... script that outputs the state of my four drives every ten seconds. ... I have the group set to wheel for the logs I want to be read by trusted ... folder with pictures of people, and a subfolder with pictures of myself. ...