Did something significant change about the 10.7 version as compared to the 10.6 version?

[Douglas Thompson]

I ask, because when I do the "svn switch ^/releases/10.7" thing listed on this page:

https://www.resourcespace.com/knowledge-base/systemadmin/upgrading

And then try to load RS, instead of seeing the login screen or anything, I get a "500 internal server error".

If I back it to 10.6 using "svn switch ^/releases/10,.6", everything works fine.

(So, I'm unable to upgrade it to 10.7 for some reason)

It's entirely possible that there's some server component that's preventing this because it's not recent enough, but I didn't have time to try to track that down or anything.

Just curious,

[SimLofi.Com]

A 500 Internal Server Error after switching to RS 10.7 via SVN usually indicates a PHP error or incompatible server component (like an outdated PHP version or missing extension). Since it works fine when you switch back to 10.6, 10.7 likely introduced something that your current server environment can't support.

A few things you can check:

1. PHP Version
   ResourceSpace 10.7 may require a newer PHP version than 10.6. Could you make sure your server is running at least PHP 8.1? See the composer.json                                                                                                                             "require": {

           "php": "8.1 - 8.3",
           "ext-mbstring": "*",
           "ext-intl": "*",
           "ext-curl": "*",
           "ext-dom": "*",
           "ext-zip": "*",
           "ext-gd": "*",
           "ext-mysqli": "*",
           "ext-json": "*"
       },

2. Error Logs
   Check your Apache error logs. That’ll help confirm what exactly is failing.

3. Required Extensions
   ResourceSpace sometimes adds new PHP extension dependencies (like intl, mbstring, etc.) between versions. See point 1.     

4. File Permissions
   SVN switch sometimes results in files with incorrect ownership or permissions. Running:

   sudo chown -R www-data:www-data /path/to/resourcespace
   sudo find /path/to/resourcespace -type d -exec chmod 755 {} \;
   sudo find /path/to/resourcespace -type f -exec chmod 644 {} \;
   

   (adjust user/group based on your server config) might help rule that out.

Regards

Ade Owolabi

Moto: Listen. Think. Create

SimloFiTech Luton

--
ResourceSpace: Open Source Digital Asset Management
http://www.resourcespace.com
---
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resourcespac...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/resourcespace/05c4f685-c92c-4e31-b877-1b8c456299f5n%40googlegroups.com.

[Dan Huby]

Hi Douglas, 

Sorry for the late reply. The clue will be in your web server error log. For Apache that's normally something like:

/var/log/apache2/error.log

That will tell you what the specific issue is. It's likely PHP version. 

Dan

[Douglas Thompson]

For me, it ended up being (I think) in the ssl_error_log file in the /var/log/httpd directory on the server:

But, as far as I can tell, it's not PHP version:

AH01276: Cannot serve directory /var/www/html/rsspace: No matching DirectoryIndex (index.html,index.php) found, and server-generated directory index forbidden by Options directive

But that error doesn't happen with RS 10.6, so if I'm reading this correctly (and I'm not very well-versed in server/programming stuff, btw), then it thinks it's missing the index.php file in that directory, but I just checked and that's there (and nearly identical) in both instances.

Another nail in the "it's likely PHP Version" coffin is the fact that a php -v says we have PHP v8.2.28

This page: https://www.resourcespace.com/knowledge-base/systemadmin/general_requirements

Says that RS requires PHP v8.1, v8.2, v8.3, or v8.4 for RS v10.6+, so v8.2.28 should be okay in that regard.

While on that page, I checked our MariaDB version, our Apache version, and our PHP extensions: That page says RS requires MariaDB v10.0.1+ (and we have v15.1, according to a "mysql -V"). That page says RS requires Apache v2.4+ (and we have v2.4.37 according to a "httpd -v"). That page lists PHP extensions that RS requires and a "php -m" reveals that we have them all except for php-ldap, php-imap, and php-cli (which, to my understanding, are all bits of RS functionality that we don't use: LDAP, IMAP, and Command Line Interface stuff). That's the only discrepancy that I'm seeing, though...maybe one (or more) of those extensions are required even if they're not actively being used by us for anything?

[Dan Huby]

It couldn't find index.php in 10.7 but it could in 10.6? That doesn't make any sense at all to me and I think something else must be going on other than the ResourceSpace upgrade.

Is this repeatable, as in, can you "svn switch" between the two, changing nothing else, and the problem occurs every time?

[Douglas Thompson]

Yeah I can svn switch between the two and the problem only happens when I switch to 10.7. I can switch back to 10.6 and it works with no errors.

The more I think about it, I'm thinking the index.php thing may be unrelated and just crept in when I was trying various things.

So I guess the big question is whether those three PHP extensions that we don't currently have are needed (despite them being, I think, for RS functionality that we do not use)

[Dan Huby]

Did you check file permissions? Perhaps the files are no longer readable by the web server after the switch.

--

ResourceSpace: Open Source Digital Asset Management
http://www.resourcespace.com
---

You received this message because you are subscribed to a topic in the Google Groups "ResourceSpace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/resourcespace/Efv0P2an084/unsubscribe.
To unsubscribe from this group and all its topics, send an email to resourcespac...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/resourcespace/02636237-031c-4c4d-9e6d-06c39f465f3bn%40googlegroups.com.

[Douglas Thompson]

So the error that's coming up in my browser when I try to access RS after the "svn switch" thing is:

"500 Internal Server Error"

(in case that helps anything)

Either way, though the ownership is the same for v10.7 as it is for v10.6, so that's not the culprit...

And the file permissions on the "include" folder are identical (I did a "sudo chmod -R 750 include/" just to be sure) for the two RS versions yet the problem persists, so that's not the culprit...

[Douglas Thompson]

So update on this one. We upgraded the OS of the server that RS was running on, so now it definitely meets/exceeds all system requirements, but it's still doing the same thing: RS v10.6 works fine, but when I do the "svn switch" stuff from https://www.resourcespace.com/knowledge-base/systemadmin/upgrading to upgrade it to v10.7, it no longer works. When I use the same command to change it to v10.6, it all works properly again...I have our IS guy looking through the server log files right now to see if he can pinpoint the culprit, but that's probably a long shot.

Anyway, I was hoping that the upgrade process would work relatively smoothly now, especially in advance of the significant RS v11.0 update that's dropping at the end of the month...but nope...

[Dan Huby]

The answer is usually pretty obvious from the log files. Likely a missing dependency such as a PHP module not installed, or an unsupported PHP version. 

The web server's error log is the first place to look when you get a 500 Server Error.  

[Douglas Thompson]

Yup. In fact, this is what our IT guy here found:

"i found this error in the php-fpm logs: [08-Jun-2026 18:42:18 UTC] PHP Fatal error:  Uncaught Error: Undefined constant "PASSWORD_ARGON2ID" in /var/www/html/rsspace/include/config.php:1169" and later, "i tried installing the php-sodium package, which reportedly provides the argon2 encryption libraries, but got an error: Problem: package php-sodium-8.0.30-2.el9.x86_64 from epel requires php(api) = 20200930-64, but none of the providers can be installed". A little bit later, he said: "i tried deleting and rebuilding the package cache, but still got the same error" and then "if the lack of argon2 support is the issue, and if php-sodium is needed to provide the support, then you may have to wait until the EPEL package maintainers fix whatever's broken with the package dependencies." and "i found more detail about the issue - the EPEL php-sodium package was built for php 8.0, but we bumped up to php 8.2.30. we might be able to downgrade php if you want to try that, though i don't know what else may break."

So, our decision is basically to kick the can down the road and see what happens with the v11 upgrade. v10.6 works for us just fine, so we'll stick with that for now. If that has an error (which is very likely to have the same error), then we'll look into fixing it. With any luck, maybe the "EPEL package maintainers" that he mentioned will have fixed whatever they need to fix on their end.

[Dan Huby]

Hi Douglas,

Your build of PHP is missing Argon2id password-hashing support, and
you'll definitely still hit this with ResourceSpace 11.0 as that
requirement hasn't been dropped.

It looks like you're having a dependency issue, possibly caused by using
mixed / non standard repositories.

A fresh server build might cure the issue.

Dan

On 09/06/2026 14:24, Douglas Thompson wrote:
> Yup. In fact, this is what our IT guy here found:
>
> "i found this error in the php-fpm logs: [08-Jun-2026 18:42:18 UTC] PHP
> Fatal error:  Uncaught Error: Undefined constant "PASSWORD_ARGON2ID"
> in /var/www/html/rsspace/include/config.php:1169" and later, "i tried
> installing the php-sodium package, which reportedly provides the argon2
> encryption libraries, but got an error: Problem: package php-
> sodium-8.0.30-2.el9.x86_64 from epel requires php(api) = 20200930-64,
> but none of the providers can be installed". A little bit later, he
> said: "i tried deleting and rebuilding the package cache, but still got
> the same error" and then "if the lack of argon2 support is the issue,
> and if php-sodium is needed to provide the support, then you may have to
> wait until the EPEL package maintainers fix whatever's broken with the
> package dependencies." and "i found more detail about the issue - the
> EPEL php-sodium package was built for php 8.0, but we bumped up to php
> 8.2.30. we might be able to downgrade php if you want to try that,
> though i don't know what else may break."
>
> So, our decision is basically to kick the can down the road and see what
> happens with the v11 upgrade. v10.6 works for us just fine, so we'll

> stick with that for now. If /that/ has an error (which is /very/ likely
> to have the /same/ error), /then/ we'll look into fixing it. With any

> luck, maybe the "EPEL package maintainers" that he mentioned will have

> fixed /whatever/ they need to fix on their end.

>
> On Tuesday, June 9, 2026 at 4:22:37 AM UTC-4 Dan Huby wrote:
>
> The answer is usually pretty obvious from the log files. Likely a
> missing dependency such as a PHP module not installed, or an
> unsupported PHP version.
> The web server's error log is the first place to look when you get a
> 500 Server Error.
>
>
> On Monday, 8 June 2026 at 19:52:07 UTC+1 Douglas Thompson wrote:
>
> So update on this one. We upgraded the OS of the server that RS

> was running on, so now it definitely meets/exceeds /all/ system
> requirements, but it's /still/ doing the same thing: RS v10.6

> works fine, but when I do the "svn switch" stuff from https://
> www.resourcespace.com/knowledge-base/systemadmin/upgrading

> <https://www.resourcespace.com/knowledge-base/systemadmin/
> upgrading> to upgrade it to v10.7, it no longer works. When I

> use the same command to change it to v10.6, it all works
> properly again...I have our IS guy looking through the server
> log files right now to see if he can pinpoint the culprit, but
> that's probably a long shot.
>

> Anyway, I was /hoping/ that the upgrade process would work
> relatively smoothly now, especially in advance of the /
> significant/ RS v11.0 update that's dropping at the end of the

> month...but nope...
>
> On Friday, December 12, 2025 at 10:36:40 AM UTC-5 Douglas
> Thompson wrote:
>
> So the error that's coming up in my browser when I try to
> access RS after the "svn switch" thing is:
>
> "500 Internal Server Error"
>
> (in case that helps anything)
>

> Either way, though the ownership is the /same/ for v10.7 as
> it is for v10.6, so /that's/ not the culprit...
>
> And the file permissions on the "include" folder are /
> identical/ (I did a "sudo chmod -R 750 include/" just to be
> sure) for the two RS versions yet the problem persists, so /
> that's/ not the culprit...

>
> On Friday, December 12, 2025 at 10:02:07 AM UTC-5 Dan Huby
> wrote:
>

> __

>
> Did you check file permissions? Perhaps the files are no
> longer readable by the web server after the switch.
>
>
> On 12/12/2025 14:59, 'Dan Huby' via ResourceSpace wrote:
>> It couldn't find index.php in 10.7 but it could in
>> 10.6? That doesn't make any sense at all to me and I
>> think something else must be going on other than the
>> ResourceSpace upgrade.
>> Is this repeatable, as in, can you "svn switch"
>> between the two, changing nothing else, and the
>> problem occurs every time?
>>
>> On Friday, 12 December 2025 at 14:52:17 UTC Douglas
>> Thompson wrote:
>>

>> For /me/, it ended up being (I think) in the

>> ssl_error_log file in the /var/log/httpd directory
>> on the server:
>>

>> But, as far as I can tell, it's /not/ PHP version:

>>
>> AH01276: Cannot serve directory /var/www/html/
>> rsspace: No matching DirectoryIndex
>> (index.html,index.php) found, and server-generated
>> directory index forbidden by Options directive
>>

>> But that error /doesn't/ happen with RS 10.6, so
>> if I'm reading this correctly (and I'm /not/ very

>> well-versed in server/programming stuff, btw),

>> then it /thinks/ it's missing the index.php file

>> in that directory, but I just checked and that's

>> there (and nearly identical) in /both/ instances.

>>
>> Another nail in the "it's likely PHP Version"
>> coffin is the fact that a php -v says we have PHP
>> v8.2.28
>>
>> This page: https://www.resourcespace.com/
>> knowledge-base/systemadmin/general_requirements

>> <https://www.resourcespace.com/knowledge-base/
>> systemadmin/general_requirements>

>>
>> Says that RS requires PHP v8.1, v8.2, v8.3, or

>> v8.4 for RS v10.6+, so v8.2.28 /should/ be okay
>> in /that/ regard.

>>
>> While on that page, I checked our MariaDB version,
>> our Apache version, and our PHP extensions: That
>> page says RS requires MariaDB v10.0.1+ (and we
>> have v15.1, according to a "mysql -V"). That page
>> says RS requires Apache v2.4+ (and we have v2.4.37
>> according to a "httpd -v"). That page lists PHP
>> extensions that RS requires and a "php -m" reveals

>> that we have them all /except/ for php-ldap, php-

>> imap, and php-cli (which, to my understanding, are

>> all bits of RS functionality that we /don't/ use:

>> LDAP, IMAP, and Command Line Interface stuff).

>> That's the /only/ discrepancy that I'm seeing,

>> though...maybe one (or more) of those extensions

>> are required even if they're /not/ actively
>> being /used/ by us for anything?

>>
>> On Friday, December 12, 2025 at 7:21:29 AM UTC-5
>> Dan Huby wrote:
>>
>> Hi Douglas,
>>
>> Sorry for the late reply. The clue will be in
>> your web server error log. For Apache that's
>> normally something like:
>>
>> /var/log/apache2/error.log
>>
>> That will tell you what the specific issue is.
>> It's likely PHP version.
>>
>> Dan
>>
>>
>> On Tuesday, 25 November 2025 at 18:36:55 UTC
>> Douglas Thompson wrote:
>>
>> I ask, because when I do the "svn switch

>> ^/releases/10.7" thing listed on /this/ page:
>>
>> https://www.resourcespace.com/knowledge-
>> base/systemadmin/upgrading <https://
>> www.resourcespace.com/knowledge-base/
>> systemadmin/upgrading>

>>
>> And then try to load RS, instead of seeing
>> the login screen or anything, I get a "500
>> internal server error".
>>
>> If I back it to 10.6 using "svn switch ^/

>> releases/10,.6", everything works /fine/.

>>
>> (So, I'm unable to upgrade it to 10.7 for
>> some reason)
>>

>> It's entirely possible that there's /
>> some/ server component that's preventing

>> this because it's not recent enough, but I

>> didn't have time to try to track /
>> that/ down or anything.

>>
>> Just curious,
>>
>> --
>> ResourceSpace: Open Source Digital Asset Management

>> http://www.resourcespace.com <http://
>> www.resourcespace.com>

>> ---
>> You received this message because you are subscribed
>> to a topic in the Google Groups "ResourceSpace" group.
>> To unsubscribe from this topic, visit https://
>> groups.google.com/d/topic/resourcespace/Efv0P2an084/

>> unsubscribe <https://groups.google.com/d/topic/
>> resourcespace/Efv0P2an084/unsubscribe>.

>> To unsubscribe from this group and all its topics,
>> send an email to resourcespac...@googlegroups.com.
>> To view this discussion, visit https://
>> groups.google.com/d/msgid/

>> resourcespace/02636237-031c-4c4d-9e6d-06c39f465f3bn%40googlegroups.com <https://groups.google.com/d/msgid/resourcespace/02636237-031c-4c4d-9e6d-06c39f465f3bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> ResourceSpace: Open Source Digital Asset Management

> http://www.resourcespace.com <http://www.resourcespace.com>

> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ResourceSpace" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/

> resourcespace/Efv0P2an084/unsubscribe <https://groups.google.com/d/
> topic/resourcespace/Efv0P2an084/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to
> resourcespac...@googlegroups.com

> <mailto:resourcespac...@googlegroups.com>.

> To view this discussion, visit https://groups.google.com/d/msgid/

> resourcespace/1ce21667-aafb-4ae9-93ba-9fd961af3d0cn%40googlegroups.com
> <https://groups.google.com/d/msgid/resourcespace/1ce21667-
> aafb-4ae9-93ba-9fd961af3d0cn%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[Douglas Thompson]

I'll let the IS guy know. This is basically "All Greek to Me" at this point :P