Brian Smith's AIX / UNIX / Linux / Open Source blog
|Modified on by brian_s|
This post is about a script I wrote for building filesystems on AIX. It automates the process of creating logical volumes, filesystems, mounting them, setting user/group owners, and setting permissions. It can be used to create large numbers of filesystems quickly, and it is also handy if you need to create the same filesystems across multiple different servers.
Start by creating a CSV file based on this example/template (the first line is the header line). Simply copy and paste this in to a new file and name it with a .csv extension:
Open up this CSV file in your favorite spreadsheet application (I'm using LibreOffice in this example, but Excel should work as well). Once in the spreadsheet make changes to your CSV file specify what filesystems you want to create:
The columns are pretty self explanatory. The "Mount Options" is optional (and if you specify multiple mount options separate them with a period, i.e. rbrw.cio.dio) The "Log" is also optional (if you don't specify it will default to an existing log in the volume group).
Once you are done editing the file in the spreadsheet save it in CSV format. It MUST be CSV to work. To make sure, transfer the file to your AIX server and "cat" the file, and you should see something similar to this:
Now run the script and specify the CSV as a parameter. By default, the script doesn't make any changes or actually do anything at all other than show the commands that need to be run to create the filesystems:
Review the output to make sure everything looks good. If you want to actually run the commands generated, you can either redirect the output to a file and run that file as a script, or you can just run the scriptfs script and pipe it to "ksh" which will cause it to run the commands and actually create the filesystems:
When this ran, it created the logical volume, filesystem, mounts them, changes the user/group, and sets the permissions.
Here is the script:
Every Filesystem in AIX has two sets of permissions: The permissions on the mount point directory, and the permissions on the mounted filesystem.
Here is an example:
Normally the Mount Point Permissions don't come in to play once the filesystem is mounted (however here is an post that shows what I recommend for them)
However, if a user doesn't have read/execute permissions on the mount point you will see weird behavior and frequently have application issues as well.
Here is an example showing this:
As a non-root user, we do an "ls -al" in the directory and get a weird "./..: Permission denied" error. This is caused because the underlying mount point permissions are restricted (700) and the user doesn't have read/execute permissions on the underlying mount point (even though the mounted filesystem has 777 permissions).
Now there are 2 different ways to check to see what the permissions are on the underlying mount points of your filesystems. You can unmount the filesystem, and do an "ls -ald" on the mount point (but it will probably require application downtime to unmount the filesystem...) Or you could use this handy script that will show you the underlying mount point permissions while the filesystem is online and mounted.
Just a quick disclaimer however... These scripts have worked with my limited testing; but use them at your own risk. The IBM documentation always recommends unmounting the filesystem to check or change mount point permissions and this is the safest and best way to do it. These scripts will do everything with the filesystem mounted and online.
When run, it will show you the underlying mount point permissions for all mounted JFS/JFS2 filesystems:
If you have filesystems with too restrictive mount points that are causing you issues (like /test1 and /app2 in the example above), then you can either unmount the filesystem and change the mount point permissions, or use this script to add read/execute permissions to user/group/others on the underlying mount point directory while it is still mounted and online:
With the script you specify a filesystem and it will add the read/execute permissions on the underlying mount point:
When ever a filesystem is mounted on a UNIX system a mount point must be specified. A mount point is simply a directory that can either be empty or contain files. If the mount point directory contains files these are "covered up" and are no longer accessible when a filesystem is mounted over the mount point. Once the filessytem is unmounted any files that where in the mount point directory become visible again.
When the filesystem is mounted the owner, group, and permissions of the root of the filesystem take effect and override whatever ownership and permissions where set on the mount point directory.
# ls -ald /app1 ##Mount Point Directory (These are the permissions/owner/group I recommend for most mount points)
The first "ls" shows the mount point directory. The filesystem is then mounted, and as you can see both the permissions, owner, and group where changed to the filesystems root directory permissions/owner/group.
I recommend setting the mount point directory owner/group to root:system and having permissions set to something like "r-xr-xr-x" rather than having it set to the same owner/group and permissions that the mounted filesystem has. This way if the filesystem doesn't mount for some reason (for example due to a filesystem issue), users will be prevented from writing files in to the mount point directory. If the mount point ownership/permissions match the filesystem, then if the filesystem doesn't mount you will probably end up with a full root filesystem and then somehow need to merge files between what was written to the mount point and what was already in the filesystem (not fun!)
This is what you don't want:
# ls -ald /app1 ##Mount point permissions, owner, and group identical to what they are when filesystem is mounted
Be careful if you set the mount point permissions too restrictive. In general the mount point should have at least "r-xr-xr-x" permissions. If you set them to something like "rwx------" AIX will show weird permission errors for the parent directory when doing file listings as other users:
# ls -ald /app1 ##Mount point permissions/owner prevent any users from even listing contents of directory