Jump to content
Welcome to our new Citrix community!
  • 0

User Layer repair failed message on 1908


Jimmy Bouma-Holtrop

Question

I recently upgraded my ELM to version 1908, which I saw in the release notes has a change to the way the User Layer repair function works. 

 

I exported a couple of images from the ELM and updated the VMware pools those images serve. 

 

Now every time one of my users logs into one of those pools they get an error pop up that says "An attempt to repair your User Layer has failed. Please contact your system administrator." Under details the error says "Access to the path '\\unc\path\users\domain_username\vmname' is denied."

 

I'm pretty sure I made all the folder permissions correct when I set up App Layering a couple of years ago. Since initial setup I've never had any permissions problems. 

 

Anyone else seeing this error with the newest version of App Layering?

 

Thanks.

Link to comment

15 answers to this question

Recommended Posts

  • 0

I was having the same "user layer failed to repair" error after I was hot-fixed to 19.8.0.14. I found the log was referencing a folder name ending in _1809, instead of the _1803 folder my user layer actually existed in. I logged off, manually renamed my folder to _1809 at then end and the error stopped occurring. Figured I'd share for what it's worth. I still have an open ticket about it, awaiting to see if what I did is the best course of action for the rest of my users with _1803 folders. Luckily only 10!

Edited by dmcclai286
Link to comment
  • 0

Hi Jimmy,

 

Did you rename the OS layer when you did an upgrade.  The path is based on the OS layer name.  So if you wnat to change something when you upgrade use the version name not the layer name to define that.

 

Forget the above - what we actually do is use the layer id to find the user layer even though we show the name.

 

You didnt create a new os layer did you?  The user layer is ties to the os layer its created on.

 

So back to you should open a ticket to figure out what is going on.

 

Link to comment
  • 0

I can confirm that renaming the OS Layer does indeed cause this.

 

I renamed the OS Layer that the user layer was created against from "Win10 Ent" to "Win10"

 

After publishing an update the error occurs at every subsequent login the JSON file has the original name

2020-06-15 11:51:14,001 INFO 33 MachineIdentityService: ImageInfo path: C:\Program Files\Unidesk\Etc\ImageInfo.json
2020-06-15 11:51:14,001 INFO 33 MachineIdentityService: ImageInfo path: {"OsLayerId":6356992,"OsLayerGuid":"43a70946-58c1-4325-abbe-56e385689abd","OsLayerName":"Win10 Ent"}
2020-06-15 11:51:14,017 INFO 33 MachineIdentityService: ImageInfo: 6356992, Win10 Ent
2020-06-15 11:51:14,017 INFO 33 WindowsId: Finished impersonating NT AUTHORITY\SYSTEM
2020-06-15 11:51:14,017 INFO 33 UserLayerService: Searching for user layer for 'domain\someuser' using pattern '\\domain.local\dfs\Citrix_Dev_UserLayers\Users\domain_someuser\610000_*\someuser.vhd'
2020-06-15 11:51:14,064 INFO 33 WindowsId: Finished impersonating domain\someuser
2020-06-15 11:51:14,064 INFO 33 UserLayerService: Returning user layer path \\domain.local\dfs\Citrix_Dev_UserLayers\Users\domain_someuser\610000_Win10\someuser.vhd
2020-06-15 11:51:14,064 INFO 33 UserLayerAttachDetachService: Opening user disk '\\domain.local\dfs\Citrix_Dev_UserLayers\Users\domain_someuser\610000_Win10\someuser.vhd' for 'domain\someuser'
2020-06-15 11:51:14,064 INFO 33 UserLayerAttachDetachService: Open with lock timout '120' seconds, '5' retries if locked
2020-06-15 11:51:14,064 INFO 33 WindowsId: Impersonating domain\someuser
2020-06-15 11:51:14,111 INFO 33 UserLayerAttachDetachService: ExtendedDiagRetentionCount=5
2020-06-15 11:51:14,126 INFO 33 WindowsId: Finished impersonating domain\someuser
2020-06-15 11:51:14,126 INFO 33 VirtualDiskService: Attaching virtual disk '\\domain.local\dfs\Citrix_Dev_UserLayers\Users\domain_someuser\610000_Win10\someuser.vhd'
2020-06-15 11:51:15,439 INFO 33 WindowsId: Impersonating domain\someuser
2020-06-15 11:51:15,439 INFO 33 WindowsId: Finished impersonating domain\someuser
2020-06-15 11:51:15,439 INFO 33 UserLayerRepairService: Repair User Layer: user 'domain\someuser', uepFolder '\\domain.local\dfs\Citrix_Dev_UserLayers\Users\domain_someuser\610000_Win10 Ent'
2020-06-15 11:51:15,439 INFO 33 WindowsId: Impersonating domain\someuser
2020-06-15 11:51:15,439 WARN 33 UserLayerRepairService: Caught exception trying to repair user layer System.IO.DirectoryNotFoundException: Could not find a part of the path '\\domain.local\dfs\Citrix_Dev_UserLayers\Users\domain_someuser\610000_Win10 Ent'.

 

The User Layer is found and mounted via a wildcard search as seen in the above log excerpt. however for the repair rather than referencing the returned path it uses the path as per the JSON.

To avoid this you need to rename the folder paths in your user layer vhd store.

I would think it would be better for the application to utilize the mountpath discovered via the wildcard search as this is the actual mount path used for the layer.

 

Note that this is the same OS Layer, just a different name on a subsequent version due to OS Layer rename. The layer ID is unchanged.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...