JMS is working perfectly with suPHP and this is also recommended to have appropriate behavior.
So the problem is not from the suPHP.
Try to put the open_basedir with novalue to check if this is the path define there.
I thing the problem is there but I don't see it.

This will help you identify if the problem come from the open_basedir.

If the open_basedir with novalue still does not work, check also the owner of the files and folders that may be incompatible. Perhaps you need to put "world" access.
In this case that mean that the owner of the file you are executing is not the same that the target one or is not in the same group.
suPHP use the owner of the file execute to perform all the access and this is what is expected.
If you are runing on Plesk environment, you also have to check the owner of the directories. Sometime you have directories that are owned by the "root" and this does not give you the access.

thanks for getting back to me!

I checked what you said and have also talked to my host:

clearing open_basedir does not make any difference whatsoever. I still get the internal server error and the soft exception

regarding ownership and permissions my host got back to me in writing with this:

die Besitzer und Gruppen der Dateien und Ordner von web1 stimmen soweit. Was auffällig ist, das Symlinks eingesetzt werden, hier ist fraglich wie diese angelegt wurden da dies generell per PHP nicht möglich ist beim Einsatz von suPHP.

Weiterhin haben diese symlinks einen chmod von 777 was ein Problem darstellen könnte da als chmod maximal 755 vergeben werden darf, für Dateien sowie Ordner.

since its a German host I will translate it here:

the owners and groups of files and folders of web1 (the user) are ok. what is unusual is that symlinks are in place. its not clear how these are being created as this is generally not possible with PHP when suPHP is in use

also symlinks have a chmod of 777 which could cause problems as for folders and files a chmod of max 755 may be assigned

could you please advice?

For me, I think the open_basedir is NOT correct and you should provide bi-directional path.
Master should also see the slave and not only the slave see the master.

I suggest you to check if that works when you put the open_basedir with "novalue".
This will help you confirm the hypothesis that the problem effectivelly comes from the open_basedir.

suPHP is working perfectly with JMS and is strongly recommended by JMS.
So this is not suPHP that provide correct and consistent permissions

thanks again for getting back to me!

- I tried your suggestion making the master also seeing the slave(s)

master site:
php_admin_value open_basedir /user/public_html/test:/usr/bin:/user/phptmp:user/public_html/test-creators/dummy1:user/public_html/test-creators/chrissy

slave dummy1:
php_admin_value open_basedir /user/public_html/test-creators/dummy1:/usr/bin:/user/phptmp:/user/public_html/test/

slave chrissy:
php_admin_value open_basedir /user/public_html/test-creators/chrissy:/usr/bin:/user/phptmp:/user/public_html/test/

same result : internal server error and soft exception

- I also tried setting open_basedir to no value with all, master and both slaves, but still the same result: internal server error and soft exception

- I also had another chat on the phone with my host and again was told that server side all is ok. they do however wonder how symlinks are being created and why they come with permissions of 777 instead of 755

since server side in general all is ok, suPHP is not being the prob, owners and groups are properly set and open_basedir not being the prob either - no value still returns the errors - what else could it be?

could you please advise?

Hi.

I have exactly the same problem. Also an internal error when trying to access the admin of the slave sites and a soft exception in the error log.
I'm using the most up to date versions of Joomla and MultiSite.

Did you manage to resolve this issue in the end?

The problemm is not in Jms Multi Sites but located in the configuration of the server.
So analyze the error_log to identify the orign of the problem.

In most case, this is a permission problem.