# Errors with ftp **URL:** \ **Category:** Support\ **Created:** [November 29, 2024, 12:26pm UTC](https://forum.duplicati.com/t/errors-with-ftp/19576 "2024-11-29T12:26:55Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Tom\_qv](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/a698b9/32.png) [@Tom\_qv](https://forum.duplicati.com/u/Tom_qv)\ **Post date:** [November 29, 2024, 12:26pm UTC](https://forum.duplicati.com/t/errors-with-ftp/19576/1 "2024-11-29T12:26:55Z")
Hi, I’m new to Duplicati after recommendation in the news. I created my first backup, its more or less 27GB big and goes to my ftp-account. It ran for a couple of hours, ca. 16GB of zip.aes files were uploaded but now status is just “Stopping after current file…”, Last backup: never, no errors. “Run now” is not doing anything. How can I reset the status and try again? Thanks Tom ---
**Author:** ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)\ **Post date:** [December 6, 2024, 1:39pm UTC](https://forum.duplicati.com/t/errors-with-ftp/19576/2 "2024-12-06T13:39:34Z")
Welcome to the forum @Tom_qv > [@Tom\_qv](#): > > status is just “Stopping after current file…” Presumably you tried the stop button in hope of something good happening? > [@Tom\_qv](#): > > “Run now” is not doing anything. It queued a backup (hard to spot though) to run after current backup finishes. > [@Tom\_qv](#): > > How can I reset the status and try again? If you can’t end the backup any other way, you can end the Duplicati process. For example, Windows has a Task Manager, and other systems have similar. There’s not really any reset required. Next run should pick up where it left off. > [@Tom\_qv](#): > > Last backup: never You can start totally fresh by deleting destination files and Duplicati [database](https://docs.duplicati.com/detailed-descriptions/the-local-database). This would lose backup history if you had any, but having none makes it nicer. It would be good to look into what went wrong with your first try, if you care to. ---
**Author:** ![kenkendk](https://forum.duplicati.com/user_avatar/forum.duplicati.com/kenkendk/32/5305_2.png) [@kenkendk](https://forum.duplicati.com/u/kenkendk)\ **Post date:** [December 6, 2024, 4:28pm UTC](https://forum.duplicati.com/t/errors-with-ftp/19576/3 "2024-12-06T16:28:38Z")
> [@Tom\_qv](#): > > How can I reset the status and try again? Hi @Tom_qv , it could look like you have experienced a similar issue to this: > > > \- \[x\] I have searched open and closed issues for duplicates. > \- \[x\] I have searc…hed the \[forum\](https://forum.duplicati.com) for related topics. > > \---------------------------------------- > > \## Environment info > \- \*\*Duplicati version\*\*: 2.1.0.100\_canary\_2024-11-25 > \- \*\*Operating system\*\*: Linux > \- \*\*Backend\*\*: WebDav > > \## Description > > As mentioned on https://github.com/duplicati/duplicati/issues/5715 I'm currently having issues using WebDAV as the backend because Duplicati is hanging on \`Backend event: Get - Started: duplicati-xxxxxxxxTxxxxxxZ.dlist.zip.aes (x.xx MB)\` if there is an internet connection drop. > I cross-checked this because I noticed that the logs stop every time I see a disconnection on the system logs, more specifically a "Lost carrier" on the ethernet interface: > > \`\`\` > Dec 02 22:06:34 nas systemd-networkd\[318\]: eth0: Lost carrier > Dec 02 22:06:34 nas systemd-networkd\[318\]: eth0: DHCP lease lost > Dec 02 22:06:34 nas avahi-daemon\[617\]: Withdrawing address record for 192.168.1.1 on eth0. > Dec 02 22:06:34 nas avahi-daemon\[617\]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.1. > Dec 02 22:06:34 nas avahi-daemon\[617\]: Interface eth0.IPv4 no longer relevant for mDNS. > Dec 02 22:06:34 nas kernel: macb 1f00100000.ethernet eth0: Link is Down > Dec 02 22:06:34 nas systemd-networkd\[318\]: eth0: DHCPv6 lease lost > Dec 02 22:06:40 nas systemd-networkd\[318\]: eth0: Gained carrier > Dec 02 22:06:40 nas NetworkManager\[750\]: \ \[1733177200.8377\] device (eth0): carrier: link connected > Dec 02 22:06:40 nas kernel: macb 1f00100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off > Dec 02 22:06:44 nas systemd-networkd\[318\]: eth0: DHCPv4 address 192.168.1.1/24, gateway 192.168.1.254 acquired from 192.168.1.254 > Dec 02 22:06:44 nas avahi-daemon\[617\]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.1. > Dec 02 22:06:44 nas avahi-daemon\[617\]: New relevant interface eth0.IPv4 for mDNS. > Dec 02 22:06:44 nas avahi-daemon\[617\]: Registering new address record for 192.168.1.1 on eth0.IPv4. > \`\`\` > > Please note that this is a recent (2~3 months ago was fine) behavior. I don't see the connectivity warnings I had before on previous versions when I had internet connectivity issues. > If there is a way to somehow profile Duplicati and further understand how the connection is being handled please let me know and I'll try to collect these logs. > > \## Steps to reproduce > > 1. Create and start a backup > 2. Re-run the backend and once Duplicati starts download dlist.zip files disconnect the internet > 3. Duplicati should hang > > > > \- \*\*Actual result\*\*: > I see Duplicati hanging > \- \*\*Expected result\*\*: > I expect Duplicati to gracefully handle the connectivity lost (timeout) and either cancel the backup or (ideally) retry to connect. > > \## Screenshots > N/A > > \## Debug log > The debug log stops on \`Backend event: Get - Started: duplicati-xxxxxxxxTxxxxxxZ.dlist.zip.aes (x.xx MB)\`. It seems that some cases of errors can cause a deadlock with 2.1.0.2. I am investigating, but for now I do not know many details. > [@ts678](#): > > There’s not really any reset required. Next run should pick up where it left off. True, except for the very first backup, which I fear is the case here. ---
**Author:** ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)\ **Post date:** [December 6, 2024, 4:39pm UTC](https://forum.duplicati.com/t/errors-with-ftp/19576/4 "2024-12-06T16:39:17Z")
> [@kenkendk](#): > > True, except for the very first backup What happens? IIRC I don’t get a synthetic file list (although in theory it seems possible). Anything worse than a full restart? Basically, is there any need for specific reset actions? ---
**Author:** ![kenkendk](https://forum.duplicati.com/user_avatar/forum.duplicati.com/kenkendk/32/5305_2.png) [@kenkendk](https://forum.duplicati.com/u/kenkendk)\ **Post date:** [December 6, 2024, 4:49pm UTC](https://forum.duplicati.com/t/errors-with-ftp/19576/5 "2024-12-06T16:49:55Z")
> [@ts678](#): > > What happens? IIRC I don’t get a synthetic file list (although in theory it seems possible). > Anything worse than a full restart? The way the interrupted continue works, is that it looks at the last successful backup, and then makes a “synthetic version”. The synthetic version is created from whatever completed, and then patching with the files from the previous version. Since there is no previous version the recovery gives up. I think we should just allow that you can continue without a previous version (pretend it was empty), but that code is not implemented yet. A silly workaround is the create the backup with just a single file, and then start the actual backup after this, so it can resume on crashes. > [@ts678](#): > > Basically, is there any need for specific reset actions? For the current code, yes, the situation where the initial backup did not succeed, you need to clean up the remote storage, local database, and start over.