It was (and still is) owned by sgeadmin:sgeadmin. And still, root couldn't get permissions somehow within the script even though it could manipulate files in there from command line. The script reported running as root. It was very strange.
-M On Thu, Aug 13, 2015 at 8:02 AM, Rémy Dernat <[email protected]> wrote: > No it is not a rocks matter. It is GridEngine. > > chown sgeadmin:sgeadmin $SGE_ROOT/$SGE_CELL > > Before any restore action should do the trick. > > Do you plan to create a rocks roll from your work? > > Best > Le 12 août 2015 17:34, "Michael Stauffer" <[email protected]> a écrit : > > > On Wed, Aug 12, 2015 at 2:59 AM, Rémy Dernat <[email protected]> wrote: > > > > > Thanks for your full report! By the way $SGE_ROOT/$SGE_CELL needs to be > > > owned by sge user (which is different in SoGE). Maybe the origin of > your > > > permission issue while trying to restore with "inst_sge -rst" ? > > > > > > > > Yes, SoGE installs using sgeadmin. I kept that. Do you mean > > $SGE_ROOT/$SGE_CELL needs to be > > owned by sge user for Rocks' purposes? The permissions error I had was > > happening with the script running as root, and some debugging showed it > > running as user root within the script. root wasn't allowed to overwrite > > files in $SGE_ROOT/$SGE_CELL/common if I remember right, even though root > > could make changes there from the command line. It was very strange. > > > > -M > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20150812/f334b828/attachment.html > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.sdsc.edu/pipermail/npaci-rocks-discussion/attachments/20150813/d57f7cad/attachment.html >
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
