Configured attachments location is ignored when set to a shared folder: attachments still uploaded to root

[sebastienaubry]

Steps to reproduce

Context

This report follows on from #7947, which describes the underlying problem: attachments added to events on a shared calendar are not accessible to other users with access to that calendar, since Nextcloud stores them by default in the attaching user's personal Files space rather than somewhere shared.

As a workaround, we manually share a dedicated folder (owned by the calendar's service account) with all users who need to add event attachments, and set it as the "default attachments location" in Calendar settings. This report describes a separate bug we ran into while setting up that workaround.

Steps to reproduce

1. As a non-admin user with write access to a calendar shared by another account (a "service" account owning the calendar), open Calendar settings.
2. Under "Files", set "Default attachments location" to a folder that is shared with this user (mounted from another account), e.g. /Affiches_Calendrier.
3. Confirm the setting is saved (it displays correctly, e.g. /Affiches_Calendrier, folder icon shown).
4. Open an event on the shared calendar and add an attachment via "Upload from device".

Expected behavior

The uploaded file is stored inside /Affiches_Calendrier (the configured default attachments location), as it does when the same setting points to a native folder.

Actual behavior

The file is uploaded to the root of the user's personal Files space (/), ignoring the configured default attachments location. This happens even though the shared folder is clearly visible and accessible at the expected path (confirmed via the Files app, same user session).

Furthermore, after the upload, the "Attachments folder" setting itself is silently reset to / (visible when reopening Calendar settings), even though it had been correctly saved as /Affiches_Calendrier just before the upload. So the bug is not only that the setting is ignored once, but that the stored value is actively overwritten back to root.

The resulting ATTACH line in the exported ICS also differs depending on how the file was added:

• File manually placed in the shared folder, then attached via "Add from files": FILENAME=/Affiches_Calendrier/nom.jpg (or /Calendar/nom.jpg when the folder was still named "Calendar")
• File attached via "Upload from device" while default location points to the shared folder: FILENAME=/nom.jpg (no path, file lands in root)

Workaround found

Manually uploading the file into the shared folder first (via the Files app), then attaching it to the event via "Add from files" (browsing to the shared folder), works reliably: the file stays in the shared folder and the ATTACH FILENAME reflects the correct path.

"Upload from device" directly on the event, or relying on the "Default attachments location" setting when it points to a shared/mounted folder, does not.

Calendar app version

6.2.1

CalDAV-clients used

No response

Browser

No response

Client operating system

No response

Server operating system

No response

Web server

None

Database engine version

None

PHP engine version

None

Nextcloud version

32.0.6

Updated from an older installed version or fresh install

None

List of activated apps

Nextcloud configuration

Web server error log

Log file

Browser log

Additional info

Environment

• Nextcloud Hub instance (Framaspace hosting)
• Calendar shared by a service/association account, non-admin user testing with write access to that calendar and the shared attachments folder
• Reproduced consistently across multiple test files

Additional context

This bug appears to be a specific manifestation of the workaround needed for #7947: since Nextcloud does not automatically share attachments with calendar recipients, we rely on a manually shared folder as the attachment location, and this is the setting that fails to be honored. This may be related to how the app resolves the configured attachment folder path against the current user's home storage versus a mounted external/shared storage. The setting itself displays and saves correctly (no error shown to the user), which makes the bug easy to miss until attachments end up scattered in users' root folders instead of the shared location intended for team visibility.

These shared attachments feed a small PHP application we built on top of the ICS export, which automatically generates our public event agenda: https://dvdtoile.com/spontex/huit/agenda.php and a monthly poster view at https://dvdtoile.com/spontex/huit/agenda-mensuel.php. Reliable attachment locations matter for us because event posters are pulled directly from these files.

This bug report was drafted with the help of Claude, Anthropic's AI assistant, based on testing and screenshots gathered by the reporter.