In-Depth

The Day the Access Rights Lists Stood Still

What should have been a standard Banyan StreetTalk for Windows NT administrative chore turned into a major source of Sunday afternoon stress.

• By Rob Vazzana
• February 01, 1999

If you do technical support for a living and are part of an on-call rotation, you know how it feels. You make plans for a special evening, yet you wear that pager with some anxiety and an uneasy feeling in your stomach. You know that if the beeper sounds, all bets are off. Plans go awry. This story is about a time my beeper went off.

Mixing It Up with StreetTalk

The technical issue at hand revolves around a product from Banyan Systems, Inc. called StreetTalk for Windows NT. StreetTalk for NT runs on an NT 4.0 server and lets you integrate NT—including access to NT printers and file shares—into your existing Banyan VINES network. StreetTalk for NT can also assist in migration away from Classic Banyan VINES servers to NT. A planned migration isn’t required for Banyan clients to access the NT resources either. Banyan users can be easily migrated, if desired, to the StreetTalk for NT server.

In addition, file volumes, printers, users, and other resources on a StreetTalk for NT server can be administered via a simple Banyan administrative tool called StreetTalk Explorer. I find this utility intuitive and easier to use than the NT administrative tools. This ease of management is a large lure and one of the real values in using StreetTalk for NT rather than NT exclusively.

A Banyan file service is created via StreetTalk Explorer and points to an NT file volume. The data contained in the volume resides on an NT server, and Banyan users can access it via the Banyan file service. Banyan services can be stopped or started via an NT “Banyan File Services” option shown with the other NT services in the Services Control Panel.

The level of access that a Banyan user has to data on a Banyan file service is determined from an Access Rights List (ARL). ARLs are managed via the StreetTalk Explorer tool. Each file and directory on a Banyan file service has its own ARL. Without this ARL, users can’t access anything.

At the time of this writing, there are two releases of StreetTalk for NT available: version 7.5 and the new 8.5. My customer is using 7.5. (He wasn’t ready to consider 8.5 until we completed further stress testing.)

The Goal

The person paging me on Sunday had a Monday 8 a.m. deadline to create a Banyan file service on his StreetTalk server. Come Monday morning, hundreds of Banyan users would be trying to access the data residing on the NT file volume that the Banyan file service would point to. The ARLs would have to be properly configured to ensure this access. He had started the project on Sunday around noon. Normally this would be simple, but since this was my on-call weekend, who could tell what would happen?

The Problem

The Access Rights Lists were malfunctioning for this newly created Banyan File service. Test Banyan users who should have been able to access the new service on the StreetTalk for NT server couldn’t. Other pre-existing Banyan file services on the same StreetTalk for NT server were fully accessible to Banyan users. When the users tried to access the new Banyan file service, they received an “Access Denied” error. My online documentation didn’t show this as a known issue either. The clock was running.

The Hunt for a Solution

We started with simple, methodical troubleshooting techniques for an access rights issue. I had the customer download the latest version of StreetTalk Explorer from the Banyan Web site. Setting ARLs using the new utility didn’t resolve our problem. We even tried using the DOS SETARL utility to set ARLs instead of using the GUI administrative tool. This also didn’t work. In the back of my mind I knew that this customer wasn’t at the latest StreetTalk for NT patch level (they had patch NT98029, and the latest patch available was NT98048.) They wanted to avoid applying the most recent patch if possible.

I had the customer create a new NT file volume. Then I had him create a new Banyan file service, point it to the new NT file volume, and configure the ARLs as desired. If the users could access the new Banyan file service, then we could copy the data from the old NT file volume to the new one. But this didn’t work either.

At this point I gave in and placed a call to Banyan for weekend tech support. Banyan promptly got back to me and advised checking NT file volumes for sharing. The NT file volumes shouldn’t be shared since StreetTalk handles the sharing. In fact, NT volume sharing can interfere with ARLs. Our volumes were shared. This could be the cause of our problem! Alas, setting them to unshared didn’t help.

There are two files in the Program Files | Banyan | Files | Data folder, which maintain the ARL settings for all of the Banyan File services that reside on the StreetTalk for NT server. Banyan suggested that these two files might be damaged. The technical support folks recommended we stop the “Banyan File Service” NT service. Then we were to move these two files to another location and restart the “Banyan File Service” NT service. The two ARL files should be automatically re-created.

The large drawback here is that ARL settings for all files and directories for every Banyan file service on the server are returned to default settings. The ARLs would have to be manually re-created for all Banyan file services, not just for the one file service that was causing the problems. Ouch! This customer had about 10 Banyan file services on the StreetTalk for NT server, so we knew it would have a fairly large impact.

