SAPCAR: can not set permissions for /EPS/in/SIGNATURE.SMF

[Former Member]

We are running SUM 1.0 SP10 on IBM i with V7R1 to put EHP6 and SP's on an ERP 6.0 system.  Phase PREP_PRE_CHECK/SCANDIR_EPS0 repeatedly ends with multiple errors that SAPCAR: can not set permissions for /EPS/in/SIGNATURE.SMF file.  We tried increasing the sidADM and R3GROUP authority to the file, but it changes them back and ends with a different number of errors each time, see example:

SAPup> Starting subprocess with PID 4295601 in phase 'SCANDIR_EPS0' at 20140319101619
    ENV: DIR_LIBRARY=/usr/sap/Y60/SUM/abap/bin
    ENV: ILE_PATH=/usr/sap/Y60/SUM/abap/bin:/usr/sap/Y60/SYS/exe/run:/usr/bin:.
    ENV: LIBPATH=/usr/sap/Y60/SUM/abap/bin:/usr/sap/Y60/SUM/jvm/jre/lib/ppc64/server:/usr/sap/Y60/SUM/jvm/jre/lib/ppc64:/usr/sap/Y60/SUM/jvm/jre/../lib/ppc64:/usr/sap/Y60/SUM/jvm/jre/lib/ppc64/jli:/usr/sap/Y60/SUM/jvm/jre/../lib/ppc64/jli:/usr/sap/Y60/SYS/exe/run:/usr/sap/Y60/hdbclient:/sapdb/clients/Y60/lib/lib64:/sapdb/clients/Y60/lib:/sapdb/programs/lib/lib64:/sapdb/programs/lib
    ENV: PASE_LANG=en_US
    ENV: PASE_LC__FASTMSG=true
    ENV: PASE_LIBPATH=/usr/sap/Y60/SUM/abap/bin:/usr/sap/Y60/SYS/exe/run:/usr/sap/Y60/hdbclient:/sapdb/clients/Y60/lib/lib64:/sapdb/clients/Y60/lib:/sapdb/programs/lib/lib64:/sapdb/programs/lib
    ENV: PASE_LOCPATH=/usr/lib/nls/loc
    ENV: PASE_NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat:/usr/lib/nls/msg/en_US/%N:/usr/lib/nls/msg/en_US/%N.cat
    ENV: PASE_PATH=/usr/sap/Y60/SUM/abap/bin:/usr/sap/Y60/SYS/exe/run:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:/usr/bin:.:/usr/sap/Y60/hdbclient:/sapdb/clients/Y60/bin:/sapdb/programs/bin
    ENV: PASE_STDIO_ISATTY=N
    ENV: PASE_THREAD_ATTACH=Y
    ENV: PASE_TZ=<EST>5<EDT>,M3.2.0,M11.1.0
    ENV: PASE_USRGRP_LIMITED=
    ENV: PATH=/usr/sap/Y60/SUM/abap/bin:/usr/sap/Y60/SYS/exe/run:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:/usr/bin:.:/usr/sap/Y60/hdbclient:/sapdb/clients/Y60/bin:/sapdb/programs/bin
    ENV: SAPSYSTEMNAME=Y60
    ENV: dbms_type=db4
    ENV: dbs_db4_schema=R3Y60DATA
    ENV: ILE_DIR_LIBRARY=/usr/sap/Y60/SUM/abap/bin
    ENV: PASE_DIR_LIBRARY=/usr/sap/Y60/SUM/abap/bin
    ENV: DIR_LIBRARY_RMT=/usr/sap/Y60/SUM/abap/bin
    ENV: ILE_DIR_LIBRARY_RMT=/usr/sap/Y60/SUM/abap/bin
    ENV: PASE_DIR_LIBRARY_RMT=/usr/sap/Y60/SUM/abap/bin
    ENV: ILE_LIBPATH=/usr/sap/Y60/SUM/abap/bin

