New issue
Advanced search Search tips

Issue 625883 link

Starred by 2 users

Issue metadata

Status: Archived
Owner: ----
Closed: Jul 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Chrome within a VMware AppVolume will not allow extensions to be installed

Reported by darkschn...@gmail.com, Jul 5 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0

Steps to reproduce the problem:
1. Spin up linked clone
2. Assign Chrome AppVolume (packaged separately from the OS)
3. Login
4. Open Chrome
5. Install Extension
6. "COULD_NOT_GET_TEMP_DIRECTORY" error appears

What is the expected behavior?
Installation of extension without complaining.

What went wrong?
This is similar to the following: https://bugs.chromium.org/p/chromium/issues/detail?id=413889

At this point application layering is gaining a lot of traction in business, so the need to be able to "roam Chrome" is becoming a must. I realize you can use an authenticated account and roam these things through Google, but in an effort to simplify user configuration within the model of application virtualization, this needs to be a setting that we can configure as engineers.

As it stands currently, because Chrome downloads/unpackages to the TMP defined variable, in an environment that is virtualized at application layer, in addition to OS layer, I cannot release Chrome as a managed application to our end users. 

Is there any way to modify this somehow? This creates a much larger management point for this application, as it would need to be part of the base image to not be affected by this.

WebStore page: 

Did this work before? No 

Chrome version: 50.0.2661.87 m  Channel: stable
OS Version: 10.0
Flash Version: 22.0.0.192

Virtualization is evolving. This needs to catch up.
 
This describes the same issue I'm seeing.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2128266

I moved to the latest version of Chrome, and tried moving it to the image, but since it's still using a writeable volume, I can't get around this. The workaround they are describing doesn't really work. Can Chrome's behavior not be changed to ignore this and work correctly? I don't understand why you would want to cripple this product in this manner.
Project Member

Comment 2 by sheriffbot@chromium.org, Jul 12 2017

Status: Archived (was: Unconfirmed)
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment