Sticker pack shows sticker as .octet-stream

[kessibi]

Using a supported version?

• [x] I have searched searched open and closed issues for duplicates.
• [x] I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

Upon sending a sticker from a sticker pack1, the desktop application on a MacOS machine reads one of the sticker normally while the other one gets displayed as a .octet-stream file.

Steps to reproduce

1. Go to group chat
2. Send the two stickers to another person
3. See which one they receive or not

The stickers were sent on an Android phone running Signal 7.33.2

Expected result

All stickers in a pack displayed normally

Actual result

One sticker displayed as a file with a .octet-stream extension.

Screenshots

Signal version

7.42.0

Operating system

Apple (Silicon)

Version of Signal on your phone

7.46

Link to debug log

No response

[jamiebuilds-signal]

Could you reproduce the problem and send debug logs from the device that saw "Octet Stream"?

https://support.signal.org/hc/en-us/articles/360007318591-Debug-Logs-and-Crash-Reports

[cYDN48]

Having the same problem on Linux, it's very annoying. It happens both to stickers sent by yourself from a different device as well as stickers received from others. To note is that when you click on the octet-stream and save it somewhere, I can view it like a regular image file (WebP)

debuglog.txt

I spammed a bunch of stickers to test things out, and one sticker arrived as an octet-stream one time (timestamp 1739829369193) and was displayed normally the next (timestamp 1739829406378). But I wasn't able to find any differences in the logs.

I tried resetting the app data (Settings -> Privacy -> Delete application data), and then linked it with the Android app again, importing the last 45 days of data. When viewing the imported chat's history, it looked the exact same. Same stickers were broken, same stickers worked. And receiving new stickers still resulted in octet-streams sometimes.

[jamiebuilds-signal]

@cYDN48 Ah yeah thank you for sending the debuglog, I can see what the error is:

Error: 'sourcePath' must be relative to the user config directory
    at Object.copyIntoAttachmentsDirectory ([REDACTED]/resources/app.asar/preload.bundle.js:210:72860)
    at copyStickerToAttachments ([REDACTED]/resources/app.asar/preload.bundle.js:163:80949)
    at queueAttachmentDownloads ([REDACTED]/resources/app.asar/preload.bundle.js:185:283689)
    at async queueAttachmentDownloadsForMessage ([REDACTED]/resources/app.asar/preload.bundle.js:185:281094)
    at async handleAttachmentDownloadsForNewMessage ([REDACTED]/resources/app.asar/preload.bundle.js:185:281051)
    at async saveAndNotify ([REDACTED]/resources/app.asar/preload.bundle.js:296:5631)

[cYDN48]

I saw that too but the error also occurs when the stickers display normally, so I wasn't sure if that was the cause

[rugk]

Have seen this on Linux flatpak system with KDE (at the receivers side), sender has android app (where all are fine) or flatpaked signal desktop too (also all stickers fine). But it also only seems to affect some stickers. Some others are fine. And the error seems to be bound to specific sticker (sets?). If you send a working one out continues to work, a broken one reproducibly fails.

[cYDN48]

I haven't seen the .octet-stream for some time now. But instead it looks like this now:

Same error in the debuglog:

ERROR 2025-04-14T09:54:08.053Z queueAttachmentDownloads([REDACTED]284.1 1744589207865}): Problem copying sticker (23d92b7bdcf31e7e48ede3c0b35290b4, 32) to attachments: Error: 'sourcePath' must be relative to the user config directory
    at Object.copyIntoAttachmentsDirectory ([REDACTED]/resources/app.asar/preload.bundle.js:209:75221)
    at copyStickerToAttachments ([REDACTED]/resources/app.asar/preload.bundle.js:163:83748)
    at queueAttachmentDownloads ([REDACTED]/resources/app.asar/preload.bundle.js:173:486550)
    at async queueAttachmentDownloadsForMessage ([REDACTED]/resources/app.asar/preload.bundle.js:173:483822)
    at async [REDACTED]/resources/app.asar/preload.bundle.js:189:86738

========= System info ========= App version: 7.50.0 Arch: x64 Environment: production Linux version: "Freedesktop SDK 24.08 (Flatpak runtime)" Node version: 22.14.0 OS version: #1 SMP PREEMPT_DYNAMIC Sun Apr 6 14:13:36 UTC 2025 Time: 1744624542063 User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Signal/7.50.0 Chrome/134.0.6998.179 Electron/35.1.4 Safari/537.36

[cYDN48]

sourcePath is the absolute path of the sticker, and Signal is trying to copy it into the attachments.noindex directory inside the userDataPath.

In the code it is checked whether the destination of the sourcePath is inside the userDataPath, and if not, it fails with the error we see in the logs.

