proc_open disabled on shared hosting, move/copy via worker fails with 500, no fallback available

[Giermann]

Describe the bug
Moving or copying folders fails on shared hosting environments where proc_open(), shell_exec(), popen(), passthru() and system() are disabled via disable_functions in php.ini. The UI shows "Waiting for worker..." indefinitely, then returns "Failed to start transfer job (error 500)". No fallback for synchronous execution exists.

To Reproduce

1. Install FileRise on shared hosting with proc_open and related functions disabled (common on managed/shared hosts)
2. Log in as admin
3. Right-click any folder → Move (or Copy)
4. Select a target folder and confirm
5. UI shows "Waiting for worker..." for a long time, then: "Failed to start transfer job (error 500)"

Expected behavior
Move and copy operations should either fall back to synchronous in-process execution when proc_open() is unavailable, or provide a configuration constant (e.g. FR_WORKER_MODE=sync) to opt into synchronous execution — so that the operation completes successfully without requiring a background worker process.

Additional context

• FileRise version: 3.11.0
• Install type: Manual (no Docker, no SSH)
• PHP version: 8.x (shared hosting)
• Disabled functions (relevant): proc_open, shell_exec, popen, passthru, system
• Available: exec() is available
• open_basedir is set to restrict access outside the webspace
• Moving or copying both files and folders triggers the worker and fails — no move or copy operation works at all.
• A config-level opt-in like define('FR_WORKER_MODE', 'sync') or an automatic fallback when proc_open is not callable would solve this for shared hosting users

Shared hosting is a common deployment scenario for small teams and the lack of a fallback makes folder operations completely unusable in this environment.

Root cause identified: spawnZipWorker() and TransferJobManager::spawnWorker() use shell_exec() to spawn the background process (even though exec() is available and used for PHP binary detection). Since shell_exec is disabled via disable_functions on shared hosting, the worker spawn always fails. A fallback to exec() for the spawn call, or a synchronous execution path when no shell function can start a background process, would fix this.

[error311]

Thanks for the detailed report. I confirmed the issue and have fixed it in FileRise v3.11.1.

The root cause was that the transfer / ZIP worker launch path assumed shell_exec()-based background spawning, with no usable fallback when that function was disabled by the host. On restrictive shared-hosting setups, that caused move/copy operations to stall and then fail with the 500 you described.

The v3.11.1 changes include:

• a shared worker-launch helper that falls back from shell_exec() to exec() where possible
• a new FR_WORKER_MODE setting with auto (default), async, and sync
• foreground fallback for transfer and ZIP jobs when background worker spawning is unavailable and fallback is allowed
• clearer degradation for other shell-dependent paths such as ClamAV diagnostics and archive operations when command execution is restricted

So on hosts like the one you described:

• auto will prefer background workers when available, but fall back more gracefully when they are not
• sync can be used to force foreground execution on hosts where that is the better fit
• async keeps strict background-worker behavior for operators who want that mode explicitly

I also validated the fix on a live test instance using a shared-hosting-style setup where shell_exec was disabled while exec remained available. File copy, folder copy, and ZIP creation all completed successfully after the change.

One note: on very restrictive hosts, large foreground operations can still be limited by normal PHP / web-server request timeouts. But the v3.11.1 fix resolves the specific worker-start failure path that was making move/copy unusable.

Thanks again for reporting it clearly.

[Giermann]

Wow - a really quick response and fix!!

Unfortunately I cannot confirm, that it works now.
I tried it without modifying my config.php and it still failed. Then I realized a lot of new functions in config.php (will comment this in another Issue later), adopted them to my copy and even set FR_WORKER_MODE to "sync", but it still queues the job with "Waiting for worker" and aborts after 60s. I tried a simple single file MOVE operation.

[error311]

Thanks for testing v3.11.1 and for reporting back.

I’m reopening this, because while v3.11.1 did fix the worker-start failure in the restrictive-host case I verified locally, your follow-up shows the issue is not fully resolved for all shared-host/manual-host environments yet.

What v3.11.1 fixed:

• fallback from shell_exec() to exec() where possible
• foreground worker fallback via FR_WORKER_MODE=sync
• clearer degradation for related shell-dependent paths

What I verified on a live test instance:

• Apache/PHP with proc_open,shell_exec,popen,passthru,system disabled
• auto mode: file move succeeded
• sync mode: file move succeeded
• sync mode: folder move succeeded

So the remaining gap appears narrower than the original report:

• on some hosts, FileRise still cannot complete the transfer even after the v3.11.1 fallback changes
• the most likely remaining cause is that the web runtime cannot invoke the PHP CLI worker path in that environment, even if exec() appears available

If you’re able to provide it, the most useful next detail would be the transfer job JSON created for the failed operation from:

metadata/transfer_jobs/.jobs/<jobId>.json

The key fields are:

• status
• phase
• error
• spawn.method
• spawn.php

