MacOS arm64 crashes when config set

[Bubba8291]

The arm64 macOS build crashes when you confirm the directory of where the folders will be synced to.

When the app is reopened, the configuration is not persistent.

[BrunoBernardino]

Thanks for reporting this @Bubba8291! This is working fine for me in an M3 Mac. Are there any errors in the logs you can see? Perhaps try opening the app via terminal to see those more easily.

[Bubba8291]

@BrunoBernardino After looking into it, it may be an issue with rclone webdav

2025/05/29 00:35:45 ERROR : Bisync critical error: Not Found: 404 Not Found
2025/05/29 00:35:45 ERROR : Bisync aborted. Must run --resync to recover.

This is in the application output as well as running the rclone command separately. Do you have any ideas on why this is happening?

[BrunoBernardino]

Seems like the URL you provided for bewCloud isn't correct (or at least reachable), given that error. If you don't want to share it here (publicly), you can do it via email to help@bewcloud.com so I can see if I can reach that URL or not.

[Bubba8291]

@BrunoBernardino The URL is internal, so it is not public facing.

Additionally, I have encountered a different error which I believe is related.

me@MacBook bewcloud-desktop % /Applications/bewCloud\ Desktop\ Sync.app/Contents/MacOS/bewCloud\ Desktop\ Sync
rclone command: rclone bisync -v bewcloud:/Documents/ /Users/me/Bewcloud/Documents/
rclone output:  2025/05/29 00:45:18 NOTICE: bisync is IN BETA. Don't use in production!
2025/05/29 00:45:18 INFO  : Setting --ignore-listing-checksum as neither --checksum nor --compare checksum are set.
2025/05/29 00:45:18 INFO  : Bisyncing with Comparison Settings: 
{
        "Modtime": true,
        "Size": true,
        "Checksum": false,
        "HashType1": 0,
        "HashType2": 0,
        "NoSlowHash": false,
        "SlowHashSyncOnly": false,
        "SlowHashDetected": true,
        "DownloadHash": false
}
2025/05/29 00:45:18 INFO  : Synching Path1 "bewcloud:Documents/" with Path2 "/Users/me/Bewcloud/Documents/"
2025/05/29 00:45:18 ERROR : Bisync critical error: cannot find prior Path1 or Path2 listings, likely due to critical error on prior run 
Tip: here are the filenames we were looking for. Do they exist? 
Path1: /Users/me/Library/Caches/rclone/bisync/bewcloud_Documents..Users_me_Bewcloud_Documents.path1.lst
Path2: /Users/me/Library/Caches/rclone/bisync/bewcloud_Documents..Users_me_Bewcloud_Documents.path2.lst
Try running this command to inspect the work dir: 
rclone lsl "/Users/me/Library/Caches/rclone/bisync"

[BrunoBernardino]

Alright, but I assume you can, for example, curl '<your-url>', right?

Regarding the error you show, maybe the local directory creation failed when the URL wasn't found. Can you manually create Bewcloud in your home directory (assuming it's not there) and try again?

[Bubba8291]

@BrunoBernardino I have the Bewcloud directory present.

One notable thing I did in my setup process was I moved my nextclouid account folder to the root of my Bewcloud instance user folder on the server side. Ex: mv nextcloud/me/files/Documents bewcloud/[uuid]/Documents

I then moved the files from my Nextcloud directory to my Bewcloud directory on my Mac. Once I did that, I started the setup and sync.

[BrunoBernardino]

I must say I see you writing bewcloud but the path in the error is Bewcloud. That matters. If the case is the same in both, please ignore, and let's try something else.

Run cd /Users/me/ && ls -ltra | grep -I 'bewcloud'. What does that show?

If it shows Bewcloud, we're good. Make a backup of your Bewcloud directory somewhere else, in case the next command does something nasty.

Now, what happens if you manually run rclone bisync --resync -v bewcloud:/Documents/ /Users/me/Bewcloud/Documents/?

[Bubba8291]

@BrunoBernardino My example command was the command I ran on the server side when I initially migrated to Bewcloud

[Bubba8291]

I am rerunning the initial sync to my mac, and bewcloud seems to be spiking the LXCs CPU. So it might be an issue with bewCloud webdav being too CPU intensive for my system.

I have seen some similar issues on Nextcloud where webdav becomes a CPU hog

Edit:

Bewcloud systemd logs:

May 29 22:11:57 BEWCLOUD systemd[1]: bewcloud.service: Main process exited, code=killed, status=9/KILL
May 29 22:11:57 BEWCLOUD systemd[1]: bewcloud.service: Failed with result 'signal'.
May 29 22:11:57 BEWCLOUD systemd[1]: bewcloud.service: Consumed 4.892s CPU time.
May 29 22:11:58 BEWCLOUD systemd[1]: bewcloud.service: Scheduled restart job, restart counter is at 33.

[BrunoBernardino]

That 9/KILL likely means it was killed over using too much memory. I haven't seen this problem yet, but I think I remember setting higher memory limits on the container when I did my first sync a long time ago. Have you tried that? What's the current limit you have on CPU/memory?

[Bubba8291]

@BrunoBernardino I have 4 GB of memory and 2 cores configured

[BrunoBernardino]

That sounds much more than enough. Can you share the docker-compose.yml file, maybe I'm missing something else?

[Bubba8291]

@BrunoBernardino I did not use docker. I compiled from source and setup a systemd service. I am running Bewcloud in a Linux Container off of a Proxmox instance. It is on Ubuntu 22.04

[Bubba8291]

Here is the systemd file I have created for bewcloud:

[Unit]
Description=Bewcloud Web Service
After=network.target

[Service]
Type=simple
User=bewcloud
WorkingDirectory=/var/lib/bewcloud
ExecStart=/home/bewcloud/.deno/bin/deno run --allow-all main.ts
Restart=on-failure

[Install]
WantedBy=multi-user.target

[BrunoBernardino]

Alright, thanks. Is there anything in the deno/app logs that could make us understand why is the memory being exhausted? With 2GB RAM and 1 cpu I had no problems re-synchronising 50GB of thousands of files. That was with Docker, though.