Skip to main content

Transfer Tool - No accounts listed when connecting to Plesk 18.0.76 (Analyze succeeds)

sicay

Hi everyone,

I'm running into a very strange issue with the WHM Transfer Tool when migrating from a Plesk server.

Environment

Destination

  • cPanel & WHM (latest RELEASE tier)
  • AlmaLinux 9

Source

  • Plesk Obsidian 18.0.76
  • CentOS 7

SSH connectivity works correctly and the Transfer Tool successfully authenticates to the remote server.

The problem

The remote analysis completes successfully, but no accounts are listed in the Transfer Tool.

The API also reports success:

whmapi1 analyze_transfer_session_remote \
    transfer_session_id=<session_id>

metadata:
  reason: OK
  result: 1

However, the account list is empty.

What I've already verified

The transfer session database contains:

  • remote/type = plesk
  • remote/version = 18.0.76
  • remote_data/hostname contains the correct hostname.
  • remote_data/dump_databases_and_users contains valid JSON with all Plesk subscriptions, databases and owners.
  • remote_data/analyze_config exists (although only the pkgacct-target values are populated, which appears normal for Plesk).

The JSON returned by dump_databases_and_users-plesk validates correctly:

sqlite3 db.sqlite "...dump_databases_and_users..." | python3 -m json.tool
OK

Additional observations

During analysis I also noticed:

remote_data/scripts_dir_ensure = 0
remote_data/Cpanel_dir_ensure = 0
remote_data/non_native_updatedomains_update = 0

I'm not sure whether these values simply indicate successful execution with no output, or whether they suggest that the helper scripts were never uploaded or executed.

The remote server also has:

/etc/trueuserdomains

present but empty, while /etc/userdomains does not exist.

Since this is a Plesk server, I assume the Transfer Tool should not rely on these files and should instead use the output from dump_databases_and_users-plesk.

Source code investigation

After tracing through the cPanel code, I found:

  • Analyze.pm correctly queues dump_databases_and_users-plesk.
  • The JSON is successfully stored in the transfer session database.
  • Results.pm reads this JSON successfully.

What I have not yet found is where the Transfer Tool converts that JSON into the list of accounts displayed in the UI.

It almost looks like the JSON is generated correctly but is ignored later in the analysis.

Question

Has anyone experienced this recently with Plesk 18.0.76?

Is there a known regression in recent cPanel versions that prevents Plesk accounts from appearing after a successful analysis?

I've already opened a support ticket through my provider (OVH), but I wanted to ask here in case someone has seen the same behaviour or can point me to the next piece of code responsible for building the account list.

Thanks!

Comments

15 comments

