[Bug] Null characters inserted on backup to CIFS provider

[billfor]

Guidelines

• I have read the FAQ and it doesn't cover the issue.
• I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
• I'm on the latest version.
• I'm not using a test build (alpha/beta/release-candidate).
• This issue contains only one bug.

Describe the bug

I'm on the March 2026 Android release and I have a strange problem when using Neo-Backup via the CIFS provider. I have not used Neo-Backup in a year but in the past I had no issues. I am using the current version and also tried the last two versions.

If I back up all the apps at once, the files(s) seem to have extra NULL characters added, which makes the backup invalid and not recognized for recovery. This only happens if I try to backup everything (so that multiple operations are running in parallel) and not if I go into each app separately and do a backup.

For example, adobe reader backed up in a batch operation with many others, vs just backing it up by clicking into it and selecting backup:

Administrator@Ratbert3 MINGW64 //qnap/Test/backup/com.adobe.reader
$ ls
2026-03-17-13-08-13-585-user_0/  2026-03-17-13-08-13-585-user_0.properties  2026-03-18-00-12-22-387-user_0/  2026-03-18-00-12-22-387-user_0.properties

The 3/17 is from a batch with 100 other apps, and 3/18 is done separate. If we look at 2026-03-17-13-08-13-585-user_0.properties or bring it into an editor, we see it padded with 4 NULLs. As a result, this will not appear as a valid backup to select as a restore (the backup is ignored).

$ tail -c 16 2026-03-17-13-08-13-585-user_0.properties | od -A n -t c -t x1
       1   4   6   4   2   4   5   7   6  \n   }  \0  \0  \0  \0
  20  31  34  36  34  32  34  35  37  36  0a  7d  00  00  00  00

When processing a batch of 100 or more apps, not every app turns out like this, but most do. If I manually remove these nulls and rewrite the prop file, then I can see the file for restore in Neo-Backup, however if will fail with other errors (invalid apk) probably because the apk's themselves have NULLs at the end.

adobe.tar.gz

Expected Behavior

Looking for valid files so I can restore. Since this used to work a long time ago for me, and since it always works for any app if I do each one manually, I wonder if some type of paralleling is causing the issue. I don't think it's the CIFS provider off hand -- I can actually make a local backup on my pixel, and then copy if over and everything works (no NULLs).
One thing that might come in handy is a way to slow things down and run in single-threaded mode so only one app is backed up at a time - maybe that would work better since I can always do a backup manually by drilling into each application and clicking the backup button, and that always works. Single threaded backup could also come in handy when backing up to a USB OTG drive - I've noticed that multiple i/o operations really hammer the drive and it takes a long time.

Neo Backup's Version

8.3.17, 8.3.16, and 8.3.15

Installation Source

Official F-Droid repo

Last Known Working Version

can't remember

Relevant information

• Device: Pixel 8
• Android Version: 16 March 2026 QPR
• ROM: stock

[hg42]

(note: I'm not following all the issues, just randomly read this one)

I don't think it's the CIFS provider off hand -- I can actually make a local backup on my pixel, and then copy if over and everything works (no NULLs).

my conclusion woukd be the opposite.

if it works locally, NB does it's parallel thing with local storage (which works) and I assume the copy over CIFS is probably single threaded (which works).

So my conclusion is, that it only happens when NB forces CIFS to work in parallel.

With CIFS you have multiple options, CIFS provider, RSAF app, RoundSync, and a simlar app in that line, which I forgot (probably mentioned in faq or telegram).
There is also rclone cli.
So you could try the others.