<UpdateBuildNumberDropLocation and NFS File Systems

Our current Team Build drop location is a Common Internet File System (CIFS) mount to some network attached storage (NAS).  To a novice like me, the drop location looks just like a Windows server drive that is shared.  However, on the back end this CIFS mount has all the bells and whistles that the data center offers (e.g. backups, redundancy, etc.).

The issue we have with the CIFS mount is that while our Windows servers can pick code on their for deployment, our Linux boxes can’t see the CIFS mount.  Since a lot of our development is done in Java and runs on Linux, we have an issue.

Enter the fine storage and system admin teams who have tested the use of Network File System (NFS), as a replacement for the CIFS mount, which is accessible by both Windows and Linux servers.  We’ve tested the NFS mount and sure enough, both our Windows servers and Linux servers can mount to the same drop location and pick up the build output used for deployment.  Perfect right?  Unfortunately there is a small issue.

According to this post, Team Build’s <UpdateBuildNumberDropLocation Task has code in it which needs to update permissions on the drop location.  From what I understand, the code will change the permissions so the App Tier service account has access to the drop location (it needs access to delete builds and such).  To see this, Right Click on a file located on the drop location and notice how the App Tier service account has full access to the folder and any sub files or directories.  The <UpdateBuildNumberDropLocation is doing this.

The issue that I’m running into is, when the drop location is a NFS system, there are no permissions at the file or directory level.  For Windows, the permissions are at the share level.  I’m assuming Linux permissions are dependent on wether the mount is a write or read mount.  So when the <UpdateBuildNumberDropLocation Task runs, it gets a message back saying permissions can’t be set and thus throws this friendly message back to the user: “TF209025: The build process is unable to set the permissions on the drop directory <actual drop location>(Detail Message: Attempted to perform an unauthorized operation.). Make sure that the build service account has proper permissions on the build drop directory and try again.”

What’s interesting is, the share is wide open thus the NFS mount is wide open.  And Team Build actually writes files to the location.  So functionally everything should work fine if we could get past the feature in the <UpdateBuildNumberDropLocation Task where it tries to adjust permissions.

I’m not sure what a good solution is for this.  However, I think the current implementation needs adjusting.  In my Connect submission to Microsoft, I’ve asked them to provide a Property (e.g. UpdatePermissions=”false”) where you can turn off the permission change when you want to use a NFS mount for your drop location.