Samba Rights When Working With NCP Volumes

  • 7000775
  • 02-Mar-2009
  • 30-Apr-2012


Novell Open Enterprise Server (OES)
Novell Open Workgroup Suite Small Business Edition (NOWS-SBE)


Samba can access two types of filesystems.  The first are POSIX-based (ie. rwxr-wr-w, or 755) filesystems, such as reiserfs and ext3.  The other type is NSS.  With either type, there is a single point of rights management.  With POSIX-based, ACLs can be used (on the filesystem itself or within Samba).  With NSS, the rights are handled through eDirectory.  This document, however, is to explain how to work with Samba rights when dealing with NCP volumes.
In OES and NOWS-SBE the administrator can create and use NCP volumes. NSS volumes, while a special type of NCP volume, is not supported or available under NOWS 2.0, but is available under NOWS 2.5..  NCP volumes, or volumes that can be accessed via the NCP protocol, are supported (non-NSS) in both NOWS 2.0 and 2.5.  For NOWS 2.0 there is no single point of rights management should an administrator choose to share the NCP volume via Samba. 
The administrator will need to configure both filesystem trustees/rights  to manage NCP connections and POSIX rights on the filesystem for Samba if access to the share will be available over both protocols.


NCP rights can be configured in two ways:
1.  iManager:
  • Go to https://ip.add.of.server:8181 and login as the user sbsadmin.
  • Under the "Components Window" make sure "Products and Services" is selected
  • On the right-hand side of the screen select "Tools" and then "iManager"
  • Once inside iManager (log in as admin), select "Rights" from the left-hand menu.
  • The rest should be intuitive.  For more information on setting rights inside of eDirectory, refer to the documentation.
  • NOTE: There are some switches that can be used in conjunction with NCP volumes that will manipulate the way rights behave (ie. whether they behave like POSIX rights for inheritance, or NetWare rights).  See the documentation for more details.
2.  Command Line:
  • NOTE: All ncpcon commands can be executed from the main shell without having to enter into the ncpcon shell by using "ncpcon" at the beginning of the command. If inside the ncpcon shell itself, don't add the ncpcon syntax at the beginning of the command as it isn't needed.
  • Review the rights command inside of ncpcon with the following (without quotes) "ncpcon rights show"
  • Basic syntax is as follows:  ncpcon rights <cmd> <volume>:<path> <user.context> <rights>
    • <cmd> is view, add, or rem (remove)
    • <volume> is the ncp volume name
    • <path> is the path to the file or folder rights are being manipulated on.  If just manipulating the volume, then exclude the path (ie "MyVol:" -- Don't forget the colon)
    • <user.context> Specify the user object with the context in the tree.  The tree should not be necessary to specify.
    • <rights> are the explicit rights to be given to the user (or removed).  To see the available options, type "ncpcon help rights" and review the "Options" section of the help page.
 POSIX rights considerations
 Volumes can be written about POSIX rights. There are volumes out on the web.  The same can be said about ACLs that can be set within Samba, and how filesystem ACLs and Samba ACLs interact and take priority over one another.  The intent of this document is not to cover any of that (again, as it can take up volumes).  This document is to make the administrator aware of something things to consider, and in some cases some "gotchas" that can cause administrative headaches. 
Unlike NetWare, the administrator cannot restrict access at the root of the share (to a degree) and add the rights further down in a subdirectory.  For instance, consider the following NCP volume path:
The ncpserv.conf shows that the ncpvolume HOME maps to /home.  The permissions on /home are:
nows:/ # getfacl --all-effective home/
# file: home
# owner: root
# group: root
Note that the owner and group are both root.  As the root user, rwx permissions are assigned.  The group only has read and execute, as does other.  This is perfectly normal, and is what the permissions need to be at the root of the ncpvolume (and on every subdirectory).  This means that the subdirectory level1 would look the same, level2, and so on.  The file, by default, will have 644 (or rw-r--r--).  If the administrator then wishes to restrict the test user "user1" from being able to access the file.txt file (via ACLs), the administrator can do the following:
nows: cd /home/level1/level2
nows:/home/level1/level2 # setfacl -m u:user1:--- file.txt
nows:/home/level1/level2 # getfacl --all-effective file.txt
# file: file.txt
# owner: root
# group: root
user:user1:---                   #effective:---
group::r--                         #effective:r--
NOTE: Setting ACLs, removing them, and so on will not be covered here.  The man pages for setfacl and getfacl will get the administrator started. 
In the above example, rights were explicitly stripped from user1 on the file.  This could have been done at the directory level with the same effect. 
In the following example, the permissions will be incorrectly set.  Consider the following:
nows:chmod -R 700 /home
nows:/ # cd /home/level1/level2/
nows:/home/level1/level2 # getfacl --all-effective file.txt
# file: file.txt
# owner: root
# group: root
Note that only the root user has permissions to do anything to this file (the same is true to the directory). 
As an administrator, I may be thinking that I am only allowing root user to have access to this directory and its contents.  This is true, however, I cannot do the following on any subdirectories or files and expect it to work:
nows:/home/level1/level2 # setfacl -m u:user1:rwx file.txt
nows:/home/level1/level2 # getfacl --all-effective file.txt
# file: file.txt
# owner: root
# group: root
user:user1:rwx                  #effective:rwx
group::---                      #effective:---
Notice that user1 has full rwx permissions on the file.  This is deceptive though, because user1 (as he is not the root user) does not have any permissions on the directory.  This user will not be able to see or manipulate the file through a Samba connection.  In order to have full rights to this file, the user will need at least r-x permissions on all directories up to the root of the path.  This means that in the path /home/level1/level2/file.txt, /home, level1, and level2 will need to have at least r-x permissions for either the user, or a group the user belongs to (or both--which is default). 
As a quick summary review, in order for a user to do anything in a directory or file, the user should have r-x permissions on all directories from the current working directory up through all parent directories to the root.  If the user doesn't, despite what ACLs may be set on a particular file or subdirectory, that user will not be able to do what their rights may specify.
With two different protocols being used to access a share (smb/cifs and ncp), some problems can occur.  For instance, consider the following file
nows:/home/level1/level2 # getfacl --all-effective new_test.txt
# file: new_test.txt
# owner: JohnDoe
# group: MyGroup
The new_test.txt file above has POSIX permissions of 777 (or rwx for user, group, and other).  If a user connects through a Novell NCP client, modifies and saves the file, the owning user will be changed to the user that changed and saved the file.  The owning group will be changed to 'root' and the default permissions will likely change to rw------- (read, write for the user only).  This presents a problem when trying to share a file with many users.  NCP provides a switch called "Inherit_POSIX_Permissions" to get around this.  When set, files will inherit the GID and mode bits of the parent directory.  This means that if the new_test.txt file resides in the "level2" directory, and the directory has permissions of 777 and is owned by SomeUser and SomeGroup, then the modified new_test.txt file (as modified through the NCP client) will have the owner of CurrentUser, the group SomeGroup, and will have rw-rw-rw- (or 666) on the file.  If the user creates subdirectories it will be the same (except the permissions will be 777 or rwxrwxrwx).  For more information about the "Inherit_POSIX_Permissions" switch, please see section 10.8 of the Storage Administration Guide under the OES 2 documentation.