Create simple file share on the fly

[consultmac2]

I'm trying to find out how to define a file share on the fly
(assuming the capability is enabled) via a DOS (or other) command file/
script, or perhaps VB as a last resort.

I'd like to be able to take a user supplied directory on a local
drive and be able to temporarily (or perm) associate a file share with
it. I'm attempting to work with some compiled programs that I don't
have source code access to... that uses this technique to communicate
with spawned virtual machines (via virtual LAN).

Clues, or pointers?

Thanks

 

[Guest]

I would suggest using WMI. It is like VB script, but has libraries for just
what you are trying to do. Here is one way to do it:

http://www.microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0107.mspx

Vinson

 

[consultmac2]

Vinson,

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

 

[Guest]

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.

http://www.microsoft.com/technet/scriptcenter

/resources/qanda/jan05/hey0107.mspx

Vinson

 

[consultmac2]

Thanks again for the reference. It does seem like it should be
helpful.

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?

Thanks.

 

[Guest]

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...

http://www.microsoft.com/technet/technetmag/issues/2006/05/ScriptingGuy/

Vinson

 

[consultmac2]

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.

 

[Guest]

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
you.

Vinson

 

[Guest]

Here is the script I was using...

Const FILE_SHARE = 0
Const MAXIMUM_CONNECTIONS = 25
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

 

[consultmac2]

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:'
list!!!
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 $MAXIMUM_CONNECTIONS = 25;

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

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

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

 

[Guest]

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
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cacls.mspx?mfr=true

I bet this will do it. Good luck!

Vinson

In the above sample,

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:'
list!!!
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 $MAXIMUM_CONNECTIONS = 25;

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

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

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

Here is the script I was using...

Const FILE_SHARE = 0
Const MAXIMUM_CONNECTIONS = 25
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

 

[Marty K]

I'm trying to find out how to define a file share on the fly
(assuming the capability is enabled) via a DOS (or other) command file/
script, or perhaps VB as a last resort.

I'd like to be able to take a user supplied directory on a local
drive and be able to temporarily (or perm) associate a file share with
it. I'm attempting to work with some compiled programs that I don't
have source code access to... that uses this technique to communicate
with spawned virtual machines (via virtual LAN).

Clues, or pointers?

Thanks

Try the net share command from command prompt.
you can create bat file to run as needed

 

[consultmac2]

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
hoped.
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.

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 (asyou
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.http://www.microsoft.com/resources/documentation/windows/xp/all/prodd...

I bet this will do it. Good luck!

Vinson

In the above sample,

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:'
list!!!
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 $MAXIMUM_CONNECTIONS = 25;

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

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

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

...

read more »

 

[consultmac2]

Net Share !!!!

Thanks for the idea Marty. After hitting a roadblock again with the
WMI/perl code I was using, I was looking for a fresh idea.

Using something like:
net share shareName=c:\dirToShare
sure sounded attractive, but it didn't solve the problem completely by
itself.

Initially disappointed, I found that the Net share command created a
share without the 'Everyone' ACL, so my VMs could not access them.
However, when I added a call to the CACLS tool that Vinson suggested
earlier, I end up with a share that IS accessible just fine by my VMs.

Thanks!!!!!

(WMI/Perl code I was using:
sub processSharable{
my $dirtoshare = $_[0];
my $sharename = $_[1];

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

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

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

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