-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Sharing links with null labels broken after upgrade to NC-30 #48629
Comments
The issue can apparently be worked around by changing the label in the backend database from UPDATE oc_share SET label = '' WHERE label IS null AND token IS NOT null; However, I guess this ought to be done somewhat automatically by the maintenance scripts. EDIT Also given that the default value for the |
Can confirm this same issue on our install, the only varying factor is that we use MariaDB and not PostgreSQL. Same PHP version too and also similar upgrade path taken. |
Disable |
@myomv100 care to explain? |
@umlaeute I had a similar issue with download limiter enabled in NC30. If disabling it solved my problem and yours then , there is something needs to be done to the download limiter app to make it compatible with NC30. That's all I know. |
you probably should report it as a separate issue then (unless they are indeed related, which i cannot test any more, as i have replaced all my |
I disabled the addon and asked one of our users to test this but I have a feeling this is not related to the problem here. I haven't nulled the DB yet myself so I can test various things on it. Edit: This did not fix the issue. Most likely it's the same NULL value issue as umlaeuteop has. |
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
I have exactly the same problem and i dont have installed the files_downloadlimit and it only affects links shared more then 2 years ago... |
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
I have had a client with this issue, disabling the the |
(I was using PostgreSQL, though the update suggestion is pure SQL anyhow) @chriscroome out of interest: which DB is the client using? (most DBs distinguish between NULL and empty strings, but some do not - most notably oracle) |
Fixed in current master, 29.0.9 and 30.0.2. |
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
* Resolves: #48629 While the database supports NULL, the typing has always said it only returns *string*. So to not break any apps that might trust the typings we should return `''` if the database is set to `NULL`. Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
Bug description
I'm running a Nextcloud instance on Debian/bookworm
Last week, I upgraded the old NC-29.0.3.4 instance to (first)
29.0.7.1
and once that looked good enough, continued to upgrade to30.0.0.14
.Now one of users reported, that one of their public sharing links no longer works - a link that used to work (according to them) for the last years without any issues whatsoever.
I can confirm their observation that whenever somebody visits the public sharing link, they get an "Internal Server Error":
The file in question is an mp4 video file.
Steps to reproduce
I'm aware that there is more to it. I know of other public sharing links that continue to work.
Expected behavior
I expect that sharing links continue to work across upgrades.
More-over I expect that no "Internal Server Error" is thrown.
Nextcloud Server version
30
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 28 to 29)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Enabled:
Disabled:
Nextcloud Signing status
No errors have been found.
Nextcloud Logs
(note that the
remoteAddr
has been obfuscated)Additional info
if I read the error correctly,
setHeaderTitle()
is called with anull
value (rather than a string), and PHP8.2 is a bit more picky about this.I guess that the share is really old and was not assigned a title/label back then.
I've tried running various maintenance tasks (including
maintenance:repair --include-expensive
,db:add-missing-columns
;files:repair
- but really every command that looked like it could fix potential problems), to no avail.The text was updated successfully, but these errors were encountered: