reusing previous gtm directory ( permissions)

Ty Maynard
  • Ty Maynard
    Ty Maynard

    This arises as I have been doing musical chairs with differing distributions (Mandrake,Debian,Ubuntu). An earlier gtm directory (gtm4.3 installed under Mandr9.2) for use with vista mumps application has been retained on undisturbed partitions, which I intended to mount and use under the new user identity, in any of these new distros. 

    I do the following:
    * have the old partitions containing old gtm directory and old vista directory mounted
    *define a new group that includes the new user which is running any new distro
    *recursively chown that group from the "mnt" directory down the entire path to and including the old gtm directory and the old vista directory
    *chmod recursively  that group permission to rxw
    *change the bash_profile with appropriate environment paths for the newly mounted location of gtm_dist,gtmgbldir etc.
    *refresh bash environment

    I get this error back to bash:
    ty14@hp:~$ gtm
    bash: /mnt/a11x/usr/local/gtm/mumps: Permission denied
    ty14@hp:~$ mupip
    bash: /mnt/a11x/usr/local/gtm/mupip: Permission denied

    I have verified that a test bash script file executes when residing in the gtm directory with the above permissions
    ...the aliased commands shown above  hang for awhile before reporting this "permission denied" which implies some processing before  bash reports the denial.

    Is there some mysterious embedded permission status...some retained state from the previously installed gtm directory...maybe for security reasons?
         Is there a gtm call to some lib file that is not available in the new distro, so that the "permission denied" message  is passed back to bash??
       What is a bash method for exposing what gtm is doing  to bring this message back to bash?

    • Steven Estes
      Steven Estes


      This would appear to be a permissions issue that is preventing any GT.M module from even beginning to execute. The message is coming from bash so my belief is that the problem is detected by bash, not GT.M.

      I know on some distros (Mandrake for one), the /mnt mount point has some automount magic associated with it (the devfs stuff) so it could be as simple as your mount choice. That may also explain the pause you see before getting an error.

      Try changing where you mount the partition to somplace in /tmp or something more permanent, whatever suits you. Also double check your permissions at each level  of the directory and check that your current group matches the group as seen in the mounted partition..


    • Ty Maynard
      Ty Maynard

      Well .... as mentioned, I have confirmed that the directories are available and mounted read write.  I have also confirmed that a simple bash script file place within the directory runs properly bash can run just fine on that mount.
      The bash user has group permissions "rwx" within the particular gtm directory ...and of course the x permission remains there for all users as well.
         I  carefully confirmed that the location of the global required in gtmgbldir  is available is also accessible for the user via group membership.  I am currently on Ubuntu with this and the gtm 4.3 had been installed under Mandrake 9.2.
         I'll move will move on  to gtm 5 , but I wanted to understand how this existing gtm can be  called upon.

    • Ty Maynard
      Ty Maynard

        After further thought it occurred to me that running a bash script from the old mounted gtm directory isnt any test of executability ...the script is executed by the running shell and is just a readable file. 
        After various permission changes and bypassing any environmental definition of path by   literally changing the current directory to  old gtm directory, truly no user could run any executable residing there.
        *As you advised* I copied the old directory to a better home  (in this case /usr/local/gtm43) and bash can then run things.  Bash has some rules about where it can run executables regardless of file permissions.
        I wonder where that behavior is configured and the history behind that design...some sort of mandated security.
      Thanks for your hunch.