Is there any way to find out what sourcePath and userDataPath Signal is trying to use? I think I know what it should be using, but I don't know what it's actually using

[scottnonnenberg-signal]

@cYDN48 On Linux, your user data directory is ~/.config/Signal by default and the attachments directory will be attachments.noindex under that, and the stickers directory will be stickers.noindex under that. Have you done anything interesting with symlinks, or moving these directories around?

[cYDN48]

Note that I'm using the Flatpak version of Signal, so it should be ~/.var/app/org.signal.Signal/config/Signal/. @kessibi had the .octet-stream issue on a Mac though, so it doesn't sound like it's flatpak-specific (assuming they got the same error as me, no one else has posted their debuglog yet)

No, I haven't done any symlinking or moving of directories. The only symlink that could be relevant is that on my distro /home/ is symlinked to /var/home/

[scottnonnenberg-signal]

@cYDN48 We know why the octet stream issue happened before, and it didn't have anything to do with the path-related errors in your logs. The question is: why are you experiencing this, when others aren't? What's interesting about your setup? What's interesting about your filesystem, such that those 'is the stickers path underneath the config path?' checks are failing?

[cYDN48]

Happy to report that it seems to be fixed (for now?)

I simply uninstalled Signal via Discover and made sure to delete user data (the option pops up in Discover after it's been uninstalled), reinstalled and now it works.

What's weird is that I did try exactly that while I had the .octet-stream issue. Perhaps the .octet-stream issue somehow triggered this bug? So reinstalling it back then didn't work because it wasn't fixed yet and triggered it again? And now that the .octet-streams are fixed it doesn't trigger anymore?

I don't know, but it works for now 😄

There were some people who upvoted my comment before, maybe they can try reinstalling too and upvote/downvote based on the result

If that doesn't fix it for others, they should probably open a new issue, as this issue was originally about the .octet-streams which are now fixed

[cYDN48]

False alarm, it's broken again today.

I reinstalled Signal (Flatpak) again, and then it worked. Then I simply closed Signal and opened it again, and it's broken again. Tested it on the exact same sticker.

Literally 8 seconds apart, same sticker:

INFO  2025-05-13T16:09:10.052Z queueAttachmentDownloads([REDACTED]284.1 1747152551285}): Copying sticker from installed pack
INFO  2025-05-13T16:09:10.054Z queueAttachmentDownloads([REDACTED]284.1 1747152551285}): Queued 1 total attachment downloads
[...]
INFO  2025-05-13T16:09:18.975Z queueAttachmentDownloads([REDACTED]284.1 1747152560256}): Copying sticker from installed pack
ERROR 2025-05-13T16:09:18.976Z queueAttachmentDownloads([REDACTED]284.1 1747152560256}): Problem copying sticker (59cb8565a4511d0c34a75c5a24a8ebec, 53) to attachments: Error: 'sourcePath' must be relative to the user config directory
    at Object.copyIntoAttachmentsDirectory ([REDACTED]/resources/app.asar/preload.bundle.js:209:75249)
    at copyStickerToAttachments ([REDACTED]/resources/app.asar/preload.bundle.js:163:83734)
    at queueAttachmentDownloads ([REDACTED]/resources/app.asar/preload.bundle.js:173:486274)
    at async queueAttachmentDownloadsForMessage ([REDACTED]/resources/app.asar/preload.bundle.js:173:483571)
    at async handleAttachmentDownloadsForNewMessage ([REDACTED]/resources/app.asar/preload.bundle.js:173:483506)
    at async saveAndNotify ([REDACTED]/resources/app.asar/preload.bundle.js:298:5604)

Here's the full debug log:

debuglog.txt

I'm not familiar enough with Signal nor Flatpak to know whether this is a problem with Signal itself, or the Flatpak version specifically. If you think the bug isn't on Signal, you can probably close this issue and I'll move to the flatpak issue.

[jamiebuilds-signal]

@cYDN48 Are you doing anything unusual with your file system? Mounting drives, symlinking folders, maybe using some kind of file backup tool that might be doing things like that? Otherwise I would probably look at the flatpak distribution for a fix.

[cYDN48]

No, I'm not really doing anything weird. I rarely ever mount my Windows drive and the only symlink on the config path is /home/ to /var/home/

[cYDN48]

When I rename attachments.noindex, the attachments and stickers sent from the desktop client (expectedly) break.

When I rename stickers.noindex, the stickers in the sticker selection panel become invisible.

So that means Signal IS using the same userData directory for both.

So my suspicion is isPathInside.ts. If I'm reading it correctly, it's just checking if the resolved childPath (in this case the path to stickers.noindex) starts with the resolved parentPath (in this case the path to the userData).

