If your existing IBM® FileNet® P8 domain includes a SnapLock fixed content device, you must allow access to your fixed content via NFS instead of, or in addition to, CIFS.
Each qtree (virtual subvolume of a storage volume) has exactly one of the security styles (scheme for setting security on files and directories in the qtree) shown in the following table:
Security Style | Description |
---|---|
UNIX | UNIX file permission attributes. Only NFS clients can create files and directories in a UNIX qtree. |
NTFS | Windows access control lists. Only CIFS clients can create files and directories in an NTFS qtree. |
Mixed | Both UNIX and NTFS security styles. Only one security style at a time is allowed. The current style is that of the last client to modify it. |
Because all pre-4.0.0 versions of IBM FileNet P8 support only CIFS, all storage volumes used by Content Engine version 3.5.2 use NTFS security style. You must change the security style to UNIX or Mixed. Specify the Mixed style for qtrees that must service requests for both NFS and CIFS clients during the upgrade process; otherwise, specify UNIX style.
For each qtree, perform the following steps to specify the security style:
telnet NAFiler qtree security /vol/vol1/sa1 unix
After the qtree command executes, all files created by Content Engine on a UNIX platform will have UNIX security attributes.
Because Content Engine version 3.5.2 support CIFS, rather than NFS, all existing files on a volume have NTFS security attributes. The users and groups with access rights to these files are defined by Windows.
To allow the version 3.5.2 files to remain accessible, you must create a mapping between the new UNIX account for version 5.0.0 of Content Engine and the old Windows account for version 3.5.2.
Each filer has its own configuration file, /etc/usermap.cfg, to map between Windows user names and equivalent UNIX user names. A UNIX user attempting to access a file having NTFS security attributes uses usermap.cfg to determine if a mapping exists between the UNIX account and an equivalent Windows account. If the mapping exists, the access checks on the target file will use the Windows account.
Each usermap.cfg entry has the following format:
[ IP_qualifier :] Windows_name [ direction ] [ IP_qualifier :] UNIX_name
The meaning of each element in the entry is shown in the following table:
Element | Meaning |
---|---|
IP_qualifier | Qualifies the name according to the source address of the requester |
Windows_name | The name of the Window user or group in domain name format (for example, DomainName\UserName). The Windows name must be in the Windows domain that the filer is configured to use when authenticating Windows users. |
UNIX_name | The name of a UNIX user or group. The name must be defined in the file or directory service that the filer uses to authenticate UNIX users. In many cases this will be the local /etc/passwd (for users) or /etc/group (for groups). If it is a group, it might be necessary to also define it in an NIS repository or an LDAP directory server, depending on how the filer is configured. In either case the UID (UNIX user ID) must be identical to the UID of the user under which the Content Engine Server is executing. |
Direction | The direction of the mapping, either <= or =>. <=: Maps UNIX_name to Windows_name =>: Maps Windows_name to UNIX_name |
For example, the following steps define a mapping on a filer between FNCE_OS_User (the Windows user account under which version 3.5.2. x of Content Engine Server executes) and FNCE_UNIX_User (the UNIX user account under which version 5.0.0 of Content Engine Server executes).
By default, the filer root volume is accessible from a Windows client as a CIFS share named C$), as in the following example (where NAFiler is the host name of the target filer at your site.
C\> net use n: \\NAFiler\C$ /user:NAFiler1\Administrator
CEDomain\FNCE_OS_User => FNCE_UNIX_User
FNCE_UNIX_User:CEServers:205:7100::/home/FNCE_UNIX_User: