View Issue Details

IDProjectCategoryView StatusLast Update
0000570bareos-core[All Projects] webuipublic2017-06-08 16:02
Reporterrenato.ramondaAssigned To 
Status closedResolutionno change required 
PlatformLinuxOSRHELOS Version7
Product Version15.2.2 
Fixed in Version 
Summary0000570: "Files to be restored" panel empty on non-widows filesets
DescriptionThis is an odd one and it looks like the opposite of a previous bug: in the "Restore" section I get the "Loading" animation, but while with Windows clients I get the expandable file lists, with *nix clients the window remains empty.
Steps To ReproduceGo to the Restore section and select any backup job from a non-windows client
Additional InformationChecked with the browser console, the "pane" that shows the file list is completely empty: the "jstree" grid object only has the headers line.

The JavaScript console shows this error:
Uncaught TypeError: Cannot read property 'defaults' of undefined

(anonymous function) @ jstreegrid.js:116
(anonymous function) @ jstreegrid.js:28
(anonymous function) @ jstreegrid.js:30
TagsNo tags attached.
bareos-master: impact
bareos-master: actionnone
bareos-19.2: impact
bareos-19.2: action
bareos-18.2: impact
bareos-18.2: action
bareos-17.2: impact
bareos-17.2: action
bareos-16.2: impact
bareos-16.2: actionnone
bareos-15.2: impact
bareos-15.2: action
bareos-14.2: impact
bareos-14.2: action
bareos-13.2: impact
bareos-13.2: action
bareos-12.4: impact
bareos-12.4: action


related to 0000603 closed no files in bareos-webui restore menu 




2015-12-18 12:34

manager   ~0002043

Is this still an issue with latest director and webui installed? I wasn't able to reproduce.


2015-12-18 13:50

reporter   ~0002046

I just updated all packages on the Director (bareos-dir and bareos-webui especially) to 15.2.2-33.1 (Ubuntu package).

I still get the empty list.

If there is something I can do to debug it further, please let me know.


2016-01-20 13:29

manager   ~0002120

Ok, let's see if we can get the root directory of a *nix client via bvfs api from the catalog db in a bconsole session.

1. Find a jobid of a *nix clients last full backup.

2. In bconsole execute the following command, to update the cache.

.bvfs_update jobid=<jobid>

3. In bconsole execute the following command with empty path argument.

.bvfs_lsdirs jobid=<jobid> path=

You should the see something like this:

*.bvfs_lsdirs jobid=654 path=
198 0 0 0 A A A A A A A A A A A A A A .
197 0 0 0 A A A A A A A A A A A A A A /

If you only get a one-liner like following, your catalog is maybe corrupt.

*.bvfs_lsdirs jobid=169964 path=
939173 0 0 0 A A A A A A A A A A A A A A .


2016-01-20 14:42

reporter   ~0002121

Yes, I get a oneliner:

Using Catalog "MyCatalog"
*.bvfs_lsdirs jobid=8836 path=
78056 0 0 0 A A A A A A A A A A A A A A .

Note that if I do a "restore" I am able to browse the fileset tree, so I guess all is not lost.

What can I do from here? I'd loathe to throw away the catalog, especially relabeling all tapes (and losing all the backups up to now).

An additional info that might be important: we are using migration jobs, and we have a prerun script that finds all 0-size jobs and deletes them from the catalog (to work around an older bug from last summer that I *think* might be fixed now). Could this be part of the problem?

Can I run some cleanup/fix job? bareos-dbcheck?


2016-01-20 14:47

reporter   ~0002122

So I went ahead and did at least a read-only scan with bareos-dbcheck:

Checking for Filenames with a trailing slash
Found 0 bad Filename records.
Checking for Paths without a trailing slash
Found 1 bad Path records.
Checking for duplicate Filename entries.
Found 0 duplicate Filename records.
Checking for duplicate Path entries.
Found 0 duplicate Path records.
Checking for orphaned JobMedia entries.
Checking for orphaned File entries. This may take some time!
Pruning orphaned Path entries isn't possible when using BVFS.
Note. Index over the FilenameId column not found, that can greatly slow down dbcheck.
Checking for orphaned Filename entries. This may take some time!
Found 3512 orphaned Filename records.
Drop temporary index.
Checking for orphaned FileSet entries. This takes some time!
Found 5 orphaned FileSet records.
Checking for orphaned Client entries.
Found 1 orphaned Client records.
Checking for orphaned Job entries.
Found 0 orphaned Job records.
Checking for Admin Job entries.
Found 0 Admin Job records.
Checking for Restore Job entries.
Found 8 Restore Job records.

Should I set it to read-write and let it fix the problems?


2016-01-20 15:34

manager   ~0002123

Probably do a ".bvfs_clear_cache" in bconsole first an see if the problem still exists by repeating the steps from my previous comment.


