# \[3.9.0+\] Initial Server Setup Fail/Deadlock - Assumed Frontend Bug

**URL:** <https://community.cloudogu.com/t/3-9-0-initial-server-setup-fail-deadlock-assumed-frontend-bug/1546>\
**Category:** SCM-Manager Bug Reports\
**Created:** [December 3, 2025, 11:50pm UTC](https://community.cloudogu.com/t/3-9-0-initial-server-setup-fail-deadlock-assumed-frontend-bug/1546 "2025-12-03T23:50:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ti.diegeler](https://dub1.discourse-cdn.com/flex013/user_avatar/community.cloudogu.com/ti.diegeler/32/1739_2.png) [@ti.diegeler](https://community.cloudogu.com/u/ti.diegeler)\
**Post date:** [December 3, 2025, 11:50pm UTC](https://community.cloudogu.com/t/3-9-0-initial-server-setup-fail-deadlock-assumed-frontend-bug/1546/1 "2025-12-03T23:50:55Z")

</div>

Hello, I’ve found what I think is a bug on SCM-Manager’s side:

- Bug description (occurred issue):

- Expected result / system behavior (from 3.8.0 frontend):

- observed result / system behavior (from 3.11.1 frontend):

- SCM-Manager version and installed package:

The SCM-Manager instance runs on a Ubuntu Live server with Docker installed. The Ufw firewall has been disabled in systemctl to avoid port restrictions, and communication between the server and client is within a private network (same router).

If there is anything else you need as an info, I can try to provide it for you.

Thanks!

Till

---

<div class="post-metadata">

**Author:** ![pfeuffer](https://dub1.discourse-cdn.com/flex013/user_avatar/community.cloudogu.com/pfeuffer/32/72_2.png) [@pfeuffer](https://community.cloudogu.com/u/pfeuffer)\
**Post date:** [December 5, 2025, 9:38am UTC](https://community.cloudogu.com/t/3-9-0-initial-server-setup-fail-deadlock-assumed-frontend-bug/1546/2 "2025-12-05T09:38:48Z")

</div>

Hey Till,

nice to hear from you! Just to make this clear to me:

After starting the 3.11.1 and opening http://…/scm/, you did **not** see this “Finish Initialization” screen but directly got to the page with the error?

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/cloudogu2/original/2X/4/4792cc93e969935b033c313ed5dfa04ca7cb9be0.png)

And the folder `/home/user/scm_home` has did not exist (or has been empty) before you start the server?

I’ve gone through this process three times now with little tweaks (running as root or as normal user, using a double `/` like in your pasted command 😉), but I always “got through”.

Are there things I might miss from your description?

Keep on coding!  
René

---

<div class="post-metadata">

**Author:** ![ti.diegeler](https://dub1.discourse-cdn.com/flex013/user_avatar/community.cloudogu.com/ti.diegeler/32/1739_2.png) [@ti.diegeler](https://community.cloudogu.com/u/ti.diegeler)\
**Post date:** [December 5, 2025, 11:33am UTC](https://community.cloudogu.com/t/3-9-0-initial-server-setup-fail-deadlock-assumed-frontend-bug/1546/3 "2025-12-05T11:33:48Z")

</div>

Hey René, thanks!

Yes, I did the “Finish Initialization” screen. I also saw the configuration selection.

However, when I picked one, the process failed and it got stuck in a loop.

I attached a **.zip** with a video:

[Aufzeichnung 2025-12-05 112742.zip](https://community.cloudogu.com/uploads/short-url/nXM7FTB5pHjU1BbUIEmPxy4SOaB.zip) (6.2 MB)

And these are the **commands** I executed beforehand:

 ![grafik](https://europe1.discourse-cdn.com/flex013/uploads/cloudogu2/original/2X/f/ff70f6e3e19aac772e9f61d7fd3d95b179f6b213.png)

For reproduction, it is important to open a **new tab** with the /scm link. Using one from a previous session may actually make the authorization work. I’ve encountered this myself now.

The folder /scm\_home did not exist before when the error emerged.

Wish you a nice weekend,

Till

---

<div class="post-metadata">

**Author:** ![fscholdei](https://dub1.discourse-cdn.com/flex013/user_avatar/community.cloudogu.com/fscholdei/32/15_2.png) [@fscholdei](https://community.cloudogu.com/u/fscholdei)\
**Post date:** [January 14, 2026, 9:19am UTC](https://community.cloudogu.com/t/3-9-0-initial-server-setup-fail-deadlock-assumed-frontend-bug/1546/4 "2026-01-14T09:19:42Z")

</div>

Hello Till, Happy New Year!

While we haven’t been able to reproduce the issue on our end yet, we are very interested in identifying the cause and finding a fix.

To help us investigate further, would you be available for a short remote session to walk us through the steps you’re seeing?  
If so, please let us know your availability and we’ll get a meeting invite sent over.

Best regards  
Florian