After scan it is not possible to connect anymore [Debian]

Kaily 3 years ago updated 3 years ago 7

After new installation it is not posssible to connect anymore.

No Log entry.

Ubooquity starts correct, configuration is okay and during scan every user is able to connect.

Also the Admin.

After scan, the web access is not possible.

Ubootquity is still alive.

server:/opt/ubooquity/logs# /etc/init.d/ubooquity status
â ubooquity.service - LSB: Ubooquity
   Loaded: loaded (/etc/init.d/ubooquity)
   Active: active (running) since Di 2017-08-15 20:41:49 CEST; 21h ago
  Process: 21716 ExecStop=/etc/init.d/ubooquity stop (code=exited, status=0/SUCCESS)
  Process: 22528 ExecStart=/etc/init.d/ubooquity start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/ubooquity.service
           ââ22538 /usr/bin/java -jar /opt/ubooquity/Ubooquity.jar --headless --remoteadmin 192.168.1.* --libraryport 8888

Aug 15 20:41:49 server ubooquity[22528]: Starting Ubooquity: Ubooquity.
Aug 15 20:41:49 server systemd[1]: Started LSB: Ubooquity.
Aug 16 18:16:02 server systemd[1]: Started LSB: Ubooquity.

Could somebody give me hand?

Thx Kaily

Hello Kaily,

at first glance, your script call for a headless service seems to be 'wrong declared' : 

"usr/bin/java -jar /opt/ubooquity/Ubooquity.jar --headless --remoteadmin 192.168.1.* --libraryport 8888" 

--headless = correct

-- remoteadmin = correct 

  192.168.1.* = is that your host-IP ? If yes, then set ist with the --host flag, e.g. --host 192.168.1.*
  (replace with your server interface IP) 

or did you want to bind the possible remote admin adress to only 192.168.1.* ?

Thats barking up the wrong tree, because this isnt possible with Ubooquity. 

for this target you have to configure your Debian firewall rules strictly, but beware of set it up too strict - 

you can lookout everybody's access, including yours... 

--libraryport 8888 = correct 

please replace <<YOUR-IP>> with your server IP (or leave it all away) and test the following code in your shell, ok ? 

" usr/bin/java -jar /opt/ubooquity/Ubooquity.jar --headless --remoteadmin --host <<YOUR-IP>>  --libraryport 8888 " or 

" usr/bin/java -jar /opt/ubooquity/Ubooquity.jar --headless --remoteadmin --libraryport 8888 "

(successful checked on my debian 8.9/9.1 VM-Machines)  

Best regards & max success ! 


Ups, okay.

Yes, Ubooquity is on my server and i want to connect only with my private network as a remotadmin.

Not only with one client, also with all clients in my network (as Admin).

The Libary should be available outside my private network as well.

So i missunderstood the manual. I will try your proposal.

Thanks very much.


Hi Kaily,

if you want to use only your library outsite of your private network, you can set the port-forward rules on your Router only for your library (forward only the port 8888) .. That's the easiest way to do it, and measured to the quality from usual router-firewalls also basical very secure... 

hope this helps 



Yes, that´s what i did.

As i wrote, the unusal behavior is, that i could connect and administrate everything.

Like in 1.10, this version was installed before and worked perfect.

After scan in version 2.10 / 2.02 (i tried out both versions) i wasn´t able to connect, not as an Admin or User neither from inside or outside my network.

But i will try it, later @home.


After starting scan it worked.

But again the Libary scan was finished and i was not able to connect.

I stopped Ubooquity and set the rights for the Database to rwx for everybody.

Who is the owner of the Folder? I made the Folder rights to root???

I startet with the init.d script and still the same problem.

After manual start with :

" usr/bin/java -jar /opt/ubooquity/Ubooquity.jar --headless --remoteadmin --libraryport 8888 "

I´m able to connect, but some of the Database is lost. So, again a new scan.

Maybe cause i have changed the rights of the database.

Never the less, here is a part of my init.d script:

# Provides:          Ubooquity
# Required-Start:    $local_fs $remote_fs $network
# Required-Stop:     $local_fs $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Ubooquity
# Description:       Ubooquity for ebook management

# Documentation available at
# http://refspecs.linuxfoundation.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
# Debian provides some extra functions though
. /lib/lsb/init-functions

export UBOOQUITY_HOME=/opt/ubooquity
DAEMON_OPTS="-jar /opt/ubooquity/Ubooquity.jar --headless --remoteadmin --libraryport 8888"
DAEMON_DESC=$(get_lsb_header_val $0 "Short-Description")

[ -r "/etc/default/${DAEMON_NAME}" ] && . "/etc/default/${DAEMON_NAME}"

do_start() {
  local result

        pidofproc -p "${DAEMON_PID}" "${DAEMON_PATH}" > /dev/null
        if [ $? -eq 0 ]; then
                log_warning_msg "${DAEMON_NAME} is already started"


Hello Kaily,

there is an strange/weird permission rights problem on your installation - have you actually think about an complete fresh start-over (renaming / moving / deleting all files excluding the Ubooquity.jar in your installation folder and start it again) ? 

The owner should be the creator, in this case root - thats correct.

the init.d-file seem correct, too - it looks like an RasPi-installation :-)

Any "death body" parts from a 1.X-Installation may occur your bugs - my old 1.x-installation was filled up with ca. 10.000 comic and ca.3.500 ebup/PDF-books, and after a "full fresh start-over" including scanning the entire collection for ca.1 day all runs perfect... 


Hello Toni, after all it dosn´t work.

I think i will go back to 1.10 and in a few weeks change to Debian 9.x.

It is not possible for me to define the problem so far.

Thanks anyway.