Once the drive is formatted, you can start using the NSL right away since it sets up two default Shares, or folders (directories) on the NSL. Figure 4 shows the two shares as they appear in My Network Places. Disk 1 is the "Guest" share, which is by default Read/Write accessible by anyone on your network. Admin 1 is a share protected by the default "admin" user account and password.

Figure 4: The NSLU2's default shares

If you poke around the NSL's directory structure using your OS's file explorer, you'll find that Disk 1 really is the "public" folder found in the Admin 1 folder. But you won't find the public share anywhere in the Shares admin interface (Figure 5). Actually, all Shares get created as folders / directories under the Admin 1 top-level share. Since "Disk 1" is the way that the Admin interface refers to the first physical disk, I think this is an unfortunate and confusing choice.

Figure 5: Share administration

You can set up a new Share directly via its interface, or click on over to the User page (inconveniently located in a different Admin page grouping) and set one up automatically when setting up a new User (Figure 6). All Shares are created in the Admin 1 root directory, unless you use the Specify option and enter the path you desire - using a forward-slash format.

Figure 6: User administration

Users can also be assigned to Groups and have Disk Quotas assigned in 1MB increments. I verified that quotas are enforced per User, no matter on which Shares the User's files are stored.

Although the NSL's permission capabilities should be adequate for most of its target SOHO users, they may not be adequate for those who need finer-level control over who can access what. Basically, you can't set file or user-level permissions. Access to the "Private Folder" that can be created for each user is actually controlled by the creation of a same-named Group.

Permission mistakes for nested folders are a common mistake to make for server administration novices and can drive you crazy until you figure out what you're doing wrong. Unfortunately, the NSL lets you create nested folders (as described above), but doesn't properly handle access permissions. And worse, it doesn't properly represent the permissions in the Admin interface that it does set.

In my test case, I created a sub-folder that had different and more restrictive Group permissions than its parent folder. I found that the NSL properly wouldn't let me log into it with User info valid for the parent folder's permissions. But once I logged into the parent folder, I was granted complete access to the sub-folder.