Video Screencast Help

Virtual Layer Folder Permissions

Created: 11 Apr 2014 • Updated: 18 Apr 2014 | 11 comments
SonicGT's picture

I have a software program that I want to utilize in a virtual layer.  The folder I'm placing the files for the program is under program files which standard users do not have rights other than read.  I need to specifically make the folder have full control for users.  When I do this to the folder before adding it to the layer it does not appear to retain this information.  What do I have to do in order to set permissions?   When I used to make this into an MSI within the MSI I can do it, and would rather get away from having to create msi's for this app since its just an easy folder of files and shortcut.

Operating Systems:

Comments 11 CommentsJump to latest comment

SK's picture

You may have to run a post import/activation action that runs acls.exe in order to do this.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

SonicGT's picture

I tried to add an autorun to the package, not sure where that runs in association with activate/import etc, but it didn't seem to work.

If I write a script to wrap the import and activate it works, but then when I deactivate the layer all the files stay.  It's as if since the files were modified rights outside of the layer they now become physical vs virtual.

 

Thoughts?

EdT's picture

Can I ask what permissions you are setting specifically?  Are you applying local or domain based permissions? Are you applying permissions at user or group level?  Is this a corporate enterprise where you could configure permissions using group policy (for example).

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

SonicGT's picture

I am attempting to give full permissions to users or everyone for a folder c:\program files\myappfolder

We do have GPO but it's like pulling teeth to get our AD team to let us use it for this type of thing, so since it is only 1 folder I'd rather find a local solution.  Plus some users who get this app are disconnected users and gpo doesn't always work the best for them.

EdT's picture

It appears your application does not conform to Microsoft best practices as no modern application should need write permissions under program files. Would the application still work if installed under <userprofile>\appdata ?

Otherwise, you could try creating a folder under program files in the base, applying permissions to the folder, then installing the application under the permissioned folder so that it inherits the permissions when the layer is activated.

 

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

SonicGT's picture

This is a custom developed application and is required to be in program files as well as have write permissions.

EdT's picture

Looks like you are caught between a rock and a hard place. I don't see any way of achieving what you need as your AD team are unhelpful and your developers are unaware of basic programming techniques for moderm windows apps.

Recommend you just install in the base O/S until one or both of your obstacles are addressed. Virtualisation is not a "fix all" for badly written apps unfortunately.

On further thought, one idea does occur to me. Have you considered using junction points to fake the location of the application folder?  Not sure if this will work in SWV but maybe worth playing with to find out?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jason.f's picture

I just tested this on an app I have packaged in SWV and if you do File > Add to Layer > run c:\windows\system32\cmd.exe and then set permissions using xcacls it does propagate when the package is exported and then reimported on another machine.

EdT's picture

@jason.f

Did you need to add xcacls.exe to the layer as well or was this used from the base?  Having said that, isn't xcacls not present in the default windows fileset?  I know cacls.exe is in the standard windows O/S but IIRC xcacls.exe is only in the resource kit and needs to be included manually. I just scanned my Win 7 installation and there was no evidence of xcacls.exe in the windows folder tree.

On the other hand, I would say that for most cases, cacls.exe is perfectly adequate.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

jason.f's picture

I've used both cacls.exe and xcacls.exe, either one works fine. I tend to either copy xcacls into my image or run it directly from the resource kit I have saved on my deployment share. No need to copy it into the layer/package. Also, I have some DS jobs that need xcacls so I usually end up copying it to the system folder so almost all of our machines have it locally.

I agree cacls.exe works perfectly fine even though it's been deprecated and MS suggests Icacls which isn't as easy to use as cacls.

Jason

Connell's picture

I have had success with going into C:\fslrdr on the composer machine and rightclicking the filder in the RO layer and setting the users to have r/w/execute permissions that way and then compiling.

 

These security settings seem to translate over to the client machines, but YMMV of course.