Date Votes
  • cPRex Jurassic Moderator

    Hey there!  I'm not aware of any known issues around this area of the Transfer Tool.  My best guess would be something related to the Plesk database or the way cPanel is accessing it, but there isn't much I can offer for this one without seeing that ticket.

    If OVH doesn't have any ideas have them escalate the issue to us and we'll get it handled.

    0
  • sicay

    Hi,

    I will tell OVH that. But if you look into the infos I gave you, the problem started after the update in the night of Sunday to Monday. Did anything got changed in this update?

    0
  • sicay

    Also, I have 4 servers running WHM 136.0.25, and they all have the same problem.

    0
  • cPRex Jurassic Moderator

    I'm not aware of any changes to the Transfer Tool for some time, so I wouldn't expect recent updates to have an issue.

    0
  • Martin MZ

    I'm having the same problem

     

     

    [root@server~]# whmapi1 create_remote_root_transfer_session \ host=66.228.XX.XX \ port=22 \ user=root \ authtype=password \ password='XXX' --- data: analyze_rawout: "Fetching information from remote host: “66.228.XX.XX” … …\nDone\nUsing local pkgacct code at: “/usr/local/cpanel/Whostmgr/Pkgacct/updateuserdomains-universal”.\nCopying “/usr/local/cpanel/Whostmgr/Pkgacct/updateuserdomains-universal” to “/scripts/updateuserdomains-universal” … …\nProcessed 129,763 bytes.\nDone\nUsing local pkgacct code at: “/usr/local/cpanel/Whostmgr/Pkgacct/packages-pXa”.\nCopying “/usr/local/cpanel/Whostmgr/Pkgacct/packages-pXa” to “/scripts/packages” … …\nProcessed 65,278 bytes.\nDone\nUsing local pkgacct code at: “/usr/local/cpanel/Whostmgr/Pkgacct/pkgacct-pXa”.\nCopying “/usr/local/cpanel/Whostmgr/Pkgacct/pkgacct-pXa” to “/scripts/pkgacct.server” … …\nProcessed 299,994 bytes.\nDone\nFetching information from remote host: “66.228.XX.XX” … …\nDone\n" create_rawout: "Basic credential check … …\nDone\nFetching information from remote host: “66.228.XX.XX” … …\nDone\nRemote Server Type: plesk\n" transfer_session_id: 6622850147copya20260701184944rwhrIuZ metadata: command: create_remote_root_transfer_session output: warnings: - Use of uninitialized value in split at /usr/local/cpanel/Whostmgr/Transfers/Session/Preflight/RemoteRoot/Analyze.pm line 301. reason: OK result: 1 version: 1



    [root@server~]# [root@server~]# whmapi1 analyze_transfer_session_remote transfer_session_id=6622850147copya20260701184944rwhrIuZ [2026-07-01 15:51:09 -0300] warn [Internal Warning while parsing [stdin] 829810] Use of uninitialized value in split at /usr/local/cpanel/Whostmgr/Transfers/Session/Preflight/RemoteRoot/Analyze.pm line 301. at /usr/local/cpanel/Whostmgr/Transfers/Session/Preflight/RemoteRoot/Analyze.pm line 301. Whostmgr::Transfers::Session::Preflight::RemoteRoot::Analyze::_determine_remote_mysql_configuration(Whostmgr::Transfers::Session::Preflight::RemoteRoot::Analyze=HASH(0x3744600)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Preflight/RemoteRoot/Analyze.pm line 133 Whostmgr::Transfers::Session::Preflight::RemoteRoot::Analyze::_analyze_remote("Whostmgr::Transfers::Session::Preflight::RemoteRoot::Analyze", HASH(0x35c0e68)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Preflight/RemoteRoot/Analyze.pm line 66 Whostmgr::Transfers::Session::Preflight::RemoteRoot::Analyze::__ANON__() called at /usr/local/cpanel/Cpanel/Capture.pm line 36 Cpanel::Capture::__ANON__() called at /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/Try/Tiny.pm line 100 eval {...} called at /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/Try/Tiny.pm line 91 Try::Tiny::try(CODE(0x3753098), Try::Tiny::Catch=REF(0x35df760)) called at /usr/local/cpanel/Cpanel/Capture.pm line 40 Cpanel::Capture::trap_stdout(CODE(0x35c1b70)) called at /usr/local/cpanel/Whostmgr/Transfers/Session/Preflight/RemoteRoot/Analyze.pm line 68 Whostmgr::Transfers::Session::Preflight::RemoteRoot::Analyze::analyze_remote(HASH(0x35c0e68)) called at /usr/local/cpanel/Whostmgr/API/1/Transfers.pm line 153 Whostmgr::API::1::Transfers::analyze_transfer_session_remote(HASH(0x2904990), Whostmgr::API::1::Utils::Metadata=HASH(0x290b2c0), HASH(0x35d5f48)) called at whostmgr/bin/xml-api.pl line 1091 whostmgr::bin::xml_api::__ANON__(Whostmgr::API::1::Utils::Metadata=HASH(0x290b2c0), HASH(0x2904990), HASH(0x35d5f48), CODE(0x35d5c60)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 242 Whostmgr::API::1::Data::Wrapper::__ANON__() called at /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/Try/Tiny.pm line 100 eval {...} called at /usr/local/cpanel/3rdparty/perl/542/cpanel-lib/Try/Tiny.pm line 91 Try::Tiny::try(CODE(0x35d8eb0), Try::Tiny::Catch=REF(0x35dfdc0)) called at /usr/local/cpanel/Whostmgr/API/1/Data/Wrapper.pm line 272 Whostmgr::API::1::Data::Wrapper::execute_internal(CODE(0x35d62d8), HASH(0x2904990), HASH(0x35d5f48), HASH(0x35d6278), CODE(0x35d5c60)) called at whostmgr/bin/xml-api.pl line 1268 whostmgr::bin::xml_api::runapp(undef, "analyze_transfer_session_remote", HASH(0x35d5f48), HASH(0x2771898), 0, CODE(0x35d5c60)) called at whostmgr/bin/xml-api.pl line 910 whostmgr::bin::xml_api::script(CODE(0x35d5c60), "-json", "analyze_transfer_session_remote") called at whostmgr/bin/xml-api.pl line 851 --- metadata: command: analyze_transfer_session_remote reason: OK result: 1 version: 1

     

     

    Use of uninitialized value in split at Analyze.pm line 301
    ↳ función: _determine_remote_mysql_configuration
    0
  • cPRex Jurassic Moderator

    Is it possible that the Plesk system is using MariaDB 11.4?

    0
  • sicay

    Not on the Plesk servers I'm transfering from :

    mysql    10.5.26-1.el7.centos

    The data of the Plesk accounts are transfered on the cPanel server. They seems to be not processed as previously.

    0
  • sicay

    Now, with 136.0.26, transfer with both Plesk and cPanel servers gives a blank page. Only the link in the header appears. And there is Javascript errors :

    Uncaught TypeError: can't access property "length", PAGE.EABlockers is undefined
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.cmb.min.js?locale=en&locale_revision=1782955466:50
        notify https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        subscribe https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        onDOMReady https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.cmb.min.js?locale=en&locale_revision=1782955466:50
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.cmb.min.js?locale=en&locale_revision=1782955466:50
    getacctlist.cmb.min.js:50:37822
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.cmb.min.js?locale=en&locale_revision=1782955466:50
        notify https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        subscribe https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        onDOMReady https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.cmb.min.js?locale=en&locale_revision=1782955466:50
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.cmb.min.js?locale=en&locale_revision=1782955466:50
    Uncaught TypeError: can't access property "length", PAGE.EABlockers is undefined
        init https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.min.js?locale_optional=1&locale=en&locale_revision=1782955466:31
        notify https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        subscribe https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        onDOMReady https://io.aztus.net:2087/cPanel_magic_revision_1781298315/yui-gen/utilities_container/utilities_container.js:13
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.min.js?locale_optional=1&locale=en&locale_revision=1782955466:31
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.min.js?locale_optional=1&locale=en&locale_revision=1782955466:31
    getacctlist.min.js:31:1757
    Uncaught TypeError: APP is not a function
        <anonymous> https://io.aztus.net:2087/cPanel_magic_revision_1782955139/templates/transfer_tool/getacctlist.dist.min.js?locale_optional=1&locale=en&locale_revision=1782955466:1
        execCb https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        check https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        enable https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        bind https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        emit https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        each https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        emit https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        check https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        enable https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        init https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        a https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        completeLoad https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
        onScriptLoad https://io.aztus.net:2087/cPanel_magic_revision_1755024884/libraries/requirejs/optimized/require.min.js:5
    getacctlist.dist.min.js:1:144

    0
  • sicay

    After some additional debugging, I have a few more findings that may help narrow this down.

    Additional findings

    The remote analysis completes successfully:

    whmapi1 analyze_transfer_session_remote transfer_session_id=<session>