As previously said, on my system /home/ is a symlink to /var/home/, so maybe for some reason it's resolving the stickers path to be something like /home/[restOfThePath]/stickers.noindex, and the userData path to /var/home/[restOfThePath]? (or the other way around)

Then the check would fail, as both paths start differently, even though they're actually the same.

I have no experience with Typescript or Node, so I'm not sure about the best way to fix this (if it is indeed the issue). But I saw that the is-path-inside npm module that inspired Signal's implementation is doing it differently now, and I found this stackoverflow answer that might be useful

[rugk]

As previously said, on my system /home/ is a symlink to /var/home/, so maybe for some reason it's resolving the stickers

That's a good observation, so maybe this issue only affects ~~immutable~~ atomic distros like Fedora Silverblue or so? Though I never had the issue, but if it's also related to flatpak, downstream issue seems to be: https://github.com/flathub/org.signal.Signal/issues/870

[LittleFox94]

Hi, I have this problem as well - my ~/.config is symlinked since it lives in a git repository, tho the rest of my system is a pretty standard debian testing (well, at least one of my systems with this problem is)

[jamiebuilds-signal]

@LittleFox94 Could you reproduce the issue and capture a debug log? https://support.signal.org/hc/en-us/articles/360007318591-Debug-Logs-and-Crash-Reports

[JoshuaKimsey]

As previously said, on my system /home/ is a symlink to /var/home/, so maybe for some reason it's resolving the stickers

That's a good observation, so maybe this issue only affects ~immutable~ atomic distros like Fedora Silverblue or so? Though I never had the issue, but if it's also related to flatpak, downstream issue seems to be: flathub/org.signal.Signal#870

I'm on Bazzite and can confirm this issue exists for me and another I know who installed it as well. It does seem to be something that affects atomic distros due to the symlinked /var/home/ thing.

[rugk]

Yeah it sounds very much as you said:

It does seem to be something that affects atomic distros due to the symlinked /var/home/ thing.

Similar issue seems to have exites in brew e.g.: https://github.com/Homebrew/brew/pull/15656 (IIRC UBlue/Aurora also wrote somewhere they work around that.)

Anyway, a PR with a solution seems to be there already: https://github.com/signalapp/Signal-Desktop/pull/7448

Next time, if it is so distro-specific it may also be worthwhile to [report it downstream to the distro then](https://github.com/ublue-os/main/issues?q=is%3Aissue%20state%3Aclosed signal), BTW.

[JoshuaKimsey]

So to resolve this, the PR #7448 has a request for some changes to it. Does anyone here have experience working with Signal Desktop that could help possibly add those to aid in getting this fixed?

[JoshuaKimsey]

Just received an update and it appears as though this issue is now fixed. Worth checking to see if it's fixed for y'all as well.

[cYDN48]

Seems to be fixed for me as well in version 7.71.0

Update: It is fixed only for installed sticker packs. If someone sends a sticker from a pack you don't have, it still shows up the same. Following error in the log:

INFO  2025-09-20T10:50:27.499Z [queueAttachmentDownloads] queueAttachmentDownloads([REDACTED]7cb.1 1758365425159}): Copying sticker from installed pack
ERROR 2025-09-20T10:50:27.500Z [queueAttachmentDownloads] queueAttachmentDownloads([REDACTED]7cb.1 1758365425159}): Problem copying sticker (23bb56356ddc12b30d18ba4684d4b609, 0) to attachments: Error: ENOENT: no such file or directory, lstat '/var/home/cYDN48/.var/app/org.signal.Signal/config/Signal/stickers.noindex/9d/[REDACTED]7a9'

Note it says "Copying sticker from installed pack", even though the sticker is from a pack that I don't have installed. But I don't know if that is intended or not

[indutny-signal]

Happy to hear this! Thank you!

[cYDN48]

Hey @indutny-signal,

what about the issue I mentioned my last comment? For me this issue has only been partially fixed

Partial fix is already better than no fix though, so I'm still thankful. 😄 This issue has been annoying me for a long time

[indutny-signal]

@cYDN48 sorry, I missed that! Could you check if the path from error exists on disk?

[cYDN48]

The directory exists, but the file doesn't

[indutny-signal]

@cYDN48 could you try reinstalling the sticker pack? I wonder if it got messed up due to previous issues with symlinked folder?

[cYDN48]

I can't reinstall it because it wasn't installed in the first place 😄

This new issue seems to only happen when the person you're chatting with sends you a sticker from a pack that you don't have installed.

The other sticker packs (the ones I do have installed) work fine now after the fix in 7.71.0

[indutny-signal]

I'll take a look. Thank you for your patience!