We performed the steps and moved those two ARL files to another location. Then we restarted the service, thus re-creating the ARL files. We reconfigured and saved the ARLs on the Banyan file services using StreetTalk Explorer, giving users the needed access to the data on the NT file volumes. However, they still received “access denied” messages when trying to access the data. And now, none of the Banyan file services were accessible to Banyan users. Users received the access denied error when trying to access data on all Banyan file services. The issue had just increased in priority by a factor of 100. I began to realize that I probably wouldn’t be making my Sunday dinner engagement.

So what else did I have to fall back on? That’s right—the patch! We had already spent a good chunk of time on this problem. We decided that since our conventional attacks were coming up short, we needed to apply the latest StreetTalk for NT patch so that we were at the latest code revision. There were also specific fixes in regards to the ARL functionality in this patch. Without further delay we applied the patch.

This is what nightmares are made of. The patch resolved nothing in regards to our problem.

The Final Solution

Out of pure desperation, the customer and I began some tests. We knew what we couldn’t do. It was time to identify what we could do. Our hope was that maybe if we tried a few small changes we could make some progress. We specifically looked at where we were pointing the Banyan file service to in the NT directory structure, as well as where the “virtual root” was for the drives being mapped via user profile. And then the two workarounds made themselves apparent.

Workaround 1: Configure the Banyan users to map a drive to a subdirectory of the Banyan File service, rather than the root.

Banyan users can map a drive letter to the Banyan file service via a SETDRIVE command, usually located in the users’ Banyan user profile. You can use a /ROOT switch on the setdrive command to specify a subdirectory path of the file volume. To the user this subdirectory path will appear as the “root” of the drive. When we configured the /ROOT switch to a subdirectory of the Banyan file service, suddenly users could access the data. Although the Banyan ARLs were configured to allow users to access the root of the file volume, they still couldn’t. We were quite happy that subdirectories didn’t have this problem.

Workaround 2: Configure the Banyan file service to point to a subdirectory of the NT file volume, rather than the root of the NT file volume.

You configure a Banyan file service via browsing to point to an NT file volume. You can pick the root of the NT file volume, or any subdirectory of the NT file volume, to appear to be the root of the Banyan file service. This site was configuring the Banyan file service to point to the root of the NT file volume. When we configured the Banyan file service to point to a subdirectory of the NT file volume, all ARLs worked, and Banyan users could access the data on the Banyan file services residing on the StreetTalk for NT server. Just don’t keep data that users need to access in the root of the NT file volume!

The Results

The user chose workaround 1 and with a simple addition of a /ROOT:[directory path] parameter appended to the Banyan SETDRIVE commands in the users’ profiles, all data was again accessible. The user was able to add the new Banyan file service and meet his goal by 6:30 Sunday evening—and I made my dinner!

In addition, later on during regular business hours, Banyan reproduced this problem in StreetTalk for NT 7.5. While they were at it, Banyan also confirmed that the bug doesn’t exist in 8.5. At present the client doesn’t intend to upgrade.

The Lesson

So what did we learn from this? Should we always keep software at the latest revision? We all know that sometimes being on the bleeding edge of technology is bad, and I have many scars to prove it, so that’s not the lesson here. Should we always keep a rubber chicken handy for these types of situations? Yes, definitely. But I also have two other lessons in mind.

• Lesson 1: Start earlier. How could this customer have met the same deadline with less stress and frustration? If the customer had started earlier than Sunday, which was less than 24 hours before the deadline, we would have encountered the problem earlier and had less of a deadline over our heads.

• Lesson 2: Do administrative tasks during business hours. Creating an additional Banyan file service and configuring its ARLs is a simple administrative task. This could have been done during business hours with no impact to the production network. ARLs could have been configured to allow a non-administrator test user to access the data. Once the test user could access the data, we could expect any of the production users to be able to access the data as well.

The benefit of having the failure during business hours is the wealth of resources available, which just isn’t there on the weekend. For example, the Banyan engineer, while very knowledgeable, didn’t have his extensive workplace lab available to reproduce our problem until Monday, after the deadline. I didn’t have the resources of my workplace lab to test this on. Had this failure occurred during the previous week, we could have attained a better understanding of the problem faster. We could have reproduced the failure, advised the upgrade to StreetTalk for NT 8.5, or used the workarounds, and let the customer make the decision. That way, the process might have occurred in a timely fashion and without much agony.