Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Joshua Myles]

Checking in to provide a report on 22.1.4 and the VSS issue for 
client-initiated connections. We have 11 Windows FDs using client-initiated 
connections, and nearly all of them would previously give VSS warnings 
(ERR=The process cannot access the file because it is being used by another 
process.) and caused us to effectively ignore the Bareos warning jobs.

As of 22.1.4 a couple of days ago, we've not seen any job warnings due to 
VSS. So here its looks like the fix is good, and I'd expect the same from 
23.0.2 though haven't tested it yet.

Josh

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/3f765c10-a32d-4180-9c7e-aaa733b06697n%40googlegroups.com.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Sebastian Sura]

They can be found here: https://download.bareos.org/current/

Sincerly

Sebastian Sura

Am 25.01.24 um 21:20 schrieb 'jo.go...@hosted-power.com' via bareos-users:
Where do I find the 23 pre release? I only see version 22 on the link 
shared earlier? :)


On Thursday 25 January 2024 at 09:30:56 UTC+1 Andreas Rogge wrote:

Yes, it is in the pre-release for 23 and also for 21.

Am 24.01.24 um 20:59 schrieb 'jo.go...@hosted-power.com' via
bareos-users:
> Ok that is cool, this similar exists for Bareos 23? Since we're
already
> on 23.0.1, the 22.x would be also a lower version :)
>
> On Wednesday 24 January 2024 at 16:49:31 UTC+1 Andreas Rogge wrote:
>
> Hi Josh,
>
> the backport has already happened in PR 1667. You can try the
> pre-release packages from these subscription repositories:
> https://download.bareos.com/bareos/testing/CD/bareos-22
> 
>
> Version 22.1.4~pre39 (and every newer version) should contain
the fix.
> You can safely install the packages from there. An upgrade to the
> upcoming version 22.1.4 will be seamless.
>
> Best Regards,
> Andreas
>
> Am 24.01.24 um 12:33 schrieb Joshua Myles:
> > I've only tested with one client, but 24.0.0~pre187.8e12c147a did
> work
> > with no VSS errors. I'll be watching for this to be backported
to 22
> > (subscription).
> >
> > Josh
> >
> > On Monday, January 22, 2024 at 11:37:51 AM UTC-5 Spadajspadaj
wrote:
> >
> > __
> >
> > Yes, it does seem to be working!
> >
> > 22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots.
> Driver="Win64 VSS"
> > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not
> processed as onefs = yes.
> > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not
> processed as onefs = yes.
> > 22-Jan 14:16 dziura-fd JobId 17111:
> (S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ ->
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
> > 22-Jan 14:16 dziura-fd JobId 17111:
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
> > [...]
> > Non-fatal FD errors: 0
> > SD Errors: 0
> > FD termination status: OK
> > SD termination status: OK
> >
> > *status client=dziura-fd
> > [...]
> > dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024) VSS
> Microsoft Windows 8 Professional (build 9200), 64-bit
> >
> > Thank you!
> >
> > MK
> >
> > On 22.01.2024 09:42, Sebastian Sura wrote:
> >>
> >> We managed to reproduce the issue.  As you already noted, the
> >> cause was the "connection from client to director" option.
> >>
> >> This was fixed by https://github.com/bareos/bareos/pull/1665
> 
> >>  >
> >>
> >> The current next release ( https://download.bareos.org/next/
> 
> >>  > ) already contains the fix.
> >> Let me know if you tried that version and the issue still
persists!
> >>
> >> Sincerly
> >>
> >> Sebastian Sura
> >>
> >> Am 18.01.24 um 19:53 schrieb Joshua Myles:
> >>> Interesting. We have a mix of client-initiated and not, and
at a
> >>> glance it looks like the only jobs that ever have warnings
> >>> ("ERR=The process cannot access the file because it is being
used
> >>> by another process.") are the ones from clients with
"Connection
> >>> From Client To Director = yes". Seems like maybe there's a
> >>> different code path used when that's enabled, and it hits a
bug.
> >>> Unfortunately we can't switch away from client-initiated for
> >>> these, we've just been living with the warnings.
> >>>
> >>> Josh
> >>>
> >>> On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj
> wrote:
> >>>
> >>> Yes. It does seem to be the cause.
> >>>
> >>> I switched the client connectivity to the "normal" mode
> >>> (director to client) and the job completed OK and I had no
> >>> problems accessing the registry file.
> >>>
> >>> MK
> >>>
> >>> On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via
> >>> bareos-users wrote:
>  Coindidence or not, we also use Connection From Client to
>  Director=yes
> 
>  Coindidence or not,  Another host which does not have this
>  setting, has 0 errors!
> 
>  On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj
>  wrote:
> 
>  Hi Sebastian.
> 
>  Thx for looking into it. This 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

['jo.go...@hosted-power.com' via bareos-users]

Where do I find the 23 pre release? I only see version 22 on the link 
shared earlier? :)

On Thursday 25 January 2024 at 09:30:56 UTC+1 Andreas Rogge wrote:

