What are the permissions for the WinAdmins on the 'file server' - can you look at the agent log there?
And... can you post the specific error message / screenshot ?
Here is the error message:
This error message was precisely the same for both jobs I'm about to discuss. Both jobs are now functional, but I'm left with more questions than answers.
First, the WinZip job. You asked about permissions on my fileserver, which led me to make a change to my "exports" file that I'd been meaning to make for a while now.
I changed the old file from:
The user "bluser" is the user that the windows share has privlidges mapped to. This is the only change I made to my system and the WinZip job started working. My "users" file was (and is) completely blank. The "users.local" file simply maps BLAdmins to administrator.
Prior to the change to the "exports" file, I only saw BladeLogicRSCD@MBBLFS001 mapping to administrator@MBBLFS001 using the BLAdmins role. Now I see BladeLogicRSCD@ mapping to bluser@ under the WinProv role as desired.
A second job I was having this exact problem with was a registry merge job. I had two .reg files loaded into the Depot and dropped into a BLPackage. I added external commands for merging the registry files with the "reg" command. Again, the depot file and deploy job were initially created under a BLAdmin role. I then assigned permissions to WinProv for this just as with the WinZip job.
When I ran this job as WinProv, I got the exact same behavior noted for the WinZip job. I figured that whatever was wrong with Winzip was also wrong with the registry merge job.
When Winzip began working (presumably due to changes noted above), I gave my registry merge job a go. It still failed for the same reasons. I rebuilt the job from scratch (using BLAdmin role again) after re-importing the registry files into the Depot. I assigned the same permissions to the job as it had before and ran it as the WinProv role. ....It worked....
With all of that said, I'm left with two basic questions.
- Does the changes to the exports file explain why the Winzip job began working with no other changes made to anything?
- Is it possible for BLPackages to become...corrupt...after a time and need to be rebuilt? If not, what else could possibly explain why a newly built job using the same permissions, same files, same everything would work when the one sitting in the depot for 5 months worked for one role, but not another?
Any insights into these issues is greatly appreciated.
1 of 1 people found this helpful
This is mostly agent acls...
The users.local file is an override to exports and users, so when you were doing things as BLAdmins, you were accessing the file server as 'Administrator'.
When you were doing things as WinAdmins you were getting mapped to 'Anonymous" (no user=) and additionally, you had only read only access (ro).
On the file server only, you should typically put something like "<appserver host/ip> rw,user=<fs user name>" so connections from your appservers are mapped to the user that has permissions on the 'storage' directory. then your users and users.local file will be blank. This means you cannot (and should not) manage the file server system like you would another box (patching, deployments)
for #2 - it's possible for things to get corrupted, but I wonder if this was an underlying (ntfs) permission issue. assigning the permission in the CM gui does not change the ntfs (or other) file permissions under the covers. were you getting the same error for the reg keys? (btw, you can package reg keys directly w/ a blpackage)
I was getting the exact same error with the regkey job both before and after the file server "exports" fix. However, this isn't the first time I've seen a job that had previously been working suddenly stop working for no foreseeable reason. On every occasion, simply creating a new version of the BLPackage using the same resources and permissions fixes it up.
I was just thinking that the problem for the winzip and registry were related since I was seeing the exact same error conditions on both jobs. *shrug* I don't know that we'll ever know the precise reason the registry job got borked. It's working now and I have to press on with other issues.
Thanks for all of your assistance and insights. It is greatly appreciated!
is there a gpo or something on the file system that could be screwing stuff up? this shouldn't be happening so randomly.