Hi Michal,
did you run the m2prep script first?
mp2prep -c
runs one (or several) 'dry/statistics' jobs to check how much memory and disk space the MP2 NMR chemical shielding job is going to need. This is conventional MP2, so it is quite resource intense...
If you did run it, check the sizes of the files in $mointunit. Perhaps the job is too big to be run in one loop. Not necessarily the memory and disk space requirements, but also some internal limits (this is partly very old code in Turbomole which still assumes to run into problems when consuming too much).
You can try to split up the calculations in parts such that mpshift loops over a subset of occupied orbitals. This will reduce the hardware requirements, but the calculation will take longer. The number of loops is set by $traloop <number>.
Try with
mp2prep -c -l 10
and rerun. This will force mpshift to split the calculation into 10 parts (they all run one after the other, so be patient) while reducing the sizes of almost everything (memory, disk space, ...). The -l option just tells mp2prep to start with a minimum of 10 loops.
If it takes much much too long: Those 10 (or whatever you set in $traloop) passes can also be run by different processes, so a course-grained parallelization can be used. It needs to be set up manually, but the procedure is not overwhelmingly complicated. See $trast and $trand keywords in the manual.
Disclaimer: I did not use this option since many years, but there is a test in the usual test suite that comes with Turbomole, so it should still work...