EXECUTING /usr/sap/Y60/SUM/abap/bin/SAPCAR -flat -R /usr/sap/transD60/EPS/in -xvf /tmp/NO_SAVE/ERP_EHP6_Download/K-60609INECCDIMP.SAR
SAPCAR: processing archive /tmp/NO_SAVE/ERP_EHP6_Download/K-60609INECCDIMP.SAR (version 2.01)
x CSR0120031469_0080800.PAT
x SIGNATURE.SMF
SAPCAR: can not set permissions for /usr/sap/transD60/EPS/in/SIGNATURE.SMF (error 13). No such file or directory
SAPup> Process with PID 4295601 terminated with status 13 at 20140319101623!

Has anyone lse exprienced this and can share a fix?

Thank you,

-Margie

[Former Member · Accepted solution]

Hi all,

this is an issue in the current SUM 1.0 SP10. As a workaround, it helps if you retry the step until it succeeds. Maybe you need to do retry twice or more but it will work eventually.

We'll fix it in one of the next SUM patches...

Best regards

Christoph

[christoph_ostrop · Accepted solution]

Christoph Langer wrote:

Hi all,
this is an issue in the current SUM 1.0 SP10. As a workaround, it helps if you retry the step until it succeeds. Maybe you need to do retry twice or more but it will work eventually.

We'll fix it in one of the next SUM patches...

Best regards
Christoph
 

that was an issue in SUM 1.0 SP09 PL-8  too.

when you update several sap-systems (e.g. sandbox, developm. test/qs, prod.)

the first system (first SUM run) could create the file '/usr/sap/trans/EPS/in/SIGNATURE.SMF'

but the second system (2. run of SUM) could not change or edit file-authority .....

so it worked as described above.

Christoph

[Former Member]

Hi,

We had the same issue, and in my opinion it is caused by the parallelisation of sapcar during SUM phase PREP_PRE_CHECK/SCANDIR_EPS0

I did see several parallel SAPCAR jobs running during this phase.

So what happens when one job extracts SIGNATURE.SMF at the same time another job tries to finalize its extraction by setting the permissions for /usr/sap/trans/EPS/in/SIGNATURE.SMF?

It can happen that permissions are being set at the same time another sapcar yust deletes this file to begin extracting.

Since we had 146 SAR archives that needed to be extracted, a retry allways ended up in 4 to 12 conflicts.

What did do the trick was adding

/sapcar/extrcact_parallel = 0

to the file

../SUM/abap/bin/SAPup.par

Just as Christoph Langer suggested.

We had to restart the whole phase, a repeat was not enough to solve the problem.

[Former Member]

Hi,

until the issue is fixed in one of the next SUM releases, here is a possible workaround.

Edit file .../SUM/abap/bin/SAPup.par, set /sapcar/extrcact_parallel = 0.

Maybe that helps to overcome the issue.

Best regards

Christoph

[janlars_goedtke]

Hello Christoph,

where can I find any documentation regarding /sapcar/extract_parallel=0 ?

Thanks

Jan

[Former Member]

Thinking about Christoph Ostrop's comments about when you use a shared /EPS/in for multiple systems in a landscape - it would be a real time-saver if the SUM tool had the option not to decompress and reload the /EPS/in box every single run.  Here we decide what the upgrade version/package will be and use it on every system in our landscape, so there is no need to repeatedly load the  shared /EPS/in box.

:-)) -Margie

[Former Member]

Thank you all - we had high hopes for Volker's suggestion to use local DIR_EPS_ROOT (we use remote) - but that didn't work either.  In desperation we went back to an older version SUM 1.0 SP09 patch 0, and it worked!  We are on to the next step. BTW - SUM 1.0 SP09 patch 8 also did not work.

Christoph Langer - we retried SUM 1.0 SP10 with original error 5 times and it got a different number of errors each time but did not successfully complete.

Thanks for the fast help,

-Margie

[christoph_ostrop]

Hi, Margie,

you can edit the IFS-file authority (on the server who is hosting the /usr/sap/trans/EPS/in/.....)

WRKAUT  OBJ('/usr/sap/trans/EPS/in/SIGNATURE.SMF')       

then you can add a new authority-entry for the needed <SID>ADM  with all authority

then retry in SUM    step    

HTH

Christoph          

[volker_gldenpfennig]

Hi Margie,

yes, that is normal, when the trans dir is remote ;-((

Because of that and because of the slow speed, we always set the DIR_EPS_ROOT to a local directory - then it works fine ...

Regards

Volker Gueldenpfennig, consolut