2016-01-20 15:53

reporter   ~0002124

Yeah, still the same output after clearing the bvfs. Should I do the dbcheck R/W?


2016-01-20 16:20

manager   ~0002126

Usually this shouldn't be needed, but sure you can give bareos-dbcheck a try with the -f option and see if it solves the issue.


2016-01-20 16:26

reporter   ~0002127

YAY, success!

Fixing the catalog with dbcheck gave me back the file browser.

I'll try now to remove our hacky workaround for the zero-size migration jobs bug, and hope for the best.


2016-01-20 16:35

manager   ~0002128

Great, I'll keep this open on feedback for a while, just in case.


2016-01-22 10:31

reporter   ~0002144

Same issue for me, running bareos-dbcheck does not fix the problem.


2016-01-22 15:26

reporter   ~0002151

On my side, after a full set of migration jobs ran, it looks like all is still working.


2016-02-02 15:06

reporter   ~0002178

same here-still not able to restore via webui.


2016-02-02 15:20

reporter   ~0002179

On my side I can confirm everything is still working ok: I can still browse the file tree (and didn't need to delete zero-size jobs).


2016-06-10 17:35

manager   ~0002292

Is this still an issue?


2016-06-12 21:07

reporter   ~0002296

Last edited: 2016-06-12 21:08

View 2 revisions

For windows client, problem can be in File record in FileSet.
 Try replace "\" to "/". Do ".bvfs_clear_cache yes" in bconsole and run "/usr/sbin/bareos-db -f".



2016-06-13 08:54

reporter   ~0002297

Bareos 15.2.2, still an issue, still the same: only filesets from windows clients are shown.


2016-06-13 09:08

reporter   ~0002298

I did a dbcheck with error fixing again, and again this (and cleaning the cache, and restarting bareos-dir) fixed it for me.

Still, how is it possible that the db goes to hell so fast? If the kind of stuff the dbcheck fixes happens so frequently, those checks should be in the code and running all the time, should they not?

Or, is this some side-effect of some transparent fault in my setup? The only strange thing happening lately is that some job (especially long-running, big jobs) has broken mid-way. Could this cause (for example) a ton of orphaned FileNameId, like in my db?

Issue History

Date Modified Username Field Change
2015-11-24 16:25 renato.ramonda New Issue
2015-11-24 16:25 renato.ramonda Status new => assigned
2015-11-24 16:25 renato.ramonda Assigned To => frank
2015-12-18 12:34 frank Note Added: 0002043
2015-12-18 12:34 frank Status assigned => feedback
2015-12-18 13:50 renato.ramonda Note Added: 0002046
2015-12-18 13:50 renato.ramonda Status feedback => assigned
2016-01-20 13:29 frank Note Added: 0002120
2016-01-20 13:29 frank Status assigned => feedback
2016-01-20 14:42 renato.ramonda Note Added: 0002121
2016-01-20 14:42 renato.ramonda Status feedback => assigned
2016-01-20 14:47 renato.ramonda Note Added: 0002122
2016-01-20 15:34 frank Note Added: 0002123
2016-01-20 15:35 frank Status assigned => feedback
2016-01-20 15:53 renato.ramonda Note Added: 0002124
2016-01-20 15:53 renato.ramonda Status feedback => assigned
2016-01-20 16:20 frank Note Added: 0002126
2016-01-20 16:26 renato.ramonda Note Added: 0002127
2016-01-20 16:35 frank Note Added: 0002128
2016-01-20 16:35 frank Status assigned => feedback
2016-01-22 10:31 Shodan Note Added: 0002144
2016-01-22 15:11 frank Relationship added related to 0000603
2016-01-22 15:26 renato.ramonda Note Added: 0002151
2016-01-22 15:26 renato.ramonda Status feedback => assigned
2016-01-22 17:29 frank Status assigned => feedback
2016-02-02 15:06 olga Note Added: 0002178
2016-02-02 15:20 renato.ramonda Note Added: 0002179
2016-02-02 15:20 renato.ramonda Status feedback => assigned
2016-06-10 17:35 frank Note Added: 0002292
2016-06-10 17:35 frank Status assigned => feedback
2016-06-12 21:07 master_volkov Note Added: 0002296
2016-06-12 21:08 master_volkov Note Edited: 0002296 View Revisions
2016-06-13 08:54 renato.ramonda Note Added: 0002297
2016-06-13 08:54 renato.ramonda Status feedback => assigned
2016-06-13 09:08 renato.ramonda Note Added: 0002298
2016-11-03 17:47 frank Status assigned => resolved
2016-11-03 17:47 frank Resolution open => no change required
2017-06-08 16:02 frank bareos-master: action => none
2017-06-08 16:02 frank bareos-16.2: action => none
2017-06-08 16:02 frank Status resolved => closed
2017-06-08 16:02 frank Assigned To frank =>