That will help pinpoint whether this is:

• a remaining host/runtime restriction,
• a partial deployment / stale OPcache issue,
• or a still-unfixed fallback bug on our side.

So I’m keeping this open, but with narrower scope: v3.11.1 improved compatibility and fixed one verified restrictive-host case, but it is not yet proven to cover every shared-host/manual-host environment.

[Giermann]

Here is the Job.json, file is still present:

{
    "id": "607c3f90b8e87e0eaec77c437d2a42de",
    "status": "queued",
    "createdAt": 1774530932,
    "updatedAt": 1774530932,
    "startedAt": null,
    "endedAt": null,
    "cancelRequested": false,
    "error": null,
    "errors": [],
    "current": null,
    "phase": "queued",
    "pct": 0,
    "filesDone": 0,
    "bytesDone": 0,
    "selectedFiles": 1,
    "selectedBytes": 274812,
    "user": "admin",
    "kind": "file_move",
    "itemType": "file",
    "mode": "move",
    "sourceFolder": "root",
    "destinationFolder": "Logos",
    "sourceId": "",
    "destSourceId": "",
    "crossSource": false,
    "files": [
        "filename.ext"
    ]
}

But I cannot find the mentioned spawn.* fields...

[error311]

Thanks, this is very helpful.

The missing spawn.* block is important. In the current v3.11.1 code, once FileRise reaches either the background worker spawn path or the foreground sync fallback path, the job JSON should contain a spawn section.

So a job that remains:

• status: "queued"
• phase: "queued"
• no spawn
• no error

suggests one of these narrower cases:

• the full v3.11.1 runtime is not actually active yet (partial update or stale OPcache),
• the job file is being created but cannot be updated afterward due to filesystem permissions/ownership,
• or the request is failing before the worker-launch code path is reached.

Could you please check these next points?

1. Confirm these files exist on the server from the same deployed version:

   • src/FileRise/Support/WorkerLauncher.php
   • src/FileRise/Domain/TransferJobManager.php
   • src/FileRise/Http/Controllers/FileController.php
   • src/FileRise/Http/Controllers/FolderController.php

2. Restart PHP/Apache (or PHP-FPM) once to rule out stale OPcache.

3. Check the owner/permissions of:

   • metadata/transfer_jobs/.jobs/
   • metadata/transfer_jobs/.logs/
   • the job file itself

4. Check the PHP / web server error log at the time of the failed move.

5. If possible, send the exact response body from transferJobStart.php for the failed request.

At this point the issue looks narrower than the original shell_exec() report, because the job metadata is not even reaching the point where the current code would record the spawn attempt.

[Giermann]

Again thanks for your quick response and your patience!
I am unable to restart PHP/Apache because it is Shared Hosting. But I executed "opcache_reset();" once which should also do the trick.

I confirmed the 4 files are at the latest version, not only by modification time, but also for existence of "use FileRise\Support\WorkerLauncher;".

Owner of all files and folders is my web server user, permissions are:
.jobs/.logs folders: 700
job file: 600

The server response from transferJobStart.php after 60 seconds is:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 root@localhost to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache Server at my.domain.com Port 443</address>
</body></html>

The error.log shows:

[Fri Mar 27 09:11:28.333791 2026] [fcgid:warn] [pid 1962300:tid 139810622654208] [client 1.2.3.4:16833] mod_fcgid: read data timeout in 60 seconds, referer: https://my.domain.com/index.html
[Fri Mar 27 09:11:28.333814 2026] [core:error] [pid 1962300:tid 139810622654208] [client 1.2.3.4:16833] End of script output before headers: transferJobStart.php, referer: https://my.domain.com/index.html

So it seems to hang at some point, although the job file creation finished.

[error311]

Thanks for the follow-up and for collecting the logs.

The mod_fcgid timeout explains why this is still failing on your host:

• transferJobStart.php is hanging inside the request for 60 seconds
• FastCGI then terminates it with mod_fcgid: read data timeout in 60 seconds
• because the request is killed before completion, the job remains queued and never reaches the later state where spawn.* metadata would be written

So this is no longer just the original shell_exec() problem.

v3.11.1 improved compatibility for one restrictive-host case I was able to verify, but it was a best-effort change for shared hosting, not a guarantee that all restrictive shared-host/manual-host environments would work.

To fully support environments like yours, FileRise would need a larger refactor to add a true in-request transfer execution path instead of relying on the current worker / CLI fallback model. That is a significantly bigger change and is not on the current roadmap.

I’ve updated the README and installation/docs wording to make the deployment stance clearer:

• Docker is the recommended deployment path
• manual installs on a standard PHP web server are supported
• more restrictive shared-hosting environments are best-effort and may not support every feature or background-worker workflow

I’ll leave this open for now as a known compatibility gap that could be revisited later, but I want to set expectations clearly: this is not something I’m planning to implement in the near term, and it may ultimately be closed as not planned.