/etc/sbfspot is not mapped to a directory outside the container => Config file can't be read. Please map the directory and restart the container.

[TerrorSource]

I use Portainer and created a Portainer Stacks(same as Docker Compose). This is my config:

version: "3"

services:
  sbfspot:
    container_name: sbfspot
    image: nakla/sbfspot:latest
    network_mode: bridge
    environment:
      - TZ=Europe/Amsterdam
      - CSV_STORAGE=1
      - DB_STORAGE=mariadb
      - ENABLE_SBFSPOT=1
      - ENABLE_SBFSPOT_UPLOAD=1
      - FINQ=1
      - INIT_DB=0
      - MQTT_ENABLE=1
      - SBFSPOT_ARGS=-d5 -v5 -finq -nocsv -nosql
      - SBFSPOT_INTERVAL=600
    volumes:
      - /share/CACHEDEV1_DATA/Docker/sbfspot/etc:/etc/sbfspot
      - /share/CACHEDEV1_DATA/Docker/sbfspot/data:/var/sbfspot

It does start and automatically stops with this error:

/etc/sbfspot is not mapped to a directory outside the container => Config file can't be read.
Please map the directory and restart the container.

Already chmod and chown the folder, did not solve the issue chmod -R 777 sbfspot/ chown -R 5000:5000 /share/CACHEDEV1_DATA/Docker/sbfspot

[nakla]

Hi, I don't know, if your config works, because of the different syntax (- and = different from my yaml), additionally the network_mode should not be bridge (as mentioned in the readme). Please take a look in portainer, if your directories are really mapped, or even better, connect into your container, check if the directories are mounted and simply create a file inside those directories. I can only tell you, that I don't have issues here with portainer and the mappings on x64 arch - atm. I don't know why you experience those problems...

With chmod -R 777 sbfspot/ you mean chmod -R 777 /share/CACHEDEV1_DATA/Docker/sbfspot ?

[TerrorSource]

This are the mapped folders

i cannot see the content in the docker as it cannot start. console is only possible with a running container.

[Depechie]

@TerrorSource just for reference I had similar issue and fixed it by actually creating a user with the 5000 id. My docker compose can be seen here: https://github.com/Depechie/HomeLab/blob/main/sbfspot-docker-compose.yml

So

sudo groupadd sbfspotgroup
sudo useradd -u 5000 sbfspotuser
sudo passwd sbfsspotuser Password: *****
sudo usermod -a -G sbfspotgroup sbfspotuser
sudo chgrp -R sbfspotgroup sbfspot
sudo chown -R sbfspotuser sbfspot

Last chown and chgrp is on the directory that should be mapped from linux into the docker container.

[TerrorSource]

@Depechie i've done the steps you posted. had to use "addgroup" instead of "groupadd". checked the /etc/passwd file and the user is in the file with 5000 sbfspotuser:x:5000:5000:Linux User,,,:/home/sbfspotuser:/bin/sh

Used your compose as an example to mix with mine.

Still got the same issue:

/etc/sbfspot is not mapped to a directory outside the container => Config file can't be read.
Please map the directory and restart the container.

[nakla]

@Depechie creating a user in the host system shouldn't be necessary, I don't have the sbfspot user and group on my host system. @TerrorSource please post the output of ls -l /share/CACHEDEV1_DATA/Docker/sbfspot

[Depechie]

@nakla I know that this is not strictly needed... but doing a chown with an user id 5000 that I do not know on my system just feels weird for me.

[TerrorSource]

@Depechie creating a user in the host system shouldn't be necessary, I don't have the sbfspot user and group on my host system. @TerrorSource please post the output of ls -l /share/CACHEDEV1_DATA/Docker/sbfspot

i've recreated the folder (sbfspot) via WinSCP with my normal user account and let the docker create the folders inside:

[/share/CACHEDEV1_DATA/Docker] # ls -l /share/CACHEDEV1_DATA/Docker/sbfspot
total 8
drwxr-xr-x 2 admin administrators 4096 2023-11-08 15:18 config/
drwxr-xr-x 2 admin administrators 4096 2023-11-08 15:18 data/

restarted the docker and same issue

[nakla]

OK, these are not the expected rights, but it should work with them. Next step would be to connect into the container. So in portainer, choose the sbfspot container, press the duplicate/edit button. Then edit your settings to the following. After that, your container keeps open. You can open the console inside the container and have to choose /bin/sh as command instead of /bin/bash. In the containers shell, please post me the output of mount.

[TerrorSource]

