Error #0: - failed to read login_js.json.

    • OMV 4.x
    • Error #0: - failed to read login_js.json.

      Hi
      I can't log in, I didn't do anything and didn't change the settings



      Error #0:
      OMV\Exception: Failed to read file
      '/var/cache/openmediavault/cache.omv\controlpanel\login_js.json'
      (size=0). in /usr/share/php/openmediavault/json/file.inc:207
      Stack trace:
      #0 /usr/share/php/openmediavault/json/file.inc(223): OMV\Json\File->getContents()
      #1 /usr/share/php/openmediavault/controlpanel/controlpanelabstract.inc(173): OMV\Json\File->read()
      #2 /var/www/openmediavault/index.php(46): OMV\ControlPanel\ControlPanelAbstract->render()
      #3 {main}




      omv-aptclean doesn't help, and omv-firstaid (Clear web control panel cache).
    • crashtest wrote:

      albdr88 wrote:

      omv-aptclean doesn't help, and omv-firstaid (Clear web control panel cache).
      If you used omv-aptclean and omv-firstaid, you can get on the command line.
      What is the output of:

      df -h



      Filesystem Size Used Avail Use% Mounted on
      udev 2.8G 0 2.8G 0% /dev
      tmpfs 577M 67M 510M 12% /run
      /dev/sdd1 8.4G 8.3G 0 100% /
      tmpfs 2.9G 0 2.9G 0% /dev/shm
      tmpfs 5.0M 0 5.0M 0% /run/lock
      tmpfs 2.9G 0 2.9G 0% /sys/fs/cgroup
      tmpfs 2.9G 0 2.9G 0% /tmp
      /dev/md0 11T 5.0T 5.9T 46% /srv/dev-disk-by-label-Raid5
      overlay 8.4G 8.3G 0 100% /var/lib/docker/overlay2/b607bccadf65c2a24 1cafac6cea8fdf9afdd4c0a14c4d62dfb5d60cb5daf1b2b/merged
      overlay 8.4G 8.3G 0 100% /var/lib/docker/overlay2/cf5405ec1fe6e9c9f 226f30c2765ebfa3ef370579a435c9f14f2e0e56d55b20a/merged
      overlay 8.4G 8.3G 0 100% /var/lib/docker/overlay2/d276b6ca250cb3c7e 4c531caa179eefd6bcb599825c22bcdf23428b50fd37880/merged
      shm 64M 0 64M 0% /var/lib/docker/containers/50a3621848fbaea 2b316d00af5cd7cda06c89167a85ce2840f1577bfa7074e95/mounts/shm
      shm 64M 8.0K 64M 1% /var/lib/docker/containers/75efd5e1bf7730b 7d1b50150edde0c0c542b09523b0d3f6759b7337800e96695/mounts/shm
      overlay 8.4G 8.3G 0 100% /var/lib/docker/overlay2/7ccc3304365e0d08b b06495e5f1c3047cf108011f17da1d941a357e454c1ab82/merged
    • To confirm, what are you booting with - what's the size of the boot drive?

      albdr88 wrote:

      /dev/sdd1 8.4G 8.3G 0 100%
      If your boot drive is /dev/ssd1 which appears to be a flash drive of some type, your boot drive is full. Until this is corrected, you won't be able to access the GUI.

      Based on the rest, it appears that you have Dockers that have filled up the boot drive.

      The post was edited 1 time, last by crashtest ().

    • crashtest wrote:

      To confirm, what are you booting with - what's the size of the boot drive?

      albdr88 wrote:

      /dev/sdd1 8.4G 8.3G 0 100%
      If your boot drive is /dev/ssd1 which appears to be a flash drive of some type, your boot drive is full. Until this is corrected, you won't be able to access the GUI.
      Based in the rest, it appears that you have Dockers that have filled up the boot drive.

      Yes correct.

      Now what do I do?
      Can I add another drive to the system?
    • For a quick fix to get back into the GUI, what I would is:

      1. None Damaging
      Clone your 8GB Thumb-drive (or SD-card) to a new 16GB (or larger) Thumb-drive or SD-card.
      A process for cloning flash media is in this -> Guide, on page 76 "Cloning Flash Media".

      Then, as a separate process, you'd have to use G-parted to expand OMV's partition to use the extra space afforded by the new drive. (If you have a very small "boot" partition, on an SD-card, leave it as it is. Expanding that partition won't help you.)

      With the modified 16GB boot drive in place you'll be able to get back in to find out which Docker is dumping data onto your boot drive.
      When you get back in, I'd also recommend changing your storage location for Dockers, to your data drives. This can be done under, Services, Docker, in the Settings tab, and selecting a shared folder in the drop down menu.

      If you just started running Plex or one of the other media servers, it's probably dumping gig's of meta data onto your boot drive. That would need to be fixed or, even with the extra space on a 16GB drive, it may happen again.

      2. Potential for Damage
      Delete some of the data under one of the docker folders, as an example:
      /var/lib/docker/overlay2/d276b6ca250cb3c7e 4c531caa179eefd6bcb599825c22bcdf23428b50fd37880/merged
      Which one to delete would be your call. However, I would expect to lose Docker or one or more of your Docker images / containers.

      Maybe @geaves has some insight on this option.
    • crashtest wrote:

      Maybe @geaves has some insight on this option.
      I wouldn't delete anything without running docker system df that will tell you if there is any free space to recover.

      If watchtower isn't being used you can add this to a scheduled job docker images -q --filter "dangling=true" | xargs -n1 -r docker rmi that was posted by another user and will effectively clean up docker, this can be set to daily, weekly or monthly.
      Raid is not a backup! Would you go skydiving without a parachute?
    • albdr88 wrote:

      TYPE TOTAL ACTIVE SIZE RECLAIMABLE
      Hm! this has just appeared for me, there is not a lot of space to recover but it might just help, run docker system prune that should clean up docker and allow you to log in. But I agree with @crashtest either increase the size of your boot drive or move the docker path to your raid as you have a large number of containers.

      If that does not resolve it have a look at this thread, rather long but the prune option didn't fully resolve the disk full. Search the forum on moving your docker location from /var/lib/docker, this has come up recently.
      Raid is not a backup! Would you go skydiving without a parachute?
    • albdr88 wrote:

      But the strange thing I use SanDisk 16Gb Flash Drive Not 8Gb,I do not know why it became 8 GB!!!
      This is normal - there's nothing wrong. I'm guessing you're using an SBC (a Raspberry Pi or another board), so the image burned to the drive created an 8GB partition. The remaining space is there, just unused.

      All you have to do is use -> G-parted to resize the larger (roughly 8GB) partition on your 16GB drive. Create a boot-able Gparted device (a thumbdrive, a CD, or a DVD) and boot up on it. Insert your boot drive, hit Refresh, and enlarge the 8GB partition on the boot drive. *It might be a good idea to clone your boot drive, to a second drive for backup, before altering your boot drive.*
      (If something goes wrong, now or later, you'd also have backup.)

      Remember, you need to find which docker is filling up your boot drive or this will happen again, and it may not take long.

      The post was edited 1 time, last by crashtest: edit ().