CapCut stalls when unable to locate network services
Using shared storage with CapCut should behave as predictably as other NLEs (non-linear editor).
You would mount the storage volume using the in-built Samba client for macOS integrated into Finder (Finder > Go > Connect to Server > enter smb:// address).
Then your volume would appear in Finder, and at the filesystem path /Volumes/storage
.
Many NAS OSs (QNAP, Synology, TrueNAS and the like) will offer service discovery using mDNS & DNS-SD, as Bonjour or Avahi.
So Mac clients can see the NAS system as an option in Finder > Networks without specifying an address.
Clicking on that NAS service name, authenticating, and selecting a volume will produce the same result: a volume is mounted via SMB, appears in Finder, and at the filesystem path /Volumes/storage
.
You can compare the output of smbutil statshares -a
for the same volume mounted in both methods:
user@client-MacBook-Pro ~ % smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
storage
SERVER_NAME 10.#.#.#
[... other fields]
--------------------------------------------------------------------------------------------------
user@client-MacBook-Pro ~ % smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
storage
SERVER_NAME nas-hostname._smb._tcp.local
[... other fields]
--------------------------------------------------------------------------------------------------
CapCut
CapCut for macOS v6.3.0 accepts media stored on shared volumes.
It is reasonably transparent to the user in displaying the full path location for media files.
[Image of CapCut UI file paths]
It also offers a link media option, and uses red & UI text to indicate when clips are offline - i.e. their storage location is unavailable, disconnected, the file is deleted, and so on.
This is great and predictable following the patterns of the other major NLEs.
Project that hangs on open
This week I faced an issue with a colleague with certain CapCut projects that they could not access.
Opening them showed the program to stall indefinitely at the message “Interface is being loaded, please wait a minute” and it never loads.
Meanwhile, the system shows Finder UI dialog message “There was a problem connecting to the server ’nas-hostname’.”
This is odd since the server nas-hostname
is perfectly accessible at the usual location /Volumes/storage.
All of the footage remains in the same place at /Volumes/storage with no folder renames or the like.
There are other CapCut projects in the user’s library that could open and used similar footage files that the offending projects used as well.
Why do these select CapCut projects stall?
Troubleshooting
Same result after logout, reboot and update of CapCut version via Mac App Store (I didn’t record the previous CapCut version number, though).
The user data directory is located at ~/Movies/CapCut/User Data
and projects under com.lvedditor.draft
.
➜ tree -d -L2 ~/Movies/CapCut/User Data
.
├── Cache
├── CEF
├── Cloud files
├── Config
├── Crash
├── Download
├── EMaterial
├── Feedback
├── Log
├── Lynx
├── Migration
├── MMKV
├── ParfaitServer
├── Presets
├── Projects
│ ├── com.lveditor.draft
│ └── com.lveditor.textTemplate.draft
├── Resources
├── SettingsSDK
├── Tracking
├── TTNet
├── VELog
└── VideoRecord
Each CapCut project is a separate directory. The directory name mostly is the name of the project within CapCut but I have a feeling there is an embedded title somewhere.
I thought to rename User Data
to User Data.bak
and relaunch CapCut, allow it to regen.
CapCut launches fine and with an empty projects list.
I add in one of the projects from User Data.bak
to the expected location.
The project is visible in CapCut and opens fine, there was no delay in passing “Interface is being loaded, please wait a minute” message and I see the timeline and its contents fine.
I thought perhaps I had selected a non-offending project reported by my colleague.
I choose another project to copy into User Data
and this time, the issue is reproduced - “Interface is being loaded, please wait a minute” message and Finder UI dialog message “There was a problem connecting to the server ’nas-hostname’.”
It’s a bit stumping why certain projects would stall AND have some association with the failed server connection message.
What part of a CapCut project would maintain references to nas-hostname
even though the underlying storage was mounted through an explicit IP address?
Local environment
A few weeks ago in anticipation of some structural and network changes in our environment, I decided to switch off Bonjour/mDNS on the NAS system.
The storage is provided by a QNAP QTS 5 system, and it’s simple as the option in QTS 5 Web UI > Settings > Service Discovery > Bonjour/mDNS and Enable/Disable.
This was motivated by my push to have our team members connect using the Connect to Server method.
Even though both explicit-Connect to Server (IP address/DNS hostname) and Bonjour achieve the same result, the latter has other expected structure in place in order to facilitate the connection.
mDNS/DNS-SD traffic needs to pass through from server <-> clients unhindered at all segments of the network.
On the client side, there is no configuration required, since macOS clients all generally behave quite well with Bonjour.
Windows clients also but I won’t pretend it’s a magic protocol that is perfectly implemented.
There is no ‘refresh’, and no real good sense if you are getting a list of all connectable servers at any one time, since often ghost or decayed services will persist in the list and give vague error messages like “Can’t connect”.
On macOS there is no easy UI-based way to take a Bonjour service and get the IP address or DNS hostname, which would be needed during a connectivity issue, in order to do next round of basic troubleshooting (ping).
There is also a real risk of other fictious services broadcasting themselves as familiar names to our team members, since the WAN source in this environment is a shared one outside of our control.
(Read: all sorts of printers and other people’s Macs pop up in the Network tab when you connect.)
So the best option in my mind that balances convenience (time/steps to connect) with security (trusted server) and reliability (less layers) is the explicit-Connect to Server method.
And given that at the filesystem level, the end result is still /Volumes/storage
, there really should be no impacts on general usage.
Until CapCut it seems.
mDNS hostname
The Finder UI dialog message “There was a problem connecting to the server ’nas-hostname’.” was a bit revealing.
At this point in time, the volumes were available at smb://10.#.#.#, i.e. not a hostname being used.
So I thought it was odd for the UI message to indicate it failed to connect to nas-hostname
, but an actual working connection existed from smb://10.#.#.#.
Since the message showed up several times over 3-5 minutes of CapCut stalling even after I dismissed it, it suggested it is trying to connect.
A tcpdump of all interfaces revealed mDNS requests for nas-hostname._smb._tcp.local
were being made:
172.19.40.245.mdns > mdns.mcast.net.mdns: 0 [2q] SRV (QM)? nas-hostname._smb._tcp.local. TXT (QM)? nas-hostname._smb._tcp.local. (51)
19:59:44.402411 IP6 (flowlabel 0x60e00, hlim 255, next-header UDP (17) payload length: 59) client-macbook-pro.local.mdns > ff02::fb.mdns: [udp sum ok] 0 [2q] SRV (QM)? nas-hostname._smb._tcp.local. TXT (QM)? nas-hostname._smb._tcp.local. (51)
19:59:45.056312 IP (tos 0x0, ttl 255, id 11719, offset 0, flags [none], proto UDP (17), length 416)
172.19.40.79.mdns > mdns.mcast.net.mdns: 0*- [0q] 2/0/6 UTS049910._device-info._tcp.local. TXT "model=Mac15,8" "osxvers=24" "icolor=9", _companion-link._tcp.local. PTR UTS049910._companion-link._tcp.local. (388)
19:59:45.875629 IP (tos 0x0, ttl 255, id 15964, offset 0, flags [none], proto UDP (17), length 449)
172.19.47.240.mdns > mdns.mcast.net.mdns: 0 [9a] [3q] PTR (QM)? _airplay-bds._tcp.local. PTR (QM)? _airplay._tcp.local. PTR (QM)? _raop._tcp.local. (421)
19:59:45.910285 IP (tos 0x0, ttl 255, id 39713, offset 0, flags [none], proto UDP (17), length 985)
But there was no returning response from the NAS.
Because I had disabled Bonjour a few weeks ago.
user@client-MacBook-Pro ~ % dns-sd -B _smb._tcp local
Browsing for _smb._tcp.local
DATE: ---Wed 11 Jun 2025---
19:58:58.401 ...STARTING...
Timestamp A/R Flags if Domain Service Type Instance Name
19:58:58.402 Add 3 9 local. _smb._tcp. other-mac
19:58:58.402 Add 3 9 local. _smb._tcp. other-mac2
19:58:58.402 Add 2 15 local. _smb._tcp. MacBook Air (5)
# nas-hostname suspiciously missing!
So back on it goes.
I redo dns-sd -B _smb._tcp local
and nas-hostname
is eventually visible.
Open an offending CapCut project, “Interface is being loaded, please wait a minute” message for a few minutes, but no accompanying Finder UI message indicating cannot connect to a server.
Eventually the project did open and the media was online.
Issue ‘resolved’.
I suspect that at the time the offending projects were created, the NAS was mounted via Bonjour and the project’s media and edits etc were composed using media on /Volumes/storage
coming from Bonjour.
During that time, I did not witness two /Volumes/storage
appear in Finder, as sometimes they do when you mount the same underlying service under more than one IP address: /Volumes/storage
and /Volumes/storage-1
.
But nas-hostname
(eject icon) did appear in the Finder sidebar and clicking on it revealed storage
and the directory contents immediately, without any authentication or visible ‘connect’ taking place.
So perhaps at that point in time, they were also mounted under the filesystem but not at a /Volumes/ path or at a way that caused them to appear in Finder.
CapCut project references
What inside the CapCut project is facilitating?
The User Data
directory was freshly regenerated and there were no connections to Bonjour made between regen & now.
So ergo Bonjour references should (if they do) exist in the project directory under Projects
.
The structure of a project is:
16:51:58 in Projects/com.lveditor.draft/censored_project_name_00_v2_250502
➜ tree
.
├── adjust_mask
├── attachment_editing.json
├── attachment_pc_common.json
├── common_attachment
│ ├── aigc_aigc_generate.json
│ ├── attachment_plugin_draft.json
│ ├── attachment_script_video.json
│ └── coperate_create.json
├── crypto_key_store.dat
├── crypto_key_store.dat.bak
├── draft_agency_config.json
├── draft_biz_config.json
├── draft_cover.jpg
├── draft_info.json
├── draft_info.json.bak
├── draft_meta_info.json
├── draft_settings
├── draft_virtual_store.json
├── draft.extra
├── key_value.json
├── materials
│ ├── audio
│ │ └── 12_full_spread-your-wings_0143.wav
│ └── video
│ ├── 8a143f51f70f827ffcdae2a4944a4bbc.mp4
│ ├── IMG_8081-Synced.mp4
│ ├── Censored Interview 01_v1_250411.mp4
│ ├── Censored Interview 02_v1_250411.mp4
│ └── [many more files]
├── matting
├── performance_opt_info.json
├── qr_upload
├── Resources
│ ├── audioAlg
│ ├── cover
│ ├── digitalHuman
│ │ ├── audio
│ │ ├── bsinfo
│ │ └── video
│ └── videoAlg
├── smart_crop
├── subdraft
│ ├── 578CA887-4D02-4BAE-AD94-53921B188524
│ │ ├── attachment_editing.json
│ │ ├── attachment_pc_common.json
│ │ ├── common_attachment
│ │ │ ├── aigc_aigc_generate.json
│ │ │ ├── attachment_plugin_draft.json
│ │ │ └── attachment_script_video.json
│ │ ├── crypto_key_store.dat
│ │ ├── crypto_key_store.dat.bak
│ │ ├── draft_agency_config.json
│ │ ├── draft_biz_config.json
│ │ ├── draft_content.json
│ │ ├── draft_cover.jpg
│ │ ├── draft_info.json
│ │ ├── draft_info.json.bak
│ │ ├── draft_meta_info.json
│ │ ├── draft_settings
│ │ ├── draft_virtual_store.json
│ │ ├── draft.extra
│ │ ├── key_value.json
│ │ ├── loudness
│ │ │ ├── ...[many more files]
│ │ ├── Resources
│ │ │ └── audioAlg
│ │ │ ├── 039c8be26750a24290413987030f6049_60333333_9933333_download.wav
│ │ │ ├──...[many more files]
│ │ │ └── fb0879317f6f0d63fd75912c4b47a97d_120333334_6199999.wav
│ │ ├── sub_draft_config.json
│ │ ├── subdraft
│ │ │ ├── 6BE5AB4E-6BB2-4E1B-AC69-ED85EA8B2E50
│ │ │ │ ├── draft_content.json
│ │ │ │ ├── draft_cover.jpg
│ │ │ │ └── sub_draft_config.json
│ │ │ └── 9F24475C-B10B-4FAB-B593-868F109CC3B7
│ │ │ ├── draft_content.json
│ │ │ ├── draft_cover.jpg
│ │ │ └── sub_draft_config.json
│ │ ├── template-2.tmp
│ │ └── template.tmp
│ └── 844C5EA3-95E5-450D-BAFF-0B25D5736863
│ ├── attachment_editing.json
│ ├── attachment_pc_common.json
│ ├── common_attachment
│ │ ├── aigc_aigc_generate.json
│ │ ├── attachment_plugin_draft.json
│ │ └── attachment_script_video.json
│ ├── crypto_key_store.dat
│ ├── crypto_key_store.dat.bak
│ ├── draft_agency_config.json
│ ├── draft_biz_config.json
│ ├── draft_content.json
│ ├── draft_cover.jpg
│ ├── draft_info.json
│ ├── draft_info.json.bak
│ ├── draft_meta_info.json
│ ├── draft_settings
│ ├── draft_virtual_store.json
│ ├── draft.extra
│ ├── key_value.json
│ ├── loudness
│ │ ├── 036d1df0b5fc377348cb9b9b7b37a99f
│ │ ├── ...[many more files]
│ │ └── fde3355d8ce7394cdf7ba732922c8cd2
│ ├── Resources
│ │ └── audioAlg
│ │ ├── ...[many more files]
│ ├── sub_draft_config.json
│ ├── subdraft
│ │ ├── 54B876E4-CDB0-4AD9-ACF4-B3F2D05CF57A
│ │ │ ├── draft_content.json
│ │ │ ├── draft_cover.jpg
│ │ │ └── sub_draft_config.json
│ │ ├── 6BE5AB4E-66B2-4E1B-AC69-ED85EADB2E50
│ │ │ ├── draft_content.json
│ │ │ ├── draft_cover.jpg
│ │ │ └── sub_draft_config.json
│ │ ├── 8B49FFF9-FF66-46D9-962C-6FCE6105D823
│ │ │ ├── draft_content.json
│ │ │ ├── draft_cover.jpg
│ │ │ └── sub_draft_config.json
│ │ └── 9F24445C-B16B-4FAB-B593-869F109CC3B7
│ │ ├── draft_content.json
│ │ ├── draft_cover.jpg
│ │ └── sub_draft_config.json
│ ├── template-2.tmp
│ └── template.tmp
├── template-2.tmp
├── template.json.bak
└── template.tmp
36 directories, 461 files
There is plaintext JSON content, base64 encoded JSON, binary data in .dat
files and some thumbnail images.
A text search in the directory revealed thousands of /Volumes/storage/folder/path/video.mp4
references.
# massive JSON:
..."audios":[{"ai_music_generate_scene":0,"ai_music_type":0,"aigc_history_id":"","aigc_item_id":"","app_id":0,"category_id":"","category_name":"","check_flag":1,[...]"music_id":"","music_source":"","name":"12_full_spread-your-wings_0143.wav","path":"/Volumes/storage/AGENCY/01_ASSETS/MUSIC/_CORPORATE - FAST - CINEMATIC/Joyful/12_full_spread-your-wings_0143.wav","pgc_id":"",[...]}]...
But no mentions of nas-hostname
.
A binary search revealed no mentions of nas-hostname
in the project directory.
A base64 decode -> strings search revealed no mentions of nas-hostname
.
% ggrep -a -r --binary-files=text 'nas-hostname' .
%
% find . -type f | while read f; do
base64 -d "$f" 2>/dev/null | strings | grep -q 'nas-hostname' && echo "$f"
done
%
Cloud integration
CapCut macOS app has cloud integration of some kind.
Projects can be “synced” and assumedly maintained across other devices running CapCut.
In relation to examining project files, this is a big area of exploration.
Since it is very possible that project data that I have no access to, can’t be evaluated by me in any kind of easy way, to say conclusively if such data plays any part in this.
Vague operations of a black box service.
Their program has no presence in ~/Library/Application Support/
and no readable logs or logging to Console.app.
There are some logs at ~/Movies/CapCut/User Data/Log/
but they are not readable.
16:47:41 in ~/Downloads/User Data
➜ tree Log/alog/log
Log/alog/log
├── 2025_05_16_1747380321904__CapCut__default.alog.hot
├── 2025_05_29_1748493463998__CapCut__default.alog.hot
...
1 directory, 30 files
16:48:07 in ~/Downloads/User Data
➜ file Log/alog/log/2025_05_16_1747380321904__CapCut__default.alog.hot
Log/alog/log/2025_05_16_1747380321904__CapCut__default.alog.hot: data
Developer support
I wrote an email to ByteDance support.
I will do an update with their response, if there is one.
The expected behaviour is simply:
- a project that contains references to Bonjour services should not stall at opening; and
- if Bonjour services are required in some way, an error message should be displayed to the user to indicate this, and allow the user to pass and still interact with the rest of the project and UI
or
- a project should not maintain strict references to Bonjour services and should only contain references to the filesystem volume mounted from that service.