> Yes, it is in the pre-release for 23 and also for 21.
>
> Am 24.01.24 um 20:59 schrieb 'jo.go...@hosted-power.com' via bareos-users:
> > Ok that is cool, this similar exists for Bareos 23? Since we're already 
> > on 23.0.1, the 22.x would be also a lower version :)
> > 
> > On Wednesday 24 January 2024 at 16:49:31 UTC+1 Andreas Rogge wrote:
> > 
> > Hi Josh,
> > 
> > the backport has already happened in PR 1667. You can try the
> > pre-release packages from these subscription repositories:
> > https://download.bareos.com/bareos/testing/CD/bareos-22
> > 
> > 
> > Version 22.1.4~pre39 (and every newer version) should contain the fix.
> > You can safely install the packages from there. An upgrade to the
> > upcoming version 22.1.4 will be seamless.
> > 
> > Best Regards,
> > Andreas
> > 
> > Am 24.01.24 um 12:33 schrieb Joshua Myles:
> > > I've only tested with one client, but 24.0.0~pre187.8e12c147a did
> > work
> > > with no VSS errors. I'll be watching for this to be backported to 22
> > > (subscription).
> > >
> > > Josh
> > >
> > > On Monday, January 22, 2024 at 11:37:51 AM UTC-5 Spadajspadaj wrote:
> > >
> > > __
> > >
> > > Yes, it does seem to be working!
> > >
> > > 22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots.
> > Driver="Win64 VSS"
> > > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not
> > processed as onefs = yes.
> > > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not
> > processed as onefs = yes.
> > > 22-Jan 14:16 dziura-fd JobId 17111:
> > (S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ ->
> > \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
> > > 22-Jan 14:16 dziura-fd JobId 17111:
> > (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
> > \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
> > > [...]
> > > Non-fatal FD errors: 0
> > > SD Errors: 0
> > > FD termination status: OK
> > > SD termination status: OK
> > >
> > > *status client=dziura-fd
> > > [...]
> > > dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024) VSS
> > Microsoft Windows 8 Professional (build 9200), 64-bit
> > >
> > > Thank you!
> > >
> > > MK
> > >
> > > On 22.01.2024 09:42, Sebastian Sura wrote:
> > >>
> > >> We managed to reproduce the issue.  As you already noted, the
> > >> cause was the "connection from client to director" option.
> > >>
> > >> This was fixed by https://github.com/bareos/bareos/pull/1665
> > 
> > >>  > >
> > >>
> > >> The current next release ( https://download.bareos.org/next/
> > 
> > >>  > > ) already contains the fix.
> > >> Let me know if you tried that version and the issue still persists!
> > >>
> > >> Sincerly
> > >>
> > >> Sebastian Sura
> > >>
> > >> Am 18.01.24 um 19:53 schrieb Joshua Myles:
> > >>> Interesting. We have a mix of client-initiated and not, and at a
> > >>> glance it looks like the only jobs that ever have warnings
> > >>> ("ERR=The process cannot access the file because it is being used
> > >>> by another process.") are the ones from clients with "Connection
> > >>> From Client To Director = yes". Seems like maybe there's a
> > >>> different code path used when that's enabled, and it hits a bug.
> > >>> Unfortunately we can't switch away from client-initiated for
> > >>> these, we've just been living with the warnings.
> > >>>
> > >>> Josh
> > >>>
> > >>> On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj
> > wrote:
> > >>>
> > >>> Yes. It does seem to be the cause.
> > >>>
> > >>> I switched the client connectivity to the "normal" mode
> > >>> (director to client) and the job completed OK and I had no
> > >>> problems accessing the registry file.
> > >>>
> > >>> MK
> > >>>
> > >>> On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via
> > >>> bareos-users wrote:
> >  Coindidence or not, we also use Connection From Client to
> >  Director=yes
> > 
> >  Coindidence or not,  Another host which does not have this
> >  setting, has 0 errors!
> > 
> >  On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj
> >  wrote:
> > 
> >  Hi Sebastian.
> > 
> >  Thx for looking into it. This is the job log. Not much
> >  interesting stuff in there.
> > 
> >  The same thing (the jobid being zero in the trace log)
> >  was in the previous trace I attached excerpt from few
> >  days ago. But that one was from a different machine.
> >  That was a clean win10 installation just for testing the
> >  FD, this one is my production setup. Anyway, one thing
> >  that can be relatively uncommon (but 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Andreas Rogge]

Yes, it is in the pre-release for 23 and also for 21.

Am 24.01.24 um 20:59 schrieb 'jo.go...@hosted-power.com' via bareos-users:
Ok that is cool, this similar exists for Bareos 23? Since we're already 
on 23.0.1, the 22.x would be also a lower version :)


On Wednesday 24 January 2024 at 16:49:31 UTC+1 Andreas Rogge wrote:

Hi Josh,

the backport has already happened in PR 1667. You can try the
pre-release packages from these subscription repositories:
https://download.bareos.com/bareos/testing/CD/bareos-22


Version 22.1.4~pre39 (and every newer version) should contain the fix.
You can safely install the packages from there. An upgrade to the
upcoming version 22.1.4 will be seamless.

Best Regards,
Andreas

Am 24.01.24 um 12:33 schrieb Joshua Myles:
 > I've only tested with one client, but 24.0.0~pre187.8e12c147a did
work
 > with no VSS errors. I'll be watching for this to be backported to 22
 > (subscription).
 >
 > Josh
 >
 > On Monday, January 22, 2024 at 11:37:51 AM UTC-5 Spadajspadaj wrote:
 >
 > __
 >
 > Yes, it does seem to be working!
 >
 > 22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots.
Driver="Win64 VSS"
 > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not
processed as onefs = yes.
 > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not
processed as onefs = yes.
 > 22-Jan 14:16 dziura-fd JobId 17111:
(S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ ->
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
 > 22-Jan 14:16 dziura-fd JobId 17111:
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
 > [...]
 > Non-fatal FD errors: 0
 > SD Errors: 0
 > FD termination status: OK
 > SD termination status: OK
 >
 > *status client=dziura-fd
 > [...]
 > dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024) VSS
Microsoft Windows 8 Professional (build 9200), 64-bit
 >
 > Thank you!
 >
 > MK
 >
 > On 22.01.2024 09:42, Sebastian Sura wrote:
 >>
 >> We managed to reproduce the issue.  As you already noted, the
 >> cause was the "connection from client to director" option.
 >>
 >> This was fixed by https://github.com/bareos/bareos/pull/1665

 >> >
 >>
 >> The current next release ( https://download.bareos.org/next/

 >> > ) already contains the fix.
 >> Let me know if you tried that version and the issue still persists!
 >>
 >> Sincerly
 >>
 >> Sebastian Sura
 >>
 >> Am 18.01.24 um 19:53 schrieb Joshua Myles:
 >>> Interesting. We have a mix of client-initiated and not, and at a
 >>> glance it looks like the only jobs that ever have warnings
 >>> ("ERR=The process cannot access the file because it is being used
 >>> by another process.") are the ones from clients with "Connection
 >>> From Client To Director = yes". Seems like maybe there's a
 >>> different code path used when that's enabled, and it hits a bug.
 >>> Unfortunately we can't switch away from client-initiated for
 >>> these, we've just been living with the warnings.
 >>>
 >>> Josh
 >>>
 >>> On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj
wrote:
 >>>
 >>> Yes. It does seem to be the cause.
 >>>
 >>> I switched the client connectivity to the "normal" mode
 >>> (director to client) and the job completed OK and I had no
 >>> problems accessing the registry file.
 >>>
 >>> MK
 >>>
 >>> On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via
 >>> bareos-users wrote:
  Coindidence or not, we also use Connection From Client to
  Director=yes
 
  Coindidence or not,  Another host which does not have this
  setting, has 0 errors!
 
  On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj
  wrote:
 
  Hi Sebastian.
 
  Thx for looking into it. This is the job log. Not much
  interesting stuff in there.
 
  The same thing (the jobid being zero in the trace log)
  was in the previous trace I attached excerpt from few
  days ago. But that one was from a different machine.
  That was a clean win10 installation just for testing the
  FD, this one is my production setup. Anyway, one thing
  that can be relatively uncommon (but I don't see why it
  should affect anything about the job itself) is that I
  use passive 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

['jo.go...@hosted-power.com' via bareos-users]

Ok that is cool, this similar exists for Bareos 23? Since we're already on 
23.0.1, the 22.x would be also a lower version :)

On Wednesday 24 January 2024 at 16:49:31 UTC+1 Andreas Rogge wrote:

> Hi Josh,
>
> the backport has already happened in PR 1667. You can try the 
> pre-release packages from these subscription repositories:
> https://download.bareos.com/bareos/testing/CD/bareos-22
>
> Version 22.1.4~pre39 (and every newer version) should contain the fix. 
> You can safely install the packages from there. An upgrade to the 
> upcoming version 22.1.4 will be seamless.
>
> Best Regards,
> Andreas
>
> Am 24.01.24 um 12:33 schrieb Joshua Myles:
> > I've only tested with one client, but 24.0.0~pre187.8e12c147a did work 
> > with no VSS errors. I'll be watching for this to be backported to 22 
> > (subscription).
> > 
> > Josh
> > 
> > On Monday, January 22, 2024 at 11:37:51 AM UTC-5 Spadajspadaj wrote:
> > 
> > __
> > 
> > Yes, it does seem to be working!
> > 
> > 22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots. 
> Driver="Win64 VSS"
> > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed 
> as onefs = yes.
> > 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed 
> as onefs = yes.
> > 22-Jan 14:16 dziura-fd JobId 17111: 
> (S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ -> 
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
> > 22-Jan 14:16 dziura-fd JobId 17111: 
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
> > [...]
> > Non-fatal FD errors: 0
> > SD Errors: 0
> > FD termination status: OK
> > SD termination status: OK
> > 
> > *status client=dziura-fd
> > [...]
> > dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024) VSS 
> Microsoft Windows 8 Professional (build 9200), 64-bit
> > 
> > Thank you!
> > 
> > MK
> > 
> > On 22.01.2024 09:42, Sebastian Sura wrote:
> >>
> >> We managed to reproduce the issue.  As you already noted, the
> >> cause was the "connection from client to director" option.
> >>
> >> This was fixed by https://github.com/bareos/bareos/pull/1665
> >> 
> >>
> >> The current next release ( https://download.bareos.org/next/
> >>  ) already contains the fix. 
> >> Let me know if you tried that version and the issue still persists!
> >>
> >> Sincerly
> >>
> >> Sebastian Sura
> >>
> >> Am 18.01.24 um 19:53 schrieb Joshua Myles:
> >>> Interesting. We have a mix of client-initiated and not, and at a
> >>> glance it looks like the only jobs that ever have warnings
> >>> ("ERR=The process cannot access the file because it is being used
> >>> by another process.") are the ones from clients with "Connection
> >>> From Client To Director = yes". Seems like maybe there's a
> >>> different code path used when that's enabled, and it hits a bug.
> >>> Unfortunately we can't switch away from client-initiated for
> >>> these, we've just been living with the warnings.
> >>>
> >>> Josh
> >>>
> >>> On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj wrote:
> >>>
> >>> Yes. It does seem to be the cause.
> >>>
> >>> I switched the client connectivity to the "normal" mode
> >>> (director to client) and the job completed OK and I had no
> >>> problems accessing the registry file.
> >>>
> >>> MK
> >>>
> >>> On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via
> >>> bareos-users wrote:
>  Coindidence or not, we also use Connection From Client to
>  Director=yes
> 
>  Coindidence or not,  Another host which does not have this
>  setting, has 0 errors!
> 
>  On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj
>  wrote:
> 
>  Hi Sebastian.
> 
>  Thx for looking into it. This is the job log. Not much
>  interesting stuff in there.
> 
>  The same thing (the jobid being zero in the trace log)
>  was in the previous trace I attached excerpt from few
>  days ago. But that one was from a different machine.
>  That was a clean win10 installation just for testing the
>  FD, this one is my production setup. Anyway, one thing
>  that can be relatively uncommon (but I don't see why it
>  should affect anything about the job itself) is that I
>  use passive clients (Connection From Client to
>  Director=yes, Heartbeat Interval=60).
> 
>  MK
> 
>  *list joblog jobid=17062
>  Automatically selected Catalog: PgCatalog
>  Using Catalog "PgCatalog"
>   2024-01-18 08:06:04 backup1-dir JobId 17062: Start
>  Backup JobId 17062, Job=win10test-fd.2024-01-18_08.06.02_12
>   2024-01-18 08:06:04 backup1-dir JobId 17062: Connected
>  Storage daemon at backup1.local:9103, encryption:
>  TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>   2024-01-18 08:06:04 backup1-dir JobId 17062:
>  Encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>   2024-01-18 08:06:04 backup1-dir JobId 17062: 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Andreas Rogge]

Hi Josh,

the backport has already happened in PR 1667. You can try the 
pre-release packages from these subscription repositories:

https://download.bareos.com/bareos/testing/CD/bareos-22

Version 22.1.4~pre39 (and every newer version) should contain the fix. 
You can safely install the packages from there. An upgrade to the 
upcoming version 22.1.4 will be seamless.


Best Regards,
Andreas

Am 24.01.24 um 12:33 schrieb Joshua Myles:
I've only tested with one client, but 24.0.0~pre187.8e12c147a did work 
with no VSS errors. I'll be watching for this to be backported to 22 
(subscription).


Josh

On Monday, January 22, 2024 at 11:37:51 AM UTC-5 Spadajspadaj wrote:

__

Yes, it does seem to be working!

22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots. Driver="Win64 
VSS"
22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as 
onefs = yes.
22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as 
onefs = yes.
22-Jan 14:16 dziura-fd JobId 17111: 
(S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ -> 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
22-Jan 14:16 dziura-fd JobId 17111: 
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
[...]
   Non-fatal FD errors:0
   SD Errors:  0
   FD termination status:  OK
   SD termination status:  OK

*status client=dziura-fd
[...]
dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024)  VSS Microsoft 
Windows 8 Professional (build 9200), 64-bit

Thank you!

MK

On 22.01.2024 09:42, Sebastian Sura wrote:


We managed to reproduce the issue.  As you already noted, the
cause was the "connection from client to director" option.

This was fixed by https://github.com/bareos/bareos/pull/1665


The current next release ( https://download.bareos.org/next/
 ) already contains the fix.  
Let me know if you tried that version and the issue still persists!


Sincerly

Sebastian Sura

Am 18.01.24 um 19:53 schrieb Joshua Myles:

Interesting. We have a mix of client-initiated and not, and at a
glance it looks like the only jobs that ever have warnings
("ERR=The process cannot access the file because it is being used
by another process.") are the ones from clients with "Connection
From Client To Director = yes". Seems like maybe there's a
different code path used when that's enabled, and it hits a bug.
Unfortunately we can't switch away from client-initiated for
these, we've just been living with the warnings.

Josh

On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj wrote:

Yes. It does seem to be the cause.

I switched the client connectivity to the "normal" mode
(director to client) and the job completed OK and I had no
problems accessing the registry file.

MK

On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via
bareos-users wrote:

Coindidence or not, we also use Connection From Client to
Director=yes

Coindidence or not,  Another host which does not have this
setting, has 0 errors!

On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj
wrote:

Hi Sebastian.

Thx for looking into it. This is the job log. Not much
interesting stuff in there.

The same thing (the jobid being zero in the trace log)
was in the previous trace I attached excerpt from few
days ago. But that one was from a different machine.
That was a clean win10 installation just for testing the
FD, this one is my production setup. Anyway, one thing
that can be relatively uncommon (but I don't see why it
should affect anything about the job itself) is that I
use passive clients (Connection From Client to
Director=yes, Heartbeat Interval=60).

MK

*list joblog jobid=17062
Automatically selected Catalog: PgCatalog
Using Catalog "PgCatalog"
 2024-01-18 08:06:04 backup1-dir JobId 17062: Start
Backup JobId 17062, Job=win10test-fd.2024-01-18_08.06.02_12
 2024-01-18 08:06:04 backup1-dir JobId 17062: Connected
Storage daemon at backup1.local:9103, encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062:
Encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using
Client Initiated Connection (dziura-fd).
 2024-01-18 08:06:04 backup1-dir JobId 17062: Handshake:
Immediate TLS
 2024-01-18 08:06:04 backup1-dir JobId 17062:
Encryption: 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Joshua Myles]

I've only tested with one client, but 24.0.0~pre187.8e12c147a did work with 
no VSS errors. I'll be watching for this to be backported to 22 
(subscription).

Josh

On Monday, January 22, 2024 at 11:37:51 AM UTC-5 Spadajspadaj wrote:

> Yes, it does seem to be working!
>
> 22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots. Driver="Win64 VSS"
> 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as 
> onefs = yes.
> 22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as 
> onefs = yes.
> 22-Jan 14:16 dziura-fd JobId 17111: 
> (S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ -> 
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
> 22-Jan 14:16 dziura-fd JobId 17111: 
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
> [...]
>   Non-fatal FD errors:0
>   SD Errors:  0
>   FD termination status:  OK
>   SD termination status:  OK
>
> *status client=dziura-fd
> [...]
> dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024)  VSS Microsoft 
> Windows 8 Professional (build 9200), 64-bit
>
>
> Thank you!
>
> MK
>
> On 22.01.2024 09:42, Sebastian Sura wrote:
>
> We managed to reproduce the issue.  As you already noted, the cause was 
> the "connection from client to director" option.
>
> This was fixed by https://github.com/bareos/bareos/pull/1665
>
> The current next release ( https://download.bareos.org/next/ ) already 
> contains the fix.   Let me know if you tried that version and the issue 
> still persists!
>
> Sincerly
>
> Sebastian Sura
> Am 18.01.24 um 19:53 schrieb Joshua Myles:
>
> Interesting. We have a mix of client-initiated and not, and at a glance it 
> looks like the only jobs that ever have warnings ("ERR=The process cannot 
> access the file because it is being used by another process.") are the ones 
> from clients with "Connection From Client To Director = yes". Seems like 
> maybe there's a different code path used when that's enabled, and it hits a 
> bug. Unfortunately we can't switch away from client-initiated for these, 
> we've just been living with the warnings.
>
> Josh
>
> On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj wrote:
>
> Yes. It does seem to be the cause.
>
> I switched the client connectivity to the "normal" mode (director to 
> client) and the job completed OK and I had no problems accessing the 
> registry file.
>
> MK
> On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via bareos-users wrote:
>
> Coindidence or not, we also use  Connection From Client to Director=yes 
>
> Coindidence or not,  Another host which does not have this setting, has 0 
> errors!
>
> On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj wrote:
>
> Hi Sebastian.
>
> Thx for looking into it. This is the job log. Not much interesting stuff 
> in there.
>
> The same thing (the jobid being zero in the trace log) was in the previous 
> trace I attached excerpt from few days ago. But that one was from a 
> different machine. That was a clean win10 installation just for testing the 
> FD, this one is my production setup. Anyway, one thing that can be 
> relatively uncommon (but I don't see why it should affect anything about 
> the job itself) is that I use passive clients (Connection From Client to 
> Director=yes, Heartbeat Interval=60).
>
> MK
>
> *list joblog jobid=17062
> Automatically selected Catalog: PgCatalog
> Using Catalog "PgCatalog"
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup JobId 17062, 
> Job=win10test-fd.2024-01-18_08.06.02_12
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Connected Storage daemon at 
> backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client Initiated 
> Connection (dziura-fd).
>  2024-01-18 08:06:04 backup1-dir JobId 17062:  Handshake: Immediate TLS 
>  2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device "vchanger-1-0" 
> to write.
>  2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27 wildcard excludes 
> from FilesNotToBackup Registry key
>  2024-01-18 08:06:03 dziura-fd JobId 17062: Connected Storage daemon at 
> backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:03 dziura-fd JobId 17062:  Encryption: 
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:05 bareos-sd JobId 17062: Volume "vchanger-1_0002_0042" 
> previously written, moving to end of data.
>  2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append to end of 
> Volume "vchanger-1_0002_0042" size=26886488931
>  2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS snapshots. 
> Driver="Win64 VSS"
>  2024-01-18 08:06:07 dziura-fd JobId 17062: 
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
> 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

Yes, it does seem to be working!

22-Jan 14:16 dziura-fd JobId 17111: Generate VSS snapshots. Driver="Win64 VSS"
22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as 
onefs = yes.
22-Jan 14:16 dziura-fd JobId 17111: VolumeMountpoints are not processed as 
onefs = yes.
22-Jan 14:16 dziura-fd JobId 17111: 
(S:\)\\?\Volume{260653cf-633a-4504-992e-f82620702a9e}\ -> 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy31
22-Jan 14:16 dziura-fd JobId 17111: 
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy30
[...]
  Non-fatal FD errors:0
  SD Errors:  0
  FD termination status:  OK
  SD termination status:  OK

*status client=dziura-fd
[...]
dziura-fd Version: 24.0.0~pre187.8e12c147a (22 January 2024)  VSS Microsoft 
Windows 8 Professional (build 9200), 64-bit

Thank you!

MK

On 22.01.2024 09:42, Sebastian Sura wrote:


We managed to reproduce the issue.  As you already noted, the cause 
was the "connection from client to director" option.


This was fixed by https://github.com/bareos/bareos/pull/1665

The current next release ( https://download.bareos.org/next/ ) already 
contains the fix.   Let me know if you tried that version and the 
issue still persists!


Sincerly

Sebastian Sura

Am 18.01.24 um 19:53 schrieb Joshua Myles:
Interesting. We have a mix of client-initiated and not, and at a 
glance it looks like the only jobs that ever have warnings ("ERR=The 
process cannot access the file because it is being used by another 
process.") are the ones from clients with "Connection From Client To 
Director = yes". Seems like maybe there's a different code path used 
when that's enabled, and it hits a bug. Unfortunately we can't switch 
away from client-initiated for these, we've just been living with the 
warnings.


Josh

On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj wrote:

Yes. It does seem to be the cause.

I switched the client connectivity to the "normal" mode (director
to client) and the job completed OK and I had no problems
accessing the registry file.

MK

On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via bareos-users
wrote:

Coindidence or not, we also use Connection From Client to
Director=yes

Coindidence or not,  Another host which does not have this
setting, has 0 errors!

On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj wrote:

Hi Sebastian.

Thx for looking into it. This is the job log. Not much
interesting stuff in there.

The same thing (the jobid being zero in the trace log) was
in the previous trace I attached excerpt from few days ago.
But that one was from a different machine. That was a clean
win10 installation just for testing the FD, this one is my
production setup. Anyway, one thing that can be relatively
uncommon (but I don't see why it should affect anything
about the job itself) is that I use passive clients
(Connection From Client to Director=yes, Heartbeat Interval=60).

MK

*list joblog jobid=17062
Automatically selected Catalog: PgCatalog
Using Catalog "PgCatalog"
 2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup
JobId 17062, Job=win10test-fd.2024-01-18_08.06.02_12
 2024-01-18 08:06:04 backup1-dir JobId 17062: Connected
Storage daemon at backup1.local:9103, encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client
Initiated Connection (dziura-fd).
 2024-01-18 08:06:04 backup1-dir JobId 17062: Handshake:
Immediate TLS
 2024-01-18 08:06:04 backup1-dir JobId 17062: Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device
"vchanger-1-0" to write.
 2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27
wildcard excludes from FilesNotToBackup Registry key
 2024-01-18 08:06:03 dziura-fd JobId 17062: Connected
Storage daemon at backup1.local:9103, encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:03 dziura-fd JobId 17062: Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:05 bareos-sd JobId 17062: Volume
"vchanger-1_0002_0042" previously written, moving to end of
data.
 2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append
to end of Volume "vchanger-1_0002_0042" size=26886488931
 2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS
snapshots. Driver="Win64 VSS"
 2024-01-18 08:06:07 dziura-fd JobId 17062:
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Sebastian Sura]

We managed to reproduce the issue.  As you already noted, the cause was 
the "connection from client to director" option.


This was fixed by https://github.com/bareos/bareos/pull/1665

The current next release ( https://download.bareos.org/next/ ) already 
contains the fix.   Let me know if you tried that version and the issue 
still persists!


Sincerly

Sebastian Sura

Am 18.01.24 um 19:53 schrieb Joshua Myles:
Interesting. We have a mix of client-initiated and not, and at a 
glance it looks like the only jobs that ever have warnings ("ERR=The 
process cannot access the file because it is being used by another 
process.") are the ones from clients with "Connection From Client To 
Director = yes". Seems like maybe there's a different code path used 
when that's enabled, and it hits a bug. Unfortunately we can't switch 
away from client-initiated for these, we've just been living with the 
warnings.


Josh

On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj wrote:

Yes. It does seem to be the cause.

I switched the client connectivity to the "normal" mode (director
to client) and the job completed OK and I had no problems
accessing the registry file.

MK

On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via bareos-users
wrote:

Coindidence or not, we also use Connection From Client to
Director=yes

Coindidence or not,  Another host which does not have this
setting, has 0 errors!

On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj wrote:

Hi Sebastian.

Thx for looking into it. This is the job log. Not much
interesting stuff in there.

The same thing (the jobid being zero in the trace log) was in
the previous trace I attached excerpt from few days ago. But
that one was from a different machine. That was a clean win10
installation just for testing the FD, this one is my
production setup. Anyway, one thing that can be relatively
uncommon (but I don't see why it should affect anything about
the job itself) is that I use passive clients (Connection
From Client to Director=yes, Heartbeat Interval=60).

MK

*list joblog jobid=17062
Automatically selected Catalog: PgCatalog
Using Catalog "PgCatalog"
 2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup
JobId 17062, Job=win10test-fd.2024-01-18_08.06.02_12
 2024-01-18 08:06:04 backup1-dir JobId 17062: Connected
Storage daemon at backup1.local:9103, encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client
Initiated Connection (dziura-fd).
 2024-01-18 08:06:04 backup1-dir JobId 17062: Handshake:
Immediate TLS
 2024-01-18 08:06:04 backup1-dir JobId 17062: Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device
"vchanger-1-0" to write.
 2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27
wildcard excludes from FilesNotToBackup Registry key
 2024-01-18 08:06:03 dziura-fd JobId 17062: Connected Storage
daemon at backup1.local:9103, encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:03 dziura-fd JobId 17062: Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:05 bareos-sd JobId 17062: Volume
"vchanger-1_0002_0042" previously written, moving to end of data.
 2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append
to end of Volume "vchanger-1_0002_0042" size=26886488931
 2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS
snapshots. Driver="Win64 VSS"
 2024-01-18 08:06:07 dziura-fd JobId 17062:
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
 2024-01-18 08:06:07 dziura-fd JobId 17062: Cannot open
"C:/windows/system32/config/DEFAULT": ERR=The process cannot
access the file because it is being used by another process.
.
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "Task Scheduler Writer", State: 0x1
(VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "VSS Metadata Store Writer", State: 0x1
(VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "Performance Counters Writer", State: 0x1
(VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "System Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "ASR Writer", State: 0x1 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Joshua Myles]

Interesting. We have a mix of client-initiated and not, and at a glance it 
looks like the only jobs that ever have warnings ("ERR=The process cannot 
access the file because it is being used by another process.") are the ones 
from clients with "Connection From Client To Director = yes". Seems like 
maybe there's a different code path used when that's enabled, and it hits a 
bug. Unfortunately we can't switch away from client-initiated for these, 
we've just been living with the warnings.

Josh

On Thursday, January 18, 2024 at 4:10:27 AM UTC-5 Spadajspadaj wrote:

Yes. It does seem to be the cause.

I switched the client connectivity to the "normal" mode (director to 
client) and the job completed OK and I had no problems accessing the 
registry file.

MK
On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via bareos-users wrote:

Coindidence or not, we also use  Connection From Client to Director=yes 

Coindidence or not,  Another host which does not have this setting, has 0 
errors!

On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj wrote:

Hi Sebastian.

Thx for looking into it. This is the job log. Not much interesting stuff in 
there.

The same thing (the jobid being zero in the trace log) was in the previous 
trace I attached excerpt from few days ago. But that one was from a 
different machine. That was a clean win10 installation just for testing the 
FD, this one is my production setup. Anyway, one thing that can be 
relatively uncommon (but I don't see why it should affect anything about 
the job itself) is that I use passive clients (Connection From Client to 
Director=yes, Heartbeat Interval=60).

MK

*list joblog jobid=17062
Automatically selected Catalog: PgCatalog
Using Catalog "PgCatalog"
 2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup JobId 17062, 
Job=win10test-fd.2024-01-18_08.06.02_12
 2024-01-18 08:06:04 backup1-dir JobId 17062: Connected Storage daemon at 
backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client Initiated 
Connection (dziura-fd).
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Handshake: Immediate TLS 
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device "vchanger-1-0" 
to write.
 2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27 wildcard excludes 
from FilesNotToBackup Registry key
 2024-01-18 08:06:03 dziura-fd JobId 17062: Connected Storage daemon at 
backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:03 dziura-fd JobId 17062:  Encryption: 
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:05 bareos-sd JobId 17062: Volume "vchanger-1_0002_0042" 
previously written, moving to end of data.
 2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append to end of 
Volume "vchanger-1_0002_0042" size=26886488931
 2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS snapshots. 
Driver="Win64 VSS"
 2024-01-18 08:06:07 dziura-fd JobId 17062: 
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
 2024-01-18 08:06:07 dziura-fd JobId 17062:  Cannot open 
"C:/windows/system32/config/DEFAULT": ERR=The process cannot access the 
file because it is being used by another process.
.
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"Task Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"VSS Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"System Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"ASR Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"Registry Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"Shadow Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"WMI Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"BITS Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
"COM+ REGDB Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:09 bareos-sd JobId 17062: Releasing device "vchanger-1-0" 
(/var/spool/vchanger/vchanger-1/0).
 2024-01-18 08:06:09 bareos-sd JobId 17062: Elapsed time=00:00:04, Transfer 
rate=158  Bytes/second
 2024-01-18 08:06:09 backup1-dir JobId 17062: Insert of attributes batch 
table with 1 entries start
 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

Yes. It does seem to be the cause.

I switched the client connectivity to the "normal" mode (director to 
client) and the job completed OK and I had no problems accessing the 
registry file.


MK

On 18.01.2024 09:36, 'jo.go...@hosted-power.com' via bareos-users wrote:

Coindidence or not, we also use Connection From Client to Director=yes

Coindidence or not,  Another host which does not have this setting, 
has 0 errors!


On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj wrote:

Hi Sebastian.

Thx for looking into it. This is the job log. Not much interesting
stuff in there.

The same thing (the jobid being zero in the trace log) was in the
previous trace I attached excerpt from few days ago. But that one
was from a different machine. That was a clean win10 installation
just for testing the FD, this one is my production setup. Anyway,
one thing that can be relatively uncommon (but I don't see why it
should affect anything about the job itself) is that I use passive
clients (Connection From Client to Director=yes, Heartbeat
Interval=60).

MK

*list joblog jobid=17062
Automatically selected Catalog: PgCatalog
Using Catalog "PgCatalog"
 2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup JobId
17062, Job=win10test-fd.2024-01-18_08.06.02_12
 2024-01-18 08:06:04 backup1-dir JobId 17062: Connected Storage
daemon at backup1.local:9103, encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client
Initiated Connection (dziura-fd).
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Handshake:
Immediate TLS
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device
"vchanger-1-0" to write.
 2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27 wildcard
excludes from FilesNotToBackup Registry key
 2024-01-18 08:06:03 dziura-fd JobId 17062: Connected Storage
daemon at backup1.local:9103, encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:03 dziura-fd JobId 17062:  Encryption:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:05 bareos-sd JobId 17062: Volume
"vchanger-1_0002_0042" previously written, moving to end of data.
 2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append to end
of Volume "vchanger-1_0002_0042" size=26886488931
 2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS
snapshots. Driver="Win64 VSS"
 2024-01-18 08:06:07 dziura-fd JobId 17062:
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ ->
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
 2024-01-18 08:06:07 dziura-fd JobId 17062:  Cannot open
"C:/windows/system32/config/DEFAULT": ERR=The process cannot
access the file because it is being used by another process.
.
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "Task Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "VSS Metadata Store Writer", State: 0x1
(VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "Performance Counters Writer", State: 0x1
(VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "System Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "ASR Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "Registry Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "Shadow Copy Optimization Writer", State: 0x1
(VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "WMI Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "BITS Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer
(BackupComplete): "COM+ REGDB Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:09 bareos-sd JobId 17062: Releasing device
"vchanger-1-0" (/var/spool/vchanger/vchanger-1/0).
 2024-01-18 08:06:09 bareos-sd JobId 17062: Elapsed time=00:00:04,
Transfer rate=158  Bytes/second
 2024-01-18 08:06:09 backup1-dir JobId 17062: Insert of attributes
batch table with 1 entries start
 2024-01-18 08:06:09 backup1-dir JobId 17062: Insert of attributes
batch table done
 2024-01-18 08:06:09 backup1-dir JobId 17062: Bareos backup1-dir
24.0.0~pre154.115b3ebca (08Jan24):
  Build OS:   Red Hat Enterprise Linux release 8.7 (Ootpa)
  JobId:  

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

['jo.go...@hosted-power.com' via bareos-users]

Coindidence or not, we also use  Connection From Client to Director=yes

Coindidence or not,  Another host which does not have this setting, has 0 
errors!

On Thursday 18 January 2024 at 09:14:17 UTC+1 Spadajspadaj wrote:

> Hi Sebastian.
>
> Thx for looking into it. This is the job log. Not much interesting stuff 
> in there.
>
> The same thing (the jobid being zero in the trace log) was in the previous 
> trace I attached excerpt from few days ago. But that one was from a 
> different machine. That was a clean win10 installation just for testing the 
> FD, this one is my production setup. Anyway, one thing that can be 
> relatively uncommon (but I don't see why it should affect anything about 
> the job itself) is that I use passive clients (Connection From Client to 
> Director=yes, Heartbeat Interval=60).
>
> MK
>
> *list joblog jobid=17062
> Automatically selected Catalog: PgCatalog
> Using Catalog "PgCatalog"
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup JobId 17062, 
> Job=win10test-fd.2024-01-18_08.06.02_12
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Connected Storage daemon at 
> backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client Initiated 
> Connection (dziura-fd).
>  2024-01-18 08:06:04 backup1-dir JobId 17062:  Handshake: Immediate TLS 
>  2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device "vchanger-1-0" 
> to write.
>  2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27 wildcard excludes 
> from FilesNotToBackup Registry key
>  2024-01-18 08:06:03 dziura-fd JobId 17062: Connected Storage daemon at 
> backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:03 dziura-fd JobId 17062:  Encryption: 
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
>  2024-01-18 08:06:05 bareos-sd JobId 17062: Volume "vchanger-1_0002_0042" 
> previously written, moving to end of data.
>  2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append to end of 
> Volume "vchanger-1_0002_0042" size=26886488931
>  2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS snapshots. 
> Driver="Win64 VSS"
>  2024-01-18 08:06:07 dziura-fd JobId 17062: 
> (C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
> \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
>  2024-01-18 08:06:07 dziura-fd JobId 17062:  Cannot open 
> "C:/windows/system32/config/DEFAULT": ERR=The process cannot access the 
> file because it is being used by another process.
> .
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "Task Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "VSS Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "System Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "ASR Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "Registry Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "Shadow Copy Optimization Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "WMI Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "BITS Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer (BackupComplete): 
> "COM+ REGDB Writer", State: 0x1 (VSS_WS_STABLE)
>  2024-01-18 08:06:09 bareos-sd JobId 17062: Releasing device 
> "vchanger-1-0" (/var/spool/vchanger/vchanger-1/0).
>  2024-01-18 08:06:09 bareos-sd JobId 17062: Elapsed time=00:00:04, 
> Transfer rate=158  Bytes/second
>  2024-01-18 08:06:09 backup1-dir JobId 17062: Insert of attributes batch 
> table with 1 entries start
>  2024-01-18 08:06:09 backup1-dir JobId 17062: Insert of attributes batch 
> table done
>  2024-01-18 08:06:09 backup1-dir JobId 17062: Bareos backup1-dir 
> 24.0.0~pre154.115b3ebca (08Jan24):
>   Build OS:   Red Hat Enterprise Linux release 8.7 (Ootpa)
>   JobId:  17062
>   Job:win10test-fd.2024-01-18_08.06.02_12
>   Backup Level:   Full
>   Client: "dziura-fd" 23.0.1~pre57.8e89bfe0a (16Jan24) 
> Microsoft Windows 8 Professional (build 9200), 64-bit,Cross-compile
>   FileSet:"Windows_test" 2024-01-18 08:06:02
>   Pool:   "Offsite-eSATA" (From Job resource)
>   Catalog:   

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

Hi Sebastian.

Thx for looking into it. This is the job log. Not much interesting stuff 
in there.


The same thing (the jobid being zero in the trace log) was in the 
previous trace I attached excerpt from few days ago. But that one was 
from a different machine. That was a clean win10 installation just for 
testing the FD, this one is my production setup. Anyway, one thing that 
can be relatively uncommon (but I don't see why it should affect 
anything about the job itself) is that I use passive clients (Connection 

From Client to Director=yes, Heartbeat Interval=60).


MK

*list joblog jobid=17062
Automatically selected Catalog: PgCatalog
Using Catalog "PgCatalog"
 2024-01-18 08:06:04 backup1-dir JobId 17062: Start Backup JobId 17062, 
Job=win10test-fd.2024-01-18_08.06.02_12
 2024-01-18 08:06:04 backup1-dir JobId 17062: Connected Storage daemon 
at backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Client Initiated 
Connection (dziura-fd).

 2024-01-18 08:06:04 backup1-dir JobId 17062:  Handshake: Immediate TLS
 2024-01-18 08:06:04 backup1-dir JobId 17062:  Encryption: 
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:04 backup1-dir JobId 17062: Using Device 
"vchanger-1-0" to write.
 2024-01-18 08:06:03 dziura-fd JobId 17062: Created 27 wildcard 
excludes from FilesNotToBackup Registry key
 2024-01-18 08:06:03 dziura-fd JobId 17062: Connected Storage daemon at 
backup1.local:9103, encryption: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:03 dziura-fd JobId 17062:  Encryption: 
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
 2024-01-18 08:06:05 bareos-sd JobId 17062: Volume 
"vchanger-1_0002_0042" previously written, moving to end of data.
 2024-01-18 08:06:05 bareos-sd JobId 17062: Ready to append to end of 
Volume "vchanger-1_0002_0042" size=26886488931
 2024-01-18 08:06:05 dziura-fd JobId 17062: Generate VSS snapshots. 
Driver="Win64 VSS"
 2024-01-18 08:06:07 dziura-fd JobId 17062: 
(C:\)\\?\Volume{7730df77-9bec-432c-a00a-597b4bf1a6f6}\ -> 
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy16
 2024-01-18 08:06:07 dziura-fd JobId 17062:  Cannot open 
"C:/windows/system32/config/DEFAULT": ERR=The process cannot access the 
file because it is being used by another process.

.
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "Task Scheduler Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "VSS Metadata Store Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "Performance Counters Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "System Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "ASR Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "Registry Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "Shadow Copy Optimization Writer", State: 0x1 
(VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "WMI Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "BITS Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:08 dziura-fd JobId 17062: VSS Writer 
(BackupComplete): "COM+ REGDB Writer", State: 0x1 (VSS_WS_STABLE)
 2024-01-18 08:06:09 bareos-sd JobId 17062: Releasing device 
"vchanger-1-0" (/var/spool/vchanger/vchanger-1/0).
 2024-01-18 08:06:09 bareos-sd JobId 17062: Elapsed time=00:00:04, 
Transfer rate=158  Bytes/second
 2024-01-18 08:06:09 backup1-dir JobId 17062: Insert of attributes 
batch table with 1 entries start
 2024-01-18 08:06:09 backup1-dir JobId 17062: Insert of attributes 
batch table done
 2024-01-18 08:06:09 backup1-dir JobId 17062: Bareos backup1-dir 
24.0.0~pre154.115b3ebca (08Jan24):

  Build OS:   Red Hat Enterprise Linux release 8.7 (Ootpa)
  JobId:  17062
  Job:    win10test-fd.2024-01-18_08.06.02_12
  Backup Level:   Full
  Client: "dziura-fd" 23.0.1~pre57.8e89bfe0a (16Jan24) 
Microsoft Windows 8 Professional (build 9200), 64-bit,Cross-compile

  FileSet:    "Windows_test" 2024-01-18 08:06:02
  Pool:   "Offsite-eSATA" (From Job resource)
  Catalog:    "PgCatalog" (From Client resource)
  Storage:    "vchanger-1-changer" (From Pool resource)
  Scheduled time: 18-Jan-2024 08:06:01
  Start time: 18-Jan-2024 08:06:04
  End time:   18-Jan-2024 08:06:09
  Elapsed time:   5 secs
  Priority:   10
  Allow Mixed Priority:   no
  FD Files Written:   2
  SD Files Written:   

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Sebastian Sura]

Hi Spadajspadaj,

something is wrong with your debug output but im not sure why. Debug 
messages are normally formatted as


daemon-name (level):file:line-jobid

For some reason your jobid is 0 (which often means it could not be 
determined) here.
This should normally not happen and might be why the vss name 
translation does not work for you.


I tried reproducing the problem you described with your fileset, but it 
just works for me.
Would it be possible for you to also submit the joblog for that 
particular job ?

You can retrieve it using "list joblog jobid=17062".

Sincerely
Sebastian Sura

Am 18.01.24 um 08:13 schrieb Spadajspadaj:

FileSet {
  Name = "Windows_test"
  Enable VSS = yes
  Include {
    File = "C:/windows/system32/config/DEFAULT"
    Options {
   onefs = no
   Signature = MD5
   IgnoreCase = yes
   Portable = no
    }
  }
}


--
 Sebastian surasebastian.s...@bareos.com
 Bareos GmbH & Co. KGPhone: +49 221 630693-0
 https://www.bareos.comFax:   +49 221 630693-10

 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
 Komplementär: Bareos Verwaltungs-GmbH
 Geschäftsführer: Stephan Dühr, Jörg Steffens, Philipp Storz

--
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/1154382e-9d9f-4252-bd16-92284ba6e010%40bareos.com.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

OK. I had a few spare minutes. I did upgrade to the pre57 release I 
downloaded today from https://download.bareos.org/current/windows/


The fileset is very simple so that the job is quick and short. It 
consists of just one file from the windows registry (so that it will be 
open for sure).



FileSet {
  Name = "Windows_test"
  Enable VSS = yes
  Include {
    File = "C:/windows/system32/config/DEFAULT"
    Options {
   onefs = no
   Signature = MD5
   IgnoreCase = yes
   Portable = no
    }
  }
}

(I tried with both Portable=no as well as Portable=yes as I found some 
info that it may change backup job behaviour but there was no 
difference. onefs option is just a remnant from older test jobs, I 
assume it should have no impact here as we're only targeting a single file).


Attaching the trace from the FD. It's the same as before - the snapshot 
is being created but the filename is not being converted for read in the 
end even though the snapshot is there.


MK

On 17.01.2024 10:12, Bruno Friedmann (bruno-at-bareos) wrote:


Please, may I ask you to either provided the trace and job log as 
requested.

As I can argue that we are using 2019 to 2022 with 0% of your troubles

That kind of guerilla can be endless.

If we have traces, joblog fileset etc we may have a chance to reproduce.
If it is reproducible, then there's a chance to have a fix.
If we can elaborate that fix, you may have a chance to solve your trouble.


Le mercredi 17 janvier 2024 à 09:58:19 UTC+1, 
jo.go...@hosted-power.com a écrit :


I just tried

https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe
on Windows 2022. But I still have 100's of failed in use files :/

On Wednesday 17 January 2024 at 09:49:10 UTC+1 Spadajspadaj wrote:

Hi Bruno.

Yes, I understand how it's supposed to work. :-)

OK, I will re-run the tests when I have a spare minute and
dump the trace somewhere (the excerpt I posted earlier was
with debug level 999 so all messages should have been captured).

And it's not that I _thought_ it wasn't backed up. I know it
wasn't backed up. It was throwing errors of being unable to
access the file and if I wanted to restore the files I got a
zero-length content. I know it should have been converted to
the shadowcopy-based filename but wasn't.

I'll check the latest package version first though.

MK

On 17.01.2024 09:43, Bruno Friedmann (bruno-at-bareos) wrote:

To add an illustration to the fact that BareOS works as
documented and expected.
We run a backup job while the registry hive is open in
regedit and we tried to remove it so you get the expected
error, the file is in use.

In the background you can see the success of the job backing
up that file without any error.
See the details about the status of VSS BackupComplete.

thumb-Screenshots_43.png

Le mercredi 17 janvier 2024 à 09:34:37 UTC+1, Bruno Friedmann
(bruno-at-bareos) a écrit :

Hi Spadapjspadaj,

When we examine what happen on test machine here we see
it working correctly.
Especially that the VSS is present.

you may think we don't backup the snapshot due to the
presence of *C:/Users/user/NTUSER.dat* in the log, but
you need to understand that is the resulting file name
after its conversion incompact.cc
compat/compat.cc:555-307 Leave

make_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\user\NTUSER.datcompat/compat.cc:1609-307
sizino=8 ino=0 filename=C:/Users/user/NTUSER.dat
desktop-vcf7e32-fd (300): findlib/find_one.cc:911-307
File : C:/Users/user/NTUSER.dat desktop-vcf7e32-fd
(130): filed/backup.cc:535-307 FT_REG saving:
C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (130):
filed/backup.cc:646-307 filed: sending
C:/Users/user/NTUSER.dat to stored
So to be sure we use the same code, could you please
install and run the following bareos-fd

https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe

In your director you set the debug level to 500 for that
client (changing the client name in the following example)

setdebug level=500 trace=1 timestamp=1 client=windows-fd

this will indicate where the tracelog will be written
(often directly on C:\)
run one backup job then disable the debugging,
To extract in text mode the joblog in bconsole
@out /tmp/backup-win-fd.joblog
list joblog jobid=X
q

Then you can zip and attach both trace and joblog here.
 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Bruno Friedmann (bruno-at-bareos)]

Please, may I ask you to either provided the trace and job log as requested.
As I can argue that we are using 2019 to 2022 with 0% of your troubles

That kind of guerilla can be endless.

If we have traces, joblog fileset etc we may have a chance to reproduce.
If it is reproducible, then there's a chance to have a fix.
If we can elaborate that fix, you may have a chance to solve your trouble.


Le mercredi 17 janvier 2024 à 09:58:19 UTC+1, jo.go...@hosted-power.com a 
écrit :

> I just tried 
> https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe
>  
> on Windows 2022. But I still have 100's of failed in use files :/
>
> On Wednesday 17 January 2024 at 09:49:10 UTC+1 Spadajspadaj wrote:
>
>> Hi Bruno.
>>
>> Yes, I understand how it's supposed to work. :-)
>>
>> OK, I will re-run the tests when I have a spare minute and dump the trace 
>> somewhere (the excerpt I posted earlier was with debug level 999 so all 
>> messages should have been captured).
>>
>> And it's not that I _thought_ it wasn't backed up. I know it wasn't 
>> backed up. It was throwing errors of being unable to access the file and if 
>> I wanted to restore the files I got a zero-length content. I know it should 
>> have been converted to the shadowcopy-based filename but wasn't.
>>
>> I'll check the latest package version first though.
>>
>> MK
>> On 17.01.2024 09:43, Bruno Friedmann (bruno-at-bareos) wrote:
>>
>> To add an illustration to the fact that BareOS works as documented and 
>> expected. 
>> We run a backup job while the registry hive is open in regedit and we 
>> tried to remove it so you get the expected error, the file is in use.
>>
>> In the background you can see the success of the job backing up that file 
>> without any error.
>> See the details about the status of VSS BackupComplete.
>>
>> [image: thumb-Screenshots_43.png]
>>
>> Le mercredi 17 janvier 2024 à 09:34:37 UTC+1, Bruno Friedmann 
>> (bruno-at-bareos) a écrit :
>>
>>> Hi Spadapjspadaj, 
>>>
>>> When we examine what happen on test machine here we see it working 
>>> correctly.
>>> Especially that the VSS is present.
>>>
>>> you may think we don't backup the snapshot due to the presence of 
>>> *C:/Users/user/NTUSER.dat* in the log, but you need to understand that 
>>> is the resulting file name after its conversion in compact.cc
>>> compat/compat.cc:555-307 Leave 
>>> make_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\user\NTUSER.dat
>>> compat/compat.cc:1609-307 sizino=8 ino=0 filename=C:/Users/user/NTUSER.dat 
>>> desktop-vcf7e32-fd (300): findlib/find_one.cc:911-307 File : C:/
>>> Users/user/NTUSER.dat desktop-vcf7e32-fd (130): filed/backup.cc:535-307 
>>> FT_REG saving: C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (130): 
>>> filed/backup.cc:646-307 
>>> filed: sending C:/Users/user/NTUSER.dat to stored
>>> So to be sure we use the same code, could you please install and run the 
>>> following bareos-fd
>>>
>>> https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe
>>>
>>> In your director you set the debug level to 500 for that client 
>>> (changing the client name in the following example)
>>>
>>> setdebug level=500 trace=1 timestamp=1 client=windows-fd
>>>
>>> this will indicate where the tracelog will be written (often directly on 
>>> C:\)
>>> run one backup job then disable the debugging,
>>> To extract in text mode the joblog in bconsole
>>> @out /tmp/backup-win-fd.joblog
>>> list joblog jobid=X
>>> q
>>>
>>> Then you can zip and attach both trace and joblog here.
>>> Add the fileset used too.
>>>
>>> BTW please ensure your fileset contain 
>>>   Enable VSS = yes
>>> as stated in documentation and Windows fileset example.
>>>
>>> Le mardi 16 janvier 2024 à 15:38:37 UTC+1, Spadajspadaj a écrit :
>>>
>>> I used the relatively new available client. (23-pre-something, 
>>> downloaded around 2 weeks ago). Yes, I should have written that explicitly.
>>> On 16.01.2024 15:23, Bruno Friedmann (bruno-at-bareos) wrote:
>>>
>>> Hello, all normally the issues that are described here, should have been 
>>> already fixed, and should work without any trouble with bareos >= 23 
>>>
>>> The code fixing the problem has been submitted and merge a certain time 
>>> ago with PR1452
>>> https://github.com/bareos/bareos/pull/1452
>>>
>>> Please refresh your installation, and of course report success and 
>>> failures.
>>>
>>> Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit :
>>>
>>> As I understand, this is the interesting excerpt from the debug trace.
>>>
>>> win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
>>> BaseJob= flags=<724185736>
>>> win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
>>> BaseJob= flags=<724185736>
>>> win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT
>>> win10test-fd (500): compat/compat.cc:278-0 Enter 
>>> convert_unix_to_win32_path
>>> win10test-fd (500): compat/compat.cc:322-0 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

['jo.go...@hosted-power.com' via bareos-users]

I just 
tried 
https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe
 
on Windows 2022. But I still have 100's of failed in use files :/

On Wednesday 17 January 2024 at 09:49:10 UTC+1 Spadajspadaj wrote:

> Hi Bruno.
>
> Yes, I understand how it's supposed to work. :-)
>
> OK, I will re-run the tests when I have a spare minute and dump the trace 
> somewhere (the excerpt I posted earlier was with debug level 999 so all 
> messages should have been captured).
>
> And it's not that I _thought_ it wasn't backed up. I know it wasn't backed 
> up. It was throwing errors of being unable to access the file and if I 
> wanted to restore the files I got a zero-length content. I know it should 
> have been converted to the shadowcopy-based filename but wasn't.
>
> I'll check the latest package version first though.
>
> MK
> On 17.01.2024 09:43, Bruno Friedmann (bruno-at-bareos) wrote:
>
> To add an illustration to the fact that BareOS works as documented and 
> expected. 
> We run a backup job while the registry hive is open in regedit and we 
> tried to remove it so you get the expected error, the file is in use.
>
> In the background you can see the success of the job backing up that file 
> without any error.
> See the details about the status of VSS BackupComplete.
>
> [image: thumb-Screenshots_43.png]
>
> Le mercredi 17 janvier 2024 à 09:34:37 UTC+1, Bruno Friedmann 
> (bruno-at-bareos) a écrit :
>
>> Hi Spadapjspadaj, 
>>
>> When we examine what happen on test machine here we see it working 
>> correctly.
>> Especially that the VSS is present.
>>
>> you may think we don't backup the snapshot due to the presence of 
>> *C:/Users/user/NTUSER.dat* in the log, but you need to understand that 
>> is the resulting file name after its conversion in compact.cc
>> compat/compat.cc:555-307 Leave 
>> make_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\user\NTUSER.dat
>> compat/compat.cc:1609-307 sizino=8 ino=0 filename=C:/Users/user/NTUSER.dat 
>> desktop-vcf7e32-fd (300): findlib/find_one.cc:911-307 File : C:/Users
>> /user/NTUSER.dat desktop-vcf7e32-fd (130): filed/backup.cc:535-307 
>> FT_REG saving: C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (130): 
>> filed/backup.cc:646-307 
>> filed: sending C:/Users/user/NTUSER.dat to stored
>> So to be sure we use the same code, could you please install and run the 
>> following bareos-fd
>>
>> https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe
>>
>> In your director you set the debug level to 500 for that client (changing 
>> the client name in the following example)
>>
>> setdebug level=500 trace=1 timestamp=1 client=windows-fd
>>
>> this will indicate where the tracelog will be written (often directly on 
>> C:\)
>> run one backup job then disable the debugging,
>> To extract in text mode the joblog in bconsole
>> @out /tmp/backup-win-fd.joblog
>> list joblog jobid=X
>> q
>>
>> Then you can zip and attach both trace and joblog here.
>> Add the fileset used too.
>>
>> BTW please ensure your fileset contain 
>>   Enable VSS = yes
>> as stated in documentation and Windows fileset example.
>>
>> Le mardi 16 janvier 2024 à 15:38:37 UTC+1, Spadajspadaj a écrit :
>>
>> I used the relatively new available client. (23-pre-something, downloaded 
>> around 2 weeks ago). Yes, I should have written that explicitly.
>> On 16.01.2024 15:23, Bruno Friedmann (bruno-at-bareos) wrote:
>>
>> Hello, all normally the issues that are described here, should have been 
>> already fixed, and should work without any trouble with bareos >= 23 
>>
>> The code fixing the problem has been submitted and merge a certain time 
>> ago with PR1452
>> https://github.com/bareos/bareos/pull/1452
>>
>> Please refresh your installation, and of course report success and 
>> failures.
>>
>> Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit :
>>
>> As I understand, this is the interesting excerpt from the debug trace.
>>
>> win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
>> BaseJob= flags=<724185736>
>> win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
>> BaseJob= flags=<724185736>
>> win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT
>> win10test-fd (500): compat/compat.cc:278-0 Enter 
>> convert_unix_to_win32_path
>> win10test-fd (500): compat/compat.cc:322-0 path = 
>> \\?\C:\Users\test\NTUSER.DAT
>> win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path 
>> path=\\?\C:\Users\test\NTUSER.DAT
>> win10test-fd (500): compat/compat.cc:234-0 Win32ConvInitCache: Setup of 
>> thread specific cache at address 1532b2b76d0
>> win10test-fd (500): compat/compat.cc:531-0 Enter make_wchar_win32_path
>> win10test-fd (500): compat/compat.cc:555-0 Leave 
>> make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT
>> win10test-fd (500): compat/compat.cc:1609-0 sizino=8 ino=0 
>> filename=C:/Users/test/NTUSER.DAT
>> win10test-fd (300): 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

Hi Bruno.

Yes, I understand how it's supposed to work. :-)

OK, I will re-run the tests when I have a spare minute and dump the 
trace somewhere (the excerpt I posted earlier was with debug level 999 
so all messages should have been captured).


And it's not that I _thought_ it wasn't backed up. I know it wasn't 
backed up. It was throwing errors of being unable to access the file and 
if I wanted to restore the files I got a zero-length content. I know it 
should have been converted to the shadowcopy-based filename but wasn't.


I'll check the latest package version first though.

MK

On 17.01.2024 09:43, Bruno Friedmann (bruno-at-bareos) wrote:
To add an illustration to the fact that BareOS works as documented and 
expected.
We run a backup job while the registry hive is open in regedit and we 
tried to remove it so you get the expected error, the file is in use.


In the background you can see the success of the job backing up that 
file without any error.

See the details about the status of VSS BackupComplete.

thumb-Screenshots_43.png

Le mercredi 17 janvier 2024 à 09:34:37 UTC+1, Bruno Friedmann 
(bruno-at-bareos) a écrit :


Hi Spadapjspadaj,

When we examine what happen on test machine here we see it working
correctly.
Especially that the VSS is present.

you may think we don't backup the snapshot due to the presence of
*C:/Users/user/NTUSER.dat* in the log, but you need to understand
that is the resulting file name after its conversion incompact.cc
compat/compat.cc:555-307 Leave

make_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\user\NTUSER.datcompat/compat.cc:1609-307
sizino=8 ino=0 filename=C:/Users/user/NTUSER.dat
desktop-vcf7e32-fd (300): findlib/find_one.cc:911-307 File :
C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (130):
filed/backup.cc:535-307 FT_REG saving: C:/Users/user/NTUSER.dat
desktop-vcf7e32-fd (130): filed/backup.cc:646-307 filed: sending
C:/Users/user/NTUSER.dat to stored
So to be sure we use the same code, could you please install and
run the following bareos-fd

https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe

In your director you set the debug level to 500 for that client
(changing the client name in the following example)

setdebug level=500 trace=1 timestamp=1 client=windows-fd

this will indicate where the tracelog will be written (often
directly on C:\)
run one backup job then disable the debugging,
To extract in text mode the joblog in bconsole
@out /tmp/backup-win-fd.joblog
list joblog jobid=X
q

Then you can zip and attach both trace and joblog here.
Add the fileset used too.

BTW please ensure your fileset contain
  Enable VSS = yes
as stated in documentation and Windows fileset example.

Le mardi 16 janvier 2024 à 15:38:37 UTC+1, Spadajspadaj a écrit :

I used the relatively new available client. (23-pre-something,
downloaded around 2 weeks ago). Yes, I should have written
that explicitly.

On 16.01.2024 15:23, Bruno Friedmann (bruno-at-bareos) wrote:

Hello, all normally the issues that are described here,
should have been already fixed, and should work without any
trouble with bareos >= 23

The code fixing the problem has been submitted and merge a
certain time ago with PR1452
https://github.com/bareos/bareos/pull/1452

Please refresh your installation, and of course report
success and failures.

Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit :

As I understand, this is the interesting excerpt from the
debug trace.

win10test-fd (50): findlib/find.cc:169-0 Verify=
Accurate= BaseJob= flags=<724185736>
win10test-fd (50): findlib/find.cc:169-0 Verify=
Accurate= BaseJob= flags=<724185736>
win10test-fd (450): findlib/find.cc:175-0 F
C:/Users/test/NTUSER.DAT
win10test-fd (500): compat/compat.cc:278-0 Enter
convert_unix_to_win32_path
win10test-fd (500): compat/compat.cc:322-0 path =
\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:328-0 Leave
cvt_u_to_win32_path path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:234-0
Win32ConvInitCache: Setup of thread specific cache at
address 1532b2b76d0
win10test-fd (500): compat/compat.cc:531-0 Enter
make_wchar_win32_path
win10test-fd (500): compat/compat.cc:555-0 Leave
make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:1609-0 sizino=8
ino=0 filename=C:/Users/test/NTUSER.DAT
win10test-fd (300): findlib/find_one.cc:911-0 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Bruno Friedmann (bruno-at-bareos)]

Hi Spadapjspadaj,

When we examine what happen on test machine here we see it working 
correctly.
Especially that the VSS is present.

you may think we don't backup the snapshot due to the presence of 
*C:/Users/user/NTUSER.dat* in the log, but you need to understand that is 
the resulting file name after its conversion in compact.cccompat/compat.cc:
555-307 Leave 
make_wchar_win32_path=\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\user\NTUSER.dat
compat/compat.cc:1609-307 sizino=8 ino=0 filename=C:/Users/user/NTUSER.dat 
desktop-vcf7e32-fd (300): findlib/find_one.cc:911-307 File : C:/Users
/user/NTUSER.dat desktop-vcf7e32-fd (130): filed/backup.cc:535-307 FT_REG 
saving: C:/Users/user/NTUSER.dat desktop-vcf7e32-fd (130): 
filed/backup.cc:646-307 
filed: sending C:/Users/user/NTUSER.dat to stored
So to be sure we use the same code, could you please install and run the 
following bareos-fd
https://download.bareos.org/current/windows/winbareos-23.0.1~pre57.8e89bfe0a-release-64-bit.exe

In your director you set the debug level to 500 for that client (changing 
the client name in the following example)

setdebug level=500 trace=1 timestamp=1 client=windows-fd

this will indicate where the tracelog will be written (often directly on 
C:\)
run one backup job then disable the debugging,
To extract in text mode the joblog in bconsole
@out /tmp/backup-win-fd.joblog
list joblog jobid=X
q

Then you can zip and attach both trace and joblog here.
Add the fileset used too.

BTW please ensure your fileset contain 
  Enable VSS = yes
as stated in documentation and Windows fileset example.

Le mardi 16 janvier 2024 à 15:38:37 UTC+1, Spadajspadaj a écrit :

I used the relatively new available client. (23-pre-something, downloaded 
around 2 weeks ago). Yes, I should have written that explicitly.
On 16.01.2024 15:23, Bruno Friedmann (bruno-at-bareos) wrote:

Hello, all normally the issues that are described here, should have been 
already fixed, and should work without any trouble with bareos >= 23 

The code fixing the problem has been submitted and merge a certain time ago 
with PR1452
https://github.com/bareos/bareos/pull/1452

Please refresh your installation, and of course report success and failures.

Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit :

As I understand, this is the interesting excerpt from the debug trace.

win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
BaseJob= flags=<724185736>
win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
BaseJob= flags=<724185736>
win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT
win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path
win10test-fd (500): compat/compat.cc:322-0 path = 
\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path 
path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:234-0 Win32ConvInitCache: Setup of 
thread specific cache at address 1532b2b76d0
win10test-fd (500): compat/compat.cc:531-0 Enter make_wchar_win32_path
win10test-fd (500): compat/compat.cc:555-0 Leave 
make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:1609-0 sizino=8 ino=0 
filename=C:/Users/test/NTUSER.DAT
win10test-fd (300): findlib/find_one.cc:911-0 File : 
C:/Users/test/NTUSER.DAT
win10test-fd (130): filed/backup.cc:535-0 FT_REG saving: 
C:/Users/test/NTUSER.DAT
win10test-fd (130): filed/backup.cc:646-0 filed: sending 
C:/Users/test/NTUSER.DAT to stored
win10test-fd (150): lib/crypto_openssl.cc:641-0 crypto_digest_new 
jcr=1532b228410
win10test-fd (300): filed/backup.cc:1575-0 encode_and_send_attrs 
fname=C:/Users/test/NTUSER.DAT
win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path
win10test-fd (500): compat/compat.cc:322-0 path = 
\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path 
path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (300): filed/backup.cc:1594-0 File C:/Users/test/NTUSER.DAT
attribs=A A IH/ B A A CAi FAAA A A BlnTaz BlnTaz BlnTaz A A L
attribsEx=CAi HaQkZzohoU HaQvQ8Q7yY HaQvQ8Q7yY A FAAA
win10test-fd (300): filed/backup.cc:1620-0 >stored: attrhdr 1 5 
0win10test-fd (200): filed/backup.cc:1772-0 No strip for 
C:/Users/test/NTUSER.DAT
win10test-fd (300): filed/backup.cc:1715-0 >stored: attr len=130: 1 3 
C:/Users/test/NTUSER.DAT
win10test-fd (150): filed/backup.cc:737-0 type=3 do_read=1
win10test-fd (100): findlib/bfile.cc:710-0 bopen: fname 
C:/Users/test/NTUSER.DAT, flags 0010, mode , rdev 8226
win10test-fd (50): findlib/bfile.cc:565-0 === NO plugin
win10test-fd (100): findlib/bfile.cc:664-0 Read 
CreateFileW=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (850): lib/message.cc:1216-0 Enter Jmsg type=8
win10test-fd (850): lib/message.cc:613-0 Enter DispatchMessage type=8 
msg=win10test-fd JobId 16959:  Cannot open "C:/Users/test/NTUSER.DAT": 
ERR=The process cannot access the file because it is being used 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

I used the relatively new available client. (23-pre-something, 
downloaded around 2 weeks ago). Yes, I should have written that explicitly.


On 16.01.2024 15:23, Bruno Friedmann (bruno-at-bareos) wrote:
Hello, all normally the issues that are described here, should have 
been already fixed, and should work without any trouble with bareos >= 23


The code fixing the problem has been submitted and merge a certain 
time ago with PR1452

https://github.com/bareos/bareos/pull/1452

Please refresh your installation, and of course report success and 
failures.


Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit :

As I understand, this is the interesting excerpt from the debug trace.

win10test-fd (50): findlib/find.cc:169-0 Verify=
Accurate= BaseJob= flags=<724185736>
win10test-fd (50): findlib/find.cc:169-0 Verify=
Accurate= BaseJob= flags=<724185736>
win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT
win10test-fd (500): compat/compat.cc:278-0 Enter
convert_unix_to_win32_path
win10test-fd (500): compat/compat.cc:322-0 path =
\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:328-0 Leave
cvt_u_to_win32_path path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:234-0 Win32ConvInitCache:
Setup of thread specific cache at address 1532b2b76d0
win10test-fd (500): compat/compat.cc:531-0 Enter make_wchar_win32_path
win10test-fd (500): compat/compat.cc:555-0 Leave
make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:1609-0 sizino=8 ino=0
filename=C:/Users/test/NTUSER.DAT
win10test-fd (300): findlib/find_one.cc:911-0 File :
C:/Users/test/NTUSER.DAT
win10test-fd (130): filed/backup.cc:535-0 FT_REG saving:
C:/Users/test/NTUSER.DAT
win10test-fd (130): filed/backup.cc:646-0 filed: sending
C:/Users/test/NTUSER.DAT to stored
win10test-fd (150): lib/crypto_openssl.cc:641-0 crypto_digest_new
jcr=1532b228410
win10test-fd (300): filed/backup.cc:1575-0 encode_and_send_attrs
fname=C:/Users/test/NTUSER.DAT
win10test-fd (500): compat/compat.cc:278-0 Enter
convert_unix_to_win32_path
win10test-fd (500): compat/compat.cc:322-0 path =
\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:328-0 Leave
cvt_u_to_win32_path path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (300): filed/backup.cc:1594-0 File
C:/Users/test/NTUSER.DAT
attribs=A A IH/ B A A CAi FAAA A A BlnTaz BlnTaz BlnTaz A A L
attribsEx=CAi HaQkZzohoU HaQvQ8Q7yY HaQvQ8Q7yY A FAAA
win10test-fd (300): filed/backup.cc:1620-0 >stored: attrhdr 1 5
0win10test-fd (200): filed/backup.cc:1772-0 No strip for
C:/Users/test/NTUSER.DAT
win10test-fd (300): filed/backup.cc:1715-0 >stored: attr len=130:
1 3 C:/Users/test/NTUSER.DAT
win10test-fd (150): filed/backup.cc:737-0 type=3 do_read=1
win10test-fd (100): findlib/bfile.cc:710-0 bopen: fname
C:/Users/test/NTUSER.DAT, flags 0010, mode , rdev 8226
win10test-fd (50): findlib/bfile.cc:565-0 === NO plugin
win10test-fd (100): findlib/bfile.cc:664-0 Read
CreateFileW=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (850): lib/message.cc:1216-0 Enter Jmsg type=8
win10test-fd (850): lib/message.cc:613-0 Enter DispatchMessage
type=8 msg=win10test-fd JobId 16959: Cannot open
"C:/Users/test/NTUSER.DAT": ERR=The process cannot access the file
because it is being used by another process.
.
win10test-fd (850): lib/message.cc:820-0 DIRECTOR for following
msg: win10test-fd JobId 16959:  Cannot open
"C:/Users/test/NTUSER.DAT": ERR=The process cannot access the file
because it is being used by another process.
.
win10test-fd (400): findlib/find_one.cc:493-0 FT_REG FI=1 linked=0
file=C:/Users/test/NTUSER.DAT

From what I understand from the description of the
make_wchar_win32_path() method in win32/compat/compat.cc - we
should leave the function with the filename properly converted to
VSS-based one. But apparently we're stuck with local name.

MK

On 11.01.2024 22:03, Spadajspadaj wrote:


The more I dig into it, the more it seems it is bareos after all.

Unfortunately, building Windows bareos-fd is no small feat so I
cannot directly debug it but.

I ran a procmon against bareos-fd.exe and it seems that while the
FD process does create a VSS snapshot... it doesn't read from it.
It reads the files straight from the main device. I did a small
test fileset consisting of just my user's registry file. And both
procmon's dump as well as bareos-fd own debug trace shows that
it's trying to read simply a c:\users\test\ntuser.dat instead of
properly going for
\\?\GLOBALROOT\Device\HardDiskVolumeShadowCopyXX\Users\test\ntuser.dat.
That would explain why the job even though it's supposed to use
VSS, fails on copying open files.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Bruno Friedmann (bruno-at-bareos)]

Hello, all normally the issues that are described here, should have been 
already fixed, and should work without any trouble with bareos >= 23

The code fixing the problem has been submitted and merge a certain time ago 
with PR1452
https://github.com/bareos/bareos/pull/1452

Please refresh your installation, and of course report success and failures.

Le jeudi 11 janvier 2024 à 23:17:26 UTC+1, Spadajspadaj a écrit :

> As I understand, this is the interesting excerpt from the debug trace.
>
> win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
> BaseJob= flags=<724185736>
> win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
> BaseJob= flags=<724185736>
> win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT
> win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path
> win10test-fd (500): compat/compat.cc:322-0 path = 
> \\?\C:\Users\test\NTUSER.DAT
> win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path 
> path=\\?\C:\Users\test\NTUSER.DAT
> win10test-fd (500): compat/compat.cc:234-0 Win32ConvInitCache: Setup of 
> thread specific cache at address 1532b2b76d0
> win10test-fd (500): compat/compat.cc:531-0 Enter make_wchar_win32_path
> win10test-fd (500): compat/compat.cc:555-0 Leave 
> make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT
> win10test-fd (500): compat/compat.cc:1609-0 sizino=8 ino=0 
> filename=C:/Users/test/NTUSER.DAT
> win10test-fd (300): findlib/find_one.cc:911-0 File : 
> C:/Users/test/NTUSER.DAT
> win10test-fd (130): filed/backup.cc:535-0 FT_REG saving: 
> C:/Users/test/NTUSER.DAT
> win10test-fd (130): filed/backup.cc:646-0 filed: sending 
> C:/Users/test/NTUSER.DAT to stored
> win10test-fd (150): lib/crypto_openssl.cc:641-0 crypto_digest_new 
> jcr=1532b228410
> win10test-fd (300): filed/backup.cc:1575-0 encode_and_send_attrs 
> fname=C:/Users/test/NTUSER.DAT
> win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path
> win10test-fd (500): compat/compat.cc:322-0 path = 
> \\?\C:\Users\test\NTUSER.DAT
> win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path 
> path=\\?\C:\Users\test\NTUSER.DAT
> win10test-fd (300): filed/backup.cc:1594-0 File C:/Users/test/NTUSER.DAT
> attribs=A A IH/ B A A CAi FAAA A A BlnTaz BlnTaz BlnTaz A A L
> attribsEx=CAi HaQkZzohoU HaQvQ8Q7yY HaQvQ8Q7yY A FAAA
> win10test-fd (300): filed/backup.cc:1620-0 >stored: attrhdr 1 5 
> 0win10test-fd (200): filed/backup.cc:1772-0 No strip for 
> C:/Users/test/NTUSER.DAT
> win10test-fd (300): filed/backup.cc:1715-0 >stored: attr len=130: 1 3 
> C:/Users/test/NTUSER.DAT
> win10test-fd (150): filed/backup.cc:737-0 type=3 do_read=1
> win10test-fd (100): findlib/bfile.cc:710-0 bopen: fname 
> C:/Users/test/NTUSER.DAT, flags 0010, mode , rdev 8226
> win10test-fd (50): findlib/bfile.cc:565-0 === NO plugin
> win10test-fd (100): findlib/bfile.cc:664-0 Read 
> CreateFileW=\\?\C:\Users\test\NTUSER.DAT
> win10test-fd (850): lib/message.cc:1216-0 Enter Jmsg type=8
> win10test-fd (850): lib/message.cc:613-0 Enter DispatchMessage type=8 
> msg=win10test-fd JobId 16959:  Cannot open "C:/Users/test/NTUSER.DAT": 
> ERR=The process cannot access the file because it is being used by another 
> process.
> .
> win10test-fd (850): lib/message.cc:820-0 DIRECTOR for following msg: 
> win10test-fd JobId 16959:  Cannot open "C:/Users/test/NTUSER.DAT": 
> ERR=The process cannot access the file because it is being used by another 
> process.
> .
> win10test-fd (400): findlib/find_one.cc:493-0 FT_REG FI=1 linked=0 
> file=C:/Users/test/NTUSER.DAT
>
> From what I understand from the description of the make_wchar_win32_path() 
> method in win32/compat/compat.cc - we should leave the function with the 
> filename properly converted to VSS-based one. But apparently we're stuck 
> with local name.
>
> MK
> On 11.01.2024 22:03, Spadajspadaj wrote:
>
> The more I dig into it, the more it seems it is bareos after all.
>
> Unfortunately, building Windows bareos-fd is no small feat so I cannot 
> directly debug it but.
>
> I ran a procmon against bareos-fd.exe and it seems that while the FD 
> process does create a VSS snapshot... it doesn't read from it. It reads the 
> files straight from the main device. I did a small test fileset consisting 
> of just my user's registry file. And both procmon's dump as well as 
> bareos-fd own debug trace shows that it's trying to read simply a 
> c:\users\test\ntuser.dat instead of properly going for 
> \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopyXX\Users\test\ntuser.dat. 
> That would explain why the job even though it's supposed to use VSS, fails 
> on copying open files.
>
> When I created a very small example VS project just creating a VSS 
> snapshot and copying said file out of the VSS snapshot (using the proper 
> shadow copy volume path), it works OK.
>
> MK
> On 9.01.2024 15:11, spadaj...@gmail.com wrote:
>
> OK. There is more to this than just bareos.
> 1. I used the script from this thread and it 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

As I understand, this is the interesting excerpt from the debug trace.

win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
BaseJob= flags=<724185736>
win10test-fd (50): findlib/find.cc:169-0 Verify= Accurate= 
BaseJob= flags=<724185736>

win10test-fd (450): findlib/find.cc:175-0 F C:/Users/test/NTUSER.DAT
win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path
win10test-fd (500): compat/compat.cc:322-0 path = 
\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path 
path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:234-0 Win32ConvInitCache: Setup of 
thread specific cache at address 1532b2b76d0

win10test-fd (500): compat/compat.cc:531-0 Enter make_wchar_win32_path
win10test-fd (500): compat/compat.cc:555-0 Leave 
make_wchar_win32_path=\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:1609-0 sizino=8 ino=0 
filename=C:/Users/test/NTUSER.DAT
win10test-fd (300): findlib/find_one.cc:911-0 File : 
C:/Users/test/NTUSER.DAT
win10test-fd (130): filed/backup.cc:535-0 FT_REG saving: 
C:/Users/test/NTUSER.DAT
win10test-fd (130): filed/backup.cc:646-0 filed: sending 
C:/Users/test/NTUSER.DAT to stored
win10test-fd (150): lib/crypto_openssl.cc:641-0 crypto_digest_new 
jcr=1532b228410
win10test-fd (300): filed/backup.cc:1575-0 encode_and_send_attrs 
fname=C:/Users/test/NTUSER.DAT

win10test-fd (500): compat/compat.cc:278-0 Enter convert_unix_to_win32_path
win10test-fd (500): compat/compat.cc:322-0 path = 
\\?\C:\Users\test\NTUSER.DAT
win10test-fd (500): compat/compat.cc:328-0 Leave cvt_u_to_win32_path 
path=\\?\C:\Users\test\NTUSER.DAT

win10test-fd (300): filed/backup.cc:1594-0 File C:/Users/test/NTUSER.DAT
attribs=A A IH/ B A A CAi FAAA A A BlnTaz BlnTaz BlnTaz A A L
attribsEx=CAi HaQkZzohoU HaQvQ8Q7yY HaQvQ8Q7yY A FAAA
win10test-fd (300): filed/backup.cc:1620-0 >stored: attrhdr 1 5 
0win10test-fd (200): filed/backup.cc:1772-0 No strip for 
C:/Users/test/NTUSER.DAT
win10test-fd (300): filed/backup.cc:1715-0 >stored: attr len=130: 1 3 
C:/Users/test/NTUSER.DAT

win10test-fd (150): filed/backup.cc:737-0 type=3 do_read=1
win10test-fd (100): findlib/bfile.cc:710-0 bopen: fname 
C:/Users/test/NTUSER.DAT, flags 0010, mode , rdev 8226

win10test-fd (50): findlib/bfile.cc:565-0 === NO plugin
win10test-fd (100): findlib/bfile.cc:664-0 Read 
CreateFileW=\\?\C:\Users\test\NTUSER.DAT

win10test-fd (850): lib/message.cc:1216-0 Enter Jmsg type=8
win10test-fd (850): lib/message.cc:613-0 Enter DispatchMessage type=8 
msg=win10test-fd JobId 16959:  Cannot open 
"C:/Users/test/NTUSER.DAT": ERR=The process cannot access the file 
because it is being used by another process.

.
win10test-fd (850): lib/message.cc:820-0 DIRECTOR for following msg: 
win10test-fd JobId 16959:  Cannot open "C:/Users/test/NTUSER.DAT": 
ERR=The process cannot access the file because it is being used by 
another process.

.
win10test-fd (400): findlib/find_one.cc:493-0 FT_REG FI=1 linked=0 
file=C:/Users/test/NTUSER.DAT


From what I understand from the description of the 
make_wchar_win32_path() method in win32/compat/compat.cc - we should 
leave the function with the filename properly converted to VSS-based 
one. But apparently we're stuck with local name.


MK

On 11.01.2024 22:03, Spadajspadaj wrote:


The more I dig into it, the more it seems it is bareos after all.

Unfortunately, building Windows bareos-fd is no small feat so I cannot 
directly debug it but.


I ran a procmon against bareos-fd.exe and it seems that while the FD 
process does create a VSS snapshot... it doesn't read from it. It 
reads the files straight from the main device. I did a small test 
fileset consisting of just my user's registry file. And both procmon's 
dump as well as bareos-fd own debug trace shows that it's trying to 
read simply a c:\users\test\ntuser.dat instead of properly going for 
\\?\GLOBALROOT\Device\HardDiskVolumeShadowCopyXX\Users\test\ntuser.dat. 
That would explain why the job even though it's supposed to use VSS, 
fails on copying open files.


When I created a very small example VS project just creating a VSS 
snapshot and copying said file out of the VSS snapshot (using the 
proper shadow copy volume path), it works OK.


MK

On 9.01.2024 15:11, spadaj...@gmail.com wrote:

OK. There is more to this than just bareos.
1. I used the script from this thread and it seems to be working 
relatively well for backing up (I'm yet to test the restore part ;-)) 
the disk. I don't know, however how to backup whole mountpoint. If I 
put the location of my symlink/junction/whatever that is, only the 
junction point itself gets backed up, not the contents. I can't make 
bareos descend into the mounted VSS shadow copy. I have to explicitly 
list directories (like c:/vssmount/c/users) to back them up.
2. I spent whole evening yesterday trying to get vss to work, 
regardless of bareos. I tried creating snapshots with " shadowcopy 
call create 

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Spadajspadaj]

The more I dig into it, the more it seems it is bareos after all.

Unfortunately, building Windows bareos-fd is no small feat so I cannot 
directly debug it but.


I ran a procmon against bareos-fd.exe and it seems that while the FD 
process does create a VSS snapshot... it doesn't read from it. It reads 
the files straight from the main device. I did a small test fileset 
consisting of just my user's registry file. And both procmon's dump as 
well as bareos-fd own debug trace shows that it's trying to read simply 
a c:\users\test\ntuser.dat instead of properly going for 
\\?\GLOBALROOT\Device\HardDiskVolumeShadowCopyXX\Users\test\ntuser.dat. 
That would explain why the job even though it's supposed to use VSS, 
fails on copying open files.


When I created a very small example VS project just creating a VSS 
snapshot and copying said file out of the VSS snapshot (using the proper 
shadow copy volume path), it works OK.


MK

On 9.01.2024 15:11, spadaj...@gmail.com wrote:

OK. There is more to this than just bareos.
1. I used the script from this thread and it seems to be working 
relatively well for backing up (I'm yet to test the restore part ;-)) 
the disk. I don't know, however how to backup whole mountpoint. If I 
put the location of my symlink/junction/whatever that is, only the 
junction point itself gets backed up, not the contents. I can't make 
bareos descend into the mounted VSS shadow copy. I have to explicitly 
list directories (like c:/vssmount/c/users) to back them up.
2. I spent whole evening yesterday trying to get vss to work, 
regardless of bareos. I tried creating snapshots with " shadowcopy 
call create Volume=C:\" and then symlinking them by hand and each time 
I did them I was also getting access denied due to file open. So there 
must be something else that the script provided in this thread does 
and neither bareos nor manual wmic call do.

(My system here is Win10)

MK
On Friday, April 28, 2023 at 3:33:36 PM UTC+2 
jo.go...@hosted-power.com wrote:


We have simuilar issues, it seems for some servers a lot is
skipped. We would really like to get to the root cause

On Wednesday, 21 December 2022 at 04:19:35 UTC+1 Matt Bader wrote:

Hi Timo and Andreas,

I'd be interested to know how to handle this issue as well -
it's happening to a number of my FDs too. Did you figure out
how to get VSS to work on all files?

Thanks and regards,

Matt

On Friday, February 11, 2022 at 6:21:59 PM UTC+1
zehnb...@gmail.com wrote:

Hey Andreas,

Windows Server Backup is working.

Those 3 files are just files to demonstrate that somehow
the bareos-vss is not working. Like i already mentioned,
as a workaround i can create a vss with a
powershell-script and ClientRunBeforeJob, then backup and
remove the vss with ClientRunAfterJob again. Also using
restic, for example, is working like a charm.

Best,
Timo

Andreas Rogge schrieb am Donnerstag, 10. Februar 2022 um
20:30:54 UTC+1:

Am 07.02.22 um 08:20 schrieb Vorname Nachname:
> Any suggestions?

Check if the integrated Windows Server Backup works or
not.
Are you backing up only these three files, or are the
other files where
the backup works?

Best Regards,
Andreas

-- 
Andreas Rogge andrea...@bareos.com

Bareos GmbH & Co. KG Phone: +49 221-630693-86

http://www.bareos.com

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens,
Philipp Storz

--
You received this message because you are subscribed to the Google 
Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/56334b0f-cabd-4570-8e4d-c7ba70b8dfc7n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/601cf55a-944f-4525-a4ba-55d66f01bd5e%40gmail.com.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[spadaj...@gmail.com]

OK. There is more to this than just bareos.
1. I used the script from this thread and it seems to be working relatively 
well for backing up (I'm yet to test the restore part ;-)) the disk. I 
don't know, however how to backup whole mountpoint. If I put the location 
of my symlink/junction/whatever that is, only the junction point itself 
gets backed up, not the contents. I can't make bareos descend into the 
mounted VSS shadow copy. I have to explicitly list directories (like 
c:/vssmount/c/users) to back them up.
2. I spent whole evening yesterday trying to get vss to work, regardless of 
bareos. I tried creating snapshots with " shadowcopy call create 
Volume=C:\" and then symlinking them by hand and each time I did them I was 
also getting access denied due to file open. So there must be something 
else that the script provided in this thread does and neither bareos nor 
manual wmic call do.
(My system here is Win10)

MK
On Friday, April 28, 2023 at 3:33:36 PM UTC+2 jo.go...@hosted-power.com 
wrote:

> We have simuilar issues, it seems for some servers a lot is skipped. We 
> would really like to get to the root cause
>
> On Wednesday, 21 December 2022 at 04:19:35 UTC+1 Matt Bader wrote:
>
>> Hi Timo and Andreas, 
>>
>> I'd be interested to know how to handle this issue as well - it's 
>> happening to a number of my FDs too. Did you figure out how to get VSS to 
>> work on all files?
>>
>> Thanks and regards, 
>>
>> Matt
>>
>> On Friday, February 11, 2022 at 6:21:59 PM UTC+1 zehnb...@gmail.com 
>> wrote:
>>
>>> Hey Andreas, 
>>>
>>> Windows Server Backup is working.
>>>
>>> Those 3 files are just files to demonstrate that somehow the bareos-vss 
>>> is not working. Like i already mentioned, as a workaround i can create a 
>>> vss with a powershell-script and ClientRunBeforeJob, then backup and 
>>> remove the vss with ClientRunAfterJob again. Also using restic, for 
>>> example, is working like a charm.
>>>
>>> Best,
>>> Timo
>>>
>>> Andreas Rogge schrieb am Donnerstag, 10. Februar 2022 um 20:30:54 UTC+1:
>>>
 Am 07.02.22 um 08:20 schrieb Vorname Nachname: 
 > Any suggestions? 

 Check if the integrated Windows Server Backup works or not. 
 Are you backing up only these three files, or are the other files where 
 the backup works? 

 Best Regards, 
 Andreas 

 -- 
 Andreas Rogge andrea...@bareos.com 
 Bareos GmbH & Co. KG Phone: +49 221-630693-86 <+49%20221%2063069386> 
 http://www.bareos.com 

 Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 
 Komplementär: Bareos Verwaltungs-GmbH 
 Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz 

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/56334b0f-cabd-4570-8e4d-c7ba70b8dfc7n%40googlegroups.com.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

['jo.go...@hosted-power.com' via bareos-users]

We have simuilar issues, it seems for some servers a lot is skipped. We 
would really like to get to the root cause

On Wednesday, 21 December 2022 at 04:19:35 UTC+1 Matt Bader wrote:

> Hi Timo and Andreas, 
>
> I'd be interested to know how to handle this issue as well - it's 
> happening to a number of my FDs too. Did you figure out how to get VSS to 
> work on all files?
>
> Thanks and regards, 
>
> Matt
>
> On Friday, February 11, 2022 at 6:21:59 PM UTC+1 zehnb...@gmail.com wrote:
>
>> Hey Andreas, 
>>
>> Windows Server Backup is working.
>>
>> Those 3 files are just files to demonstrate that somehow the bareos-vss 
>> is not working. Like i already mentioned, as a workaround i can create a 
>> vss with a powershell-script and ClientRunBeforeJob, then backup and 
>> remove the vss with ClientRunAfterJob again. Also using restic, for 
>> example, is working like a charm.
>>
>> Best,
>> Timo
>>
>> Andreas Rogge schrieb am Donnerstag, 10. Februar 2022 um 20:30:54 UTC+1:
>>
>>> Am 07.02.22 um 08:20 schrieb Vorname Nachname: 
>>> > Any suggestions? 
>>>
>>> Check if the integrated Windows Server Backup works or not. 
>>> Are you backing up only these three files, or are the other files where 
>>> the backup works? 
>>>
>>> Best Regards, 
>>> Andreas 
>>>
>>> -- 
>>> Andreas Rogge andrea...@bareos.com 
>>> Bareos GmbH & Co. KG Phone: +49 221-630693-86 <+49%20221%2063069386> 
>>> http://www.bareos.com 
>>>
>>> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 
>>> Komplementär: Bareos Verwaltungs-GmbH 
>>> Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/ea08dfff-8bfd-41bb-be10-b9edbd16a04dn%40googlegroups.com.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Matt Bader]

Hi Timo and Andreas, 

I'd be interested to know how to handle this issue as well - it's happening 
to a number of my FDs too. Did you figure out how to get VSS to work on all 
files?

Thanks and regards, 

Matt

On Friday, February 11, 2022 at 6:21:59 PM UTC+1 zehnb...@gmail.com wrote:

> Hey Andreas, 
>
> Windows Server Backup is working.
>
> Those 3 files are just files to demonstrate that somehow the bareos-vss is 
> not working. Like i already mentioned, as a workaround i can create a vss 
> with a powershell-script and ClientRunBeforeJob, then backup and remove 
> the vss with ClientRunAfterJob again. Also using restic, for example, is 
> working like a charm.
>
> Best,
> Timo
>
> Andreas Rogge schrieb am Donnerstag, 10. Februar 2022 um 20:30:54 UTC+1:
>
>> Am 07.02.22 um 08:20 schrieb Vorname Nachname: 
>> > Any suggestions? 
>>
>> Check if the integrated Windows Server Backup works or not. 
>> Are you backing up only these three files, or are the other files where 
>> the backup works? 
>>
>> Best Regards, 
>> Andreas 
>>
>> -- 
>> Andreas Rogge andrea...@bareos.com 
>> Bareos GmbH & Co. KG Phone: +49 221-630693-86 <+49%20221%2063069386> 
>> http://www.bareos.com 
>>
>> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646 
>> Komplementär: Bareos Verwaltungs-GmbH 
>> Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/7afd4b20-4f8b-45f6-b958-41c115f34870n%40googlegroups.com.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Vorname Nachname]

Hey Andreas, 

Windows Server Backup is working.

Those 3 files are just files to demonstrate that somehow the bareos-vss is 
not working. Like i already mentioned, as a workaround i can create a vss 
with a powershell-script and ClientRunBeforeJob, then backup and remove the 
vss with ClientRunAfterJob again. Also using restic, for example, is 
working like a charm.

Best,
Timo

Andreas Rogge schrieb am Donnerstag, 10. Februar 2022 um 20:30:54 UTC+1:

> Am 07.02.22 um 08:20 schrieb Vorname Nachname:
> > Any suggestions?
>
> Check if the integrated Windows Server Backup works or not.
> Are you backing up only these three files, or are the other files where 
> the backup works?
>
> Best Regards,
> Andreas
>
> -- 
> Andreas Rogge andrea...@bareos.com
> Bareos GmbH & Co. KG Phone: +49 221-630693-86 <+49%20221%2063069386>
> http://www.bareos.com
>
> Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
> Komplementär: Bareos Verwaltungs-GmbH
> Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz
>

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/a78281c6-6576-45d9-ada7-28b0b61489f5n%40googlegroups.com.

Re: [bareos-users] VSS ERR=The process cannot access the file because it is being used by another process

[Andreas Rogge]

Am 07.02.22 um 08:20 schrieb Vorname Nachname:

Any suggestions?


Check if the integrated Windows Server Backup works or not.
Are you backing up only these three files, or are the other files where 
the backup works?


Best Regards,
Andreas

--
Andreas Rogge andreas.ro...@bareos.com
  Bareos GmbH & Co. KG  Phone: +49 221-630693-86
  http://www.bareos.com

  Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
  Komplementär: Bareos Verwaltungs-GmbH
  Geschäftsführer: S. Dühr, M. Außendorf, J. Steffens, Philipp Storz

--
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/1b91bd46-9ace-d1c8-e872-1b2f93620ecd%40bareos.com.