This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Kwan-yin Kong <address@hidden> >Organization: UCAR/Unidata >Keywords: 200111070252.fA72qP121516 >Dear Unidata support: > > My name is Kwan-yin Kong, currently working in >Earth and Atmospheric Science Department at the City >College of New York. I am contacting you regarding >a GEMPAK/LDM related problem that recently surfaced >in our UNIX Solaris machine. About a month ago, the >LDM experienced a crash. After the system was >brought back up (by an attending system operator), >the file permission of all gempak files have >mysterious been changed to allow read and write only >within the LDM account. All other accounts can no >longer read the gempak data even within gempak >programs. Since I am relatively new to administ- >rating GEMPAK, could you offer me some hints as >to what and how to fix this problem? I appreciate >your comments. > >Kwan-yin Kong >EAS >CCNY > Kwan-yin, If you mean that all the GEMPAK data files that the LDM is creating are being created with a mode of rw-----, (eg read/write only by the owner), then the "umask" setting of the ldm account is probably set as 077. That is, the account that runs the LDM will create the decoded files with the permissions masked by the umask value. You probably want your LDM account to use a "umask 022" so that the files are created with permissions rw-r-r. The umask is frequently set in your shell profile, or the system wide profile. Steve Chiswell