OK, these are not the expected rights, but it should work with them. Next step would be to connect into the container. So in portainer, choose the sbfspot container, press the duplicate/edit button. Then edit your settings to the following. After that, your container keeps open. You can open the console inside the container and have to choose /bin/sh as command instead of /bin/bash. In the containers shell, please post me the output of mount.

mount does nothing

/etc/sbfspot $ mount
/etc/sbfspot $ 

checked the folders via ls -al

/etc/sbfspot $ ls -al /etc/sbfspot/
total 52
drwxrwxrwx    2 sbfspot  sbfspot       4096 Nov  8 15:25 .
drwxr-xr-x    1 root     root          4096 Nov  8 18:53 ..
-rwxrwxrwx    1 sbfspot  sbfspot       9382 Jan 19  2021 SBFspot - kopie.cfg
-rwxrwxrwx    1 sbfspot  sbfspot       9381 Jan 12  2023 SBFspot.cfg
-rwxrwxrwx    1 sbfspot  sbfspot       9557 Jul  6  2020 SBFspot.default.cfg
-rwxrwxrwx    1 sbfspot  sbfspot       1955 Jan 19  2021 SBFspotUpload.cfg
-rwxrwxrwx    1 sbfspot  sbfspot       1930 Jul  6  2020 SBFspotUpload.default.cfg
/etc/sbfspot $ ls -al /var/sbfspot/
total 12
drwxrwxrwx    2 sbfspot  sbfspot       4096 Nov  8 15:18 .
drwxr-xr-x    1 root     root          4096 Sep  1 03:18 ..
/etc/sbfspot $ 

[nakla]

Ok, that is our problem. In the start-script, with the mount command, I check if the outside directory is mounted / available. The mount command inside the container normally returns more than 20 entries from mounted directories / files not zero. ATM I don't know why this is the case in your installation. Can you issue the command /usr/local/bin/sbfspot.3/SBFspot_nosql -? inside your container? - Just to confirm sbfspot runs and we "only" have the mount - command problem...

[TerrorSource]

@nakla done:

/etc/sbfspot $ /usr/local/bin/sbfspot.3/SBFspot_nosql -?
SBFspot V3.9.7
Yet another tool to read power production of SMA solar inverters
(c) 2012-2022, SBF (https://github.com/SBFspot/SBFspot)
Compiled for Linux (LE) 64 bitSBFspot [-options]
 -scan               Scan for bluetooth enabled SMA inverters.
 -d#                 Set debug level: 0-5 (0=none, default=2)
 -v#                 Set verbose output level: 0-5 (0=none, default=2)
 -ad#                Set #days for archived daydata: 0-300
                     0=disabled, 1=today (default), ...
 -am#                Set #months for archived monthdata: 0-300
                     0=disabled, 1=current month (default), ...
 -ae#                Set #months for archived events: 0-300
                     0=disabled, 1=current month (default), ...
 -cfg:filename.ext   Set alternative config file
 -finq               Force Inquiry (Inquire inverter also during the night)
 -q                  Quiet (No output)
 -nocsv              Disables CSV export (Overrules CSV_Export in config)
 -nosql              Disables SQL export
 -sp0                Disables Spot.csv export
 -installer          Login as installer
 -password:xxxx      Installer password
 -loadlive           Use predefined settings for manual upload to pvoutput.org
 -startdate:YYYYMMDD Set start date for historic data retrieval
 -settime            Sync inverter time with host time
 -mqtt               Publish spot data to MQTT broker
 -version            Show SBFspot version number

Libraries used:
        BOOST V1.72.0
/etc/sbfspot $ 

[nakla]

Ok, the sbfspot binary seems to run, I think you have a problem with your environment, not with the container itself. Therefore I don't have a solution for your problem. You can disable that "mount" test in the console by editing the start.sh script vi /start.sh and change lins 78 from ifmount | grep -q -e "$confdir "; then into if true; then. But that is only a temporary solution. If I update the container and you download it, your changes will be overwritten. Furthermore you should check, if the directories are really mounted. E.g. copy a file in the host directory and watch, if the files are shown in the mapped container dirs.

[TerrorSource]

@nakla as i see on this repo there are multiple users with the same issue: https://github.com/nakla/sbfspot/issues/6 https://github.com/nakla/sbfspot/issues/15

[nakla]

Sorry if the project does not work for you. I don't know how to reproduce the failure, so I can't find a solution. As only 2 persons had problems with the mounting (one didn't set the correct file-rights), I believe the problem is based on their/your setup and not the project as already told. Have you tested the points I had described?

[nakla]

Problem seems to be solved...