#846 - [GH-ISSUE #1170] [Bug]: P2S - every print falls back to "no 3MF available"; FTPS returns 550 for all 3MF probe paths - starred/bambuddy

BreizhHardware commented

2026-05-06 12:33:22 +02:00

Owner

Originally created by @MacheteBang on GitHub (Apr 29, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1170

Originally assigned to: @maziggy on GitHub.

Component

Bambuddy

Bug Description

Every print I send to my Bambu Lab P2S from Bambu Studio ends up as a "no 3MF available" fallback archive. There's no error in the logs, just no source 3MF.

The sequence is the same for every P2S print:

MQTT reports PRINT START with file: /data/Metadata/plate_1.gcode and a usable subtask_name.
Bambuddy derives the candidate filenames ['<subtask>.gcode.3mf', '<subtask>.3mf', 'plate_1.gcode.3mf', 'plate_1.3mf'] and probes them across /, /cache/, /model/, /data/, and /data/Metadata/ on the printer's FTPS.
Every single probe returns 550 Failed to open file. (not on printer).
Bambuddy then runs the "search directories" fallback (a few follow-up FTPS connects), still finds nothing, and finally creates a fallback archive: Could not find 3MF file for print: /data/Metadata/plate_1.gcode, then Created fallback archive N for <subtask> (no 3MF available).

Downstream, the archive has no source 3MF, no thumbnail (the cover-image fetch goes through the same paths), and none of the slicer-derived metadata.

The same Bambuddy instance handles a Bambu A1 on the same network without issue. For the A1 I can see the slicer-side FTPS upload land (STOR confirmed: 226) and Bambuddy then reads the 3MF cover image back. Only the P2S is broken, so the install, network, MQTT, and Bambuddy logic all appear to be working.

I tested every combination of slicer storage setting and physical USB on the P2S in Bambu Studio:

Slicer Storage	USB drive in P2S	Result
Internal	not attached	fallback archive
Internal	attached	fallback archive
External	not attached	fallback archive
External	attached	fallback archive

Every combination produces the same 550 Failed to open file on every probe path. The slicer reports the print starting normally and MQTT reports a clean subtask_name, so the slicer thinks it's doing its job. Even with a USB drive plugged in, the .gcode.3mf does not appear anywhere Bambuddy can find it over FTPS.

There was at least one earlier print on this same P2S that landed as a normal, fully populated archive with metadata, so the printer side is capable of producing one. I haven't been able to figure out what was different about that print.

Expected Behavior

A print sent to the P2S from Bambu Studio, under any of the storage and USB combinations above, should result in Bambuddy locating the .gcode.3mf somewhere readable and producing a normal archive with the source 3MF, thumbnail, and slicer metadata. That's what it does for the A1.

Steps to Reproduce

Bambu Lab P2S in LAN-Only Mode with Developer Mode enabled, Access Code recorded.
Bambu Studio sees that printer in LAN mode.
Slice any project and send the print from the slicer.
Watch docker logs bambuddy -f. Within roughly 30 seconds of PRINT START you'll see the probe sequence end with Could not find 3MF file for print: /data/Metadata/plate_1.gcode, then Created fallback archive N for <subtask_name> (no 3MF available).
Open that archive in the Bambuddy UI: no source 3MF, no thumbnail, no metadata.

Printer Model

P2S

Bambuddy Version

0.2.3.2

SpoolBuddy Version

No response

Printer Firmware Version

01.02.00.00

Installation Method

Docker

Operating System

Linux (Other)

Relevant Logs / Support Package

bambuddy-support-20260430-171835.zip

Screenshots

No response

Additional Context

One earlier success on the same printer: at least one previous print on this P2S landed as a normal non-fallback archive with full metadata. Every print since has been a fallback. I haven't been able to isolate what was different about that one print. I think this was before the P2S firmware was updated
Workaround in use: I manually drop the slicer's .gcode.3mf into the archive folder, point print_archives.file_path and source_3mf_path at it, POST /api/v1/archives/<id>/rescan, and unzip Metadata/plate_1.png for the thumbnail. Works fine but doesn't scale. Every P2S print needs this
Possibly related: #1117 reports the same end symptom (empty fallback archive, no 3MF, no thumbnail) on an H2D, but the reporter says it's sporadic and couldn't reproduce reliably. My case reproduces 100% of the time on the P2S, so if the underlying cause is the same, this might be a more useful repro to chase it from.

Checklist

I have searched existing issues to ensure this bug hasn't already been reported
I am using the latest version of Bambuddy
My printer is set to LAN Only mode
My printer has Developer Mode enabled

Originally created by @MacheteBang on GitHub (Apr 29, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1170 Originally assigned to: @maziggy on GitHub. ### Component Bambuddy ### Bug Description Every print I send to my Bambu Lab P2S from Bambu Studio ends up as a "no 3MF available" fallback archive. There's no error in the logs, just no source 3MF. The sequence is the same for every P2S print: 1. MQTT reports `PRINT START` with `file: /data/Metadata/plate_1.gcode` and a usable `subtask_name`. 2. Bambuddy derives the candidate filenames `['<subtask>.gcode.3mf', '<subtask>.3mf', 'plate_1.gcode.3mf', 'plate_1.3mf']` and probes them across `/`, `/cache/`, `/model/`, `/data/`, and `/data/Metadata/` on the printer's FTPS. 3. Every single probe returns `550 Failed to open file. (not on printer)`. 4. Bambuddy then runs the "search directories" fallback (a few follow-up FTPS connects), still finds nothing, and finally creates a fallback archive: `Could not find 3MF file for print: /data/Metadata/plate_1.gcode`, then `Created fallback archive N for <subtask> (no 3MF available)`. Downstream, the archive has no source 3MF, no thumbnail (the cover-image fetch goes through the same paths), and none of the slicer-derived metadata. The same Bambuddy instance handles a Bambu A1 on the same network without issue. For the A1 I can see the slicer-side FTPS upload land (`STOR confirmed: 226`) and Bambuddy then reads the 3MF cover image back. Only the P2S is broken, so the install, network, MQTT, and Bambuddy logic all appear to be working. I tested every combination of slicer storage setting and physical USB on the P2S in Bambu Studio: | Slicer Storage | USB drive in P2S | Result | | --- | --- | --- | | Internal | not attached | fallback archive | | Internal | attached | fallback archive | | External | not attached | fallback archive | | External | attached | fallback archive | Every combination produces the same `550 Failed to open file` on every probe path. The slicer reports the print starting normally and MQTT reports a clean `subtask_name`, so the slicer thinks it's doing its job. Even with a USB drive plugged in, the `.gcode.3mf` does not appear anywhere Bambuddy can find it over FTPS. There was at least one earlier print on this same P2S that landed as a normal, fully populated archive with metadata, so the printer side is capable of producing one. I haven't been able to figure out what was different about that print. ### Expected Behavior A print sent to the P2S from Bambu Studio, under any of the storage and USB combinations above, should result in Bambuddy locating the `.gcode.3mf` somewhere readable and producing a normal archive with the source 3MF, thumbnail, and slicer metadata. That's what it does for the A1. ### Steps to Reproduce 1. Bambu Lab P2S in LAN-Only Mode with Developer Mode enabled, Access Code recorded. 2. Bambu Studio sees that printer in LAN mode. 3. Slice any project and send the print from the slicer. 4. Watch `docker logs bambuddy -f`. Within roughly 30 seconds of `PRINT START` you'll see the probe sequence end with `Could not find 3MF file for print: /data/Metadata/plate_1.gcode`, then `Created fallback archive N for <subtask_name> (no 3MF available)`. 5. Open that archive in the Bambuddy UI: no source 3MF, no thumbnail, no metadata. ### Printer Model P2S ### Bambuddy Version 0.2.3.2 ### SpoolBuddy Version _No response_ ### Printer Firmware Version 01.02.00.00 ### Installation Method Docker ### Operating System Linux (Other) ### Relevant Logs / Support Package [bambuddy-support-20260430-171835.zip](https://github.com/user-attachments/files/27262084/bambuddy-support-20260430-171835.zip) ### Screenshots _No response_ ### Additional Context - One earlier success on the same printer: at least one previous print on this P2S landed as a normal non-fallback archive with full metadata. Every print since has been a fallback. I haven't been able to isolate what was different about that one print. *I think this was before the P2S firmware was updated* - Workaround in use: I manually drop the slicer's `.gcode.3mf` into the archive folder, point `print_archives.file_path` and `source_3mf_path` at it, `POST /api/v1/archives/<id>/rescan`, and unzip `Metadata/plate_1.png` for the thumbnail. Works fine but doesn't scale. Every P2S print needs this - Possibly related: #1117 reports the same end symptom (empty fallback archive, no 3MF, no thumbnail) on an H2D, but the reporter says it's sporadic and couldn't reproduce reliably. My case reproduces 100% of the time on the P2S, so if the underlying cause is the same, this might be a more useful repro to chase it from. ### Checklist - [x] I have searched existing issues to ensure this bug hasn't already been reported - [x] I am using the latest version of Bambuddy - [x] My printer is set to LAN Only mode - [x] My printer has Developer Mode enabled

BreizhHardware added the

feedback

bug

labels

2026-05-06 12:33:22 +02:00

BreizhHardware commented

2026-05-06 12:33:23 +02:00

Author

Owner

@maziggy commented on GitHub (Apr 30, 2026):

Please upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

@maziggy commented on GitHub (Apr 30, 2026): Please upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

BreizhHardware commented

2026-05-06 12:33:23 +02:00

Author

Owner

@MacheteBang commented on GitHub (Apr 30, 2026):

Please upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging

Uploaded directly to ticket. Thanks!

@MacheteBang commented on GitHub (Apr 30, 2026): > Please upload a support package -> https://wiki.bambuddy.cool/features/system-info/?h=debug#enable-debug-logging Uploaded directly to ticket. Thanks!

BreizhHardware commented

2026-05-06 12:33:23 +02:00

Author

Owner

@maziggy commented on GitHub (May 1, 2026):

This should already be fixed. Please use latest daily build and let me know if it works for you.

@maziggy commented on GitHub (May 1, 2026): This should already be fixed. Please use latest daily build and let me know if it works for you.

BreizhHardware commented

2026-05-06 12:33:23 +02:00

Author

Owner

@maziggy commented on GitHub (May 6, 2026):

Did you follow the install instructions?

@maziggy commented on GitHub (May 6, 2026): Did you follow the install instructions? <img width="850" height="403" alt="Image" src="https://github.com/user-attachments/assets/14713f85-481d-4632-922f-77791410ba60" />

BreizhHardware referenced this issue

2026-05-06 12:35:21 +02:00

[PR #1029] [MERGED] v0.2.3 final #1149

Rows
Columns

[GH-ISSUE #1170] [Bug]: P2S - every print falls back to "no 3MF available"; FTPS returns 550 for all 3MF probe paths #846

Component

Bug Description

Expected Behavior

Steps to Reproduce

Printer Model

Bambuddy Version

SpoolBuddy Version

Printer Firmware Version

Installation Method

Operating System

Relevant Logs / Support Package

Screenshots

Additional Context

Checklist