OK, I'm (more) confused now. I thought the backup worked on other server (server2), because it was showing the same error, but in this case the backup continued and finished, as opposed to the orignal server (server1) backup that just aborts after the first offending file.
Server2: LOG 2020-09-02 12:41:52 Created directory /var/db/BackupPC/pc/datos-01 <http://backup.bolognino.com.ar/cgi-bin/BackupPC_Admin?host=datos-01>/refCnt 2020-09-02 12:41:52 full backup started for share BLN 2020-09-02 14:32:31 full backup 0 complete, 46709 files, 59836945366 bytes, 224 xferErrs (0 bad files, 0 bad shares, 224 other) XferLOG XferLOG file /var/db/BackupPC/pc/datos-01/XferLOG.0.z created 2020-09-02 12:41:52 Backup prep: type = full, case = 1, inPlace = 1, doDuplicate = 0, newBkupNum = 0, newBkupIdx = 0, lastBkupNum = , lastBkupIdx = (FillCycle = 0, noFillCnt = ) Running: /usr/local/bin/smbclient \\\\datos-01\\BLN -U bkpuser -E -d 1 -c tarmode\ full -mSMB3 -Tc - full backup started for share BLN Xfer PIDs are now 41842,41841 tar:316 tarmode is now full, system, hidden, noreset, quiet tarExtract: /usr/local/bin/BackupPC_tarExtract: got Full = 1 tarExtract: /usr/local/bin/BackupPC_tarExtract starting... (XferLogLevel = 1) [ skipped 3 lines ] tar:974 Fatal: Can't translate pathname './Administracion/AFIP - Administración Federal de Ingresos Públicos.pdf' to UTF-8 XferErr NT_STATUS_UNSUCCESSFUL listing \Administracion\* ... tar:974 Fatal: Can't translate pathname './WD/Rolo/Downloads/Electrificación con tomacorriente.pdf' to UTF-8 XferErr NT_STATUS_UNSUCCESSFUL listing \WD\Rolo\Downloads\* [ skipped 2 lines ] tar:974 Fatal: Can't translate pathname './WD/Rolo/Favorites/Links/Galería de Web Slice.url' to UTF-8 XferErr NT_STATUS_UNSUCCESSFUL listing \WD\Rolo\Favorites\Links\* [ skipped 83 lines ] tar:974 Fatal: Can't translate pathname './WD/Rolo/Pictures/Rolando/Mi instantánea 1.png' to UTF-8 XferErr NT_STATUS_UNSUCCESSFUL listing \WD\Rolo\Pictures\Rolando\* [ skipped 4 lines ] tar:717 Total bytes received: 59836945366 readOutput: sysread returns 0 and got EOF (exit ok = 1, ) [ skipped 1 lines ] tarExtract: Done: 0 errors, 6165 filesExist, 10453625404 sizeExist, 8283490235 sizeExistComp, 46709 filesTotal, 59836945366 sizeTotal, 40544 filesNew, 49383319962 sizeNew, 38122453382 sizeNewComp, 51704 inodeLast Xfer PIDs are now full backup 0 complete, 46709 files, 59836945366 bytes, 224 xferErrs (0 bad files, 0 bad shares, 224 other) BackupExpire: cntFull = 1, cntIncr = 0, firstFull = 0, firstIncr = , oldestIncr = 0, oldestFull = 0.0768402777777778 Running BackupPC_refCountUpdate -h datos-01 on datos-01 Xfer PIDs are now 47192 BackupPC_refCountUpdate: doing fsck on datos-01 #0 (full) since $ConfRefCntFsck == 1 BackupPC_refCountUpdate: host datos-01 got 0 errors (took 12 secs) Xfer PIDs are now Finished BackupPC_refCountUpdate (running time: 12 sec) Xfer PIDs are now ------------------------------------------------------------------------------------------------------------------------ Server1 LOG 2020-09-02 16:10:38 full backup started for share Folder 2020-09-02 16:11:10 Got fatal error during xfer (Non-zero exit status from smbclient) 2020-09-02 16:11:15 Backup aborted (Non-zero exit status from smbclient) XferLOG XferLOG file /var/db/BackupPC/pc/winserver/XferLOG.0.z created 2020-09-02 16:10:38 Backup prep: type = full, case = 6, inPlace = 1, doDuplicate = 0, newBkupNum = 0, newBkupIdx = 0, lastBkupNum = , lastBkupIdx = (FillCycle = 0, noFillCnt = ) Running: /usr/local/bin/smbclient \\\\winserver\\Folder -m SMB3 -U bkpuser -E -d 1 -c tarmode\ full -Tc - full backup started for share Folder Xfer PIDs are now 50291,50290 tar:316 tarmode is now full, system, hidden, noreset, quiet tarExtract: /usr/local/bin/BackupPC_tarExtract: got Full = 1 tarExtract: /usr/local/bin/BackupPC_tarExtract starting... (XferLogLevel = 1) [ skipped 4 lines ] tar:974 Fatal: Can't translate pathname './Ajuste Inflación Año 2019.xps' to UTF-8 XferErr NT_STATUS_UNSUCCESSFUL listing \* tar:710 do_list fail NT_STATUS_UNSUCCESSFUL tar:717 Total bytes received: 289563505 [ skipped 5 lines ] readOutput: sysread returns 0 and got EOF (exit ok = , ) XferErr Non-zero exit status from smbclient [ skipped 1 lines ] tarExtract: Done: 0 errors, 7 filesExist, 289563505 sizeExist, 285326858 sizeExistComp, 7 filesTotal, 289563505 sizeTotal, 0 filesNew, 0 sizeNew, 0 sizeNewComp, 121 inodeLast Xfer PIDs are now Got fatal error during xfer (Non-zero exit status from smbclient) Backup aborted (Non-zero exit status from smbclient) BackupFailCleanup: nFilesTotal = 7, type = full, BackupCase = 6, inPlace = 1, lastBkupNum = BackupFailCleanup: inPlace with some new files... no cleanup and marking partial Running BackupPC_refCountUpdate -h bejerman -f on bejerman Xfer PIDs are now 50331 BackupPC_refCountUpdate: host bejerman got 0 errors (took 0 secs) Xfer PIDs are now Finished BackupPC_refCountUpdate (running time: 0 sec) Xfer PIDs are now Additionally, I can browse Server2 backup, view and restore those files, BUT they're corrupted (different hash). The main difference I can see is the "Non-zero exit status from smbclient" message, and the only thing I can think of is that on Server1 the offending file is on the share's root (XferErr NT_STATUS_UNSUCCESSFUL listing \*), while on Server2 is inside other directories (XferErr NT_STATUS_UNSUCCESSFUL listing \Administracion\*) M On Wed, Sep 2, 2020 at 3:30 PM Mariano Aliaga <marianoali...@gmail.com> wrote: > Craig, > > On Wed, Sep 2, 2020 at 3:10 PM Craig Barratt < > cbarr...@users.sourceforge.net> wrote: > >> Mariano, >> >> I believe the unix charset should always be utf-8. It's the dos charset >> that you should be changing. >> > > OK, tried that combination "dos charset = CP1252 & unix charset = UTF-8" > but doesn't work. Just for the record, I have older backup servers > (bpc-3.3.1, smb-4.5.16, linux) with "dos charset = CP850 & unix charset = > UTF-8" that work OK. > > > >> Craig >> > > M > >> On Wed, Sep 2, 2020 at 10:51 AM Mariano Aliaga <marianoali...@gmail.com> >> wrote: >> >>> On Wed, Sep 2, 2020 at 2:20 PM Craig Barratt < >>> cbarr...@users.sourceforge.net> wrote: >>> >>>> Mariano, >>>> >>>> Yes, the trick is to figure out what the correct charset name is for >>>> the windows machine. You could use smbclient interactively to make >>>> checking it be easier (ie, just navigate to the directory containing the >>>> offending entry, and try listing that directory). >>>> >>> >>> Yes, I've been trying that way with smbclient interactively. With >>> default config (UTF-8) files list OK, with special characters printed. With >>> other settings sometimes special characters are not shown, sometimes look >>> OK, but backup fails anyways. I've tried so far (for unix charset): >>> UTF-8@latin, ISO8859-1, ISO8859-15, CP1252 >>> >>> >>> >>>> Have you tried cp-1252 <https://en.wikipedia.org/wiki/Windows-1252>? >>>> >>> >>> Yes, but: I didn't know whether that's for unix charset or dos charset, >>> but tested different combinations and didn't work. >>> >>> And I'm not sure that's a valid codepage on FreeBSD, as it's not shown >>> as valid charmap: >>> >>> $ locale -m | grep CP >>> CP1131 >>> CP1251 >>> CP866 >>> CP949 >>> >>> On linux 1252 is shown, though. >>> >>> >>> >>>> Craig >>>> >>> >>> M >>> >>> >>> On Wed, Sep 2, 2020 at 10:05 AM Mariano Aliaga <marianoali...@gmail.com> >>>> wrote: >>>> >>>>> Hi Craig, >>>>> Thanks for your reply >>>>> >>>>> On Wed, Sep 2, 2020 at 1:49 PM Craig Barratt via BackupPC-users < >>>>> backuppc-users@lists.sourceforge.net> wrote: >>>>> >>>>>> The "tar" errors are from smbclient. Unfortunately the output format >>>>>> of smb messages have changed many times over the years. I'm happy to >>>>>> accept PRs for detecting additional errors it reports if someone wants to >>>>>> submit something. >>>>>> >>>>> >>>>> OK, I'll try to send a PR with the details. >>>>> >>>>> >>>>> >>>>>> As Jeff points out, rsync is a far better option. It has built in >>>>>> support for charset conversion, which is required for Windows machines >>>>>> since their file systems don't use utf-8. >>>>>> >>>>> >>>>>> But that said smbclient should be able to do charset conversion. >>>>>> What settings do you have for "dos charset" and "unix charset" in your >>>>>> smb.conf on the backuppc server? >>>>>> >>>>> >>>>> Exactly, that's what I read on the docs: "If you are using smbclient >>>>> on a WinXX machine, smbclient will convert to the "unix charset" setting >>>>> in >>>>> smb.conf..." I've been playing with different settings for those two >>>>> smb.conf options, but didn't have luck so left them at their default >>>>> value: >>>>> >>>>> dos charset = CP850 >>>>> unix charset = UTF-8 >>>>> >>>>> >>>>> Just as a side note: an old Win2k8 32bit server seems to work. Just >>>>> newer ones (w2k10, w2k12 server, etc) show this behavior. >>>>> >>>>> >>>>> Craig >>>>>> >>>>> >>>>> M >>>>> >>>>>> On Wed, Sep 2, 2020 at 9:22 AM <backu...@kosowsky.org> wrote: >>>>>> >>>>>>> Mariano Aliaga wrote at about 11:34:55 -0300 on Wednesday, September >>>>>>> 2, 2020: >>>>>>> > Hi, >>>>>>> > >>>>>>> > On Wed, Sep 2, 2020 at 11:28 AM <backu...@kosowsky.org> wrote: >>>>>>> > >>>>>>> > > G.W. Haywood via BackupPC-users wrote at about 14:22:50 +0100 on >>>>>>> > > Wednesday, September 2, 2020: >>>>>>> > > > Hi there, >>>>>>> > > > >>>>>>> > > > On Wed, 2 Sep 2020, Mariano Aliaga wrote: >>>>>>> > > > > ... >>>>>>> > > > > tar:974 Fatal: Can't translate pathname './Ajuste >>>>>>> Inflaci?n >>>>>>> > > A?o2019.xps' to UTF-8 >>>>>>> > > > > ... >>>>>>> > > > > ... So I wonder if this is a known bug, it's smbclient, >>>>>>> backuppc, >>>>>>> > > > > tar or what? Is there some known workaround? I'd >>>>>>> appreciate any help >>>>>>> > > > > you could give. >>>>>>> > > > >>>>>>> > > > I think it's a message from 'tar'. (That's because that's >>>>>>> what it >>>>>>> > > says. :) >>>>>>> > > > >>>>>>> > > > It's not what I'd call a bug, it's the unfortunate result of >>>>>>> the many >>>>>>> > > > changes to the capabilities of both utilties and filesystems >>>>>>> over the >>>>>>> > > > time that they've been in use. There can be ambiguities >>>>>>> when strings >>>>>>> > > > are translated between some character sets, and you really >>>>>>> don't want >>>>>>> > > > that kind of ambiguity in file names. >>>>>>> > > > >>>>>>> > > > What's your output from 'locale'? >>>>>>> > > > >>>>>>> > > > Just a stab in the dark but you might try UTF-16, as >>>>>>> mentioned here: >>>>>>> > > > >>>>>>> > > > >>>>>>> https://forums.freebsd.org/threads/tar-cant-translate-pathname.32262/ >>>>>>> > > > >>>>>>> > > > Life was so simple when everything was done with 7-bit ASCII >>>>>>> codes... >>>>>>> > > > >>>>>>> > > > -- >>>>>>> > > > >>>>>>> > > > 73, >>>>>>> > > > Ged. >>>>>>> > > > >>>>>>> > > >>>>>>> > > Agree with Ged... I have had similar issues with rsync over time >>>>>>> > > But two further items: >>>>>>> > > 1. Does the entire tar backup fail or does it just skip the >>>>>>> offending >>>>>>> > > paths? >>>>>>> > > >>>>>>> > >>>>>>> > The entire (smb) backup fails. >>>>>>> That doesn't typically happen with rsync as it typically "skips" the >>>>>>> file. >>>>>>> What happens when you try to manually 'tar' the file? >>>>>>> Do you get the same error? >>>>>>> If you are tarring multiple files, does the entire manual tar fail? >>>>>>> >>>>>>> Is there any reason you can't use rsync? >>>>>>> It's typically faster, more robust, and more full-featured (e.g., it >>>>>>> can backup more file types along with ACLs & xattrs) whereas tar has >>>>>>> more limitations... >>>>>>> > >>>>>>> > >>>>>>> > > 2. (This one is for Craig) It would be good if the error >>>>>>> summaries >>>>>>> > > could better reflect the errors encountered by the transport >>>>>>> > > method. In this case, tar has a 'fatal' error, >>>>>>> > > tar:974 Fatal: Can't translate pathname './Ajuste >>>>>>> Inflación Año >>>>>>> > > but the summary line says: >>>>>>> > > tarExtract: Done: 0 errors, 7 filesExist, 289563505 >>>>>>> sizeExist, >>>>>>> > > 285326858 sizeExistComp, 7 filesTotal, 289563505 >>>>>>> sizeTotal, 0 >>>>>>> > > filesNew, 0 sizeNew, 0 sizeNewComp, 110 inodeLast >>>>>>> > > >>>>>>> > > It's never been clear to me which 'errors' get counted and >>>>>>> which >>>>>>> > > don't... >>>>>>> > > >>>>>>> > > >>>>>>> > > _______________________________________________ >>>>>>> > > BackupPC-users mailing list >>>>>>> > > BackupPC-users@lists.sourceforge.net >>>>>>> > > List: >>>>>>> https://lists.sourceforge.net/lists/listinfo/backuppc-users >>>>>>> > > Wiki: https://github.com/backuppc/backuppc/wiki >>>>>>> > > Project: https://backuppc.github.io/backuppc/ >>>>>>> > > >>>>>>> > _______________________________________________ >>>>>>> > BackupPC-users mailing list >>>>>>> > BackupPC-users@lists.sourceforge.net >>>>>>> > List: >>>>>>> https://lists.sourceforge.net/lists/listinfo/backuppc-users >>>>>>> > Wiki: https://github.com/backuppc/backuppc/wiki >>>>>>> > Project: https://backuppc.github.io/backuppc/ >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> BackupPC-users mailing list >>>>>>> BackupPC-users@lists.sourceforge.net >>>>>>> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users >>>>>>> Wiki: https://github.com/backuppc/backuppc/wiki >>>>>>> Project: https://backuppc.github.io/backuppc/ >>>>>>> >>>>>> _______________________________________________ >>>>>> BackupPC-users mailing list >>>>>> BackupPC-users@lists.sourceforge.net >>>>>> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users >>>>>> Wiki: https://github.com/backuppc/backuppc/wiki >>>>>> Project: https://backuppc.github.io/backuppc/ >>>>>> >>>>>
_______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