metadata:
  result: 1
  reason: OK

    The transfer session SQLite database is created correctly and contains valid data.

    In particular:

    • dump_databases_and_users contains valid JSON.

    • The JSON validates successfully (python3 -m json.tool).

    • Database owners are correctly detected.

    Example:

    {
  "users": {
    "MYSQL": {
      "ckrl_ckrlqcca": {
        "owner": "ckrl"
      }
    }
  }
}

    So dump_databases_and_users-plesk appears to be working correctly.

    However, the following values remain empty in the transfer session:

    remote_data:
/etc/trueuserdomains
/etc/userdomains

    On the Plesk source server:

    • /etc/trueuserdomains exists but is an empty file.

    • /etc/userdomains does not exist.

    This is expected on Plesk, but it looks like the Transfer Tool may still expect those mappings later when building the account list.

    I also noticed that non_native_updatedomains_update is stored as 0 in the session database, suggesting that no account mapping is generated after the analysis.

    At this point it seems that:

    • Remote analysis succeeds.

    • dump_databases_and_users succeeds.

    • Database owners are discovered correctly.

    • The failure occurs later when the Transfer Tool builds the list of transferable accounts.

    Additional issue after upgrading to 136.0.26

    While continuing my investigation, I also discovered what appears to be a separate regression.

    After upgrading to 136.0.26, the Transfer Tool between two cPanel servers now produces a blank page after the analysis.

    The transfer session itself completes successfully, but the browser console reports:

    TypeError: PAGE.EABlockers is undefined

    followed by

    TypeError: APP is not a function

    The transfer session SQLite database contains no page section or PAGE.EABlockers data, so it appears the frontend is expecting data that is never generated.

    I'm not sure whether these two issues are related, but both appeared while testing 136.0.26.

    I already have an official support ticket open through my provider, but I wanted to share these findings here in case they help identify the regression or if anyone else is seeing the same behaviour.

    0
  • cPRex Jurassic Moderator

    Update - our team has been able to replicate this issue and we're working on this through case CPANEL-54330.  I don't have a workaround available at this time but I've linked this thread to the case so I'll be sure to post an update once I have one.

    0
  • sicay

    Good news! Can they check also for the issue of the accounts not showing for a Plesk server? I can provide an access to my server for the cPanel team so that they can investigate.

    0
  • cPRex Jurassic Moderator

    Yes - the issue is specifically about the Plesk server connection.

    We wouldn't be able to access your system(s) outside of a ticket, but I think we have the data we need at this point.

    0
  • sicay

    The Transfer Tool is working again! Thanks a lot!

    0
  • cPRex Jurassic Moderator

    Glad to hear it!

    0
  • cPRex Jurassic Moderator

    Update - this issue is scheduled to be resolved in the next release, 136.0.28.

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post