Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dietpi-Software File browser won't start #5093

Closed
jaguar489 opened this issue Dec 18, 2021 · 9 comments · Fixed by #5099
Closed

Dietpi-Software File browser won't start #5093

jaguar489 opened this issue Dec 18, 2021 · 9 comments · Fixed by #5099
Labels
Milestone

Comments

@jaguar489
Copy link

Hi,

I am running a freshly installed 64-bit dietpi OS on a raspberry Pi 4 4GB using a micro SD card. I am having the attached error when trying to access the file browser software. I have already attempted reinstalling the software and restarting the service but it continuosly says failed.
Thanks
Screenshot_20211218-032515~01

@Joulinar
Copy link
Collaborator

Hmm I did a test installation on RPi4 64bit without issue. Can you share following

journalctl -u filebrowser.service

@jaguar489
Copy link
Author

jaguar489 commented Dec 18, 2021

Here is the result

root@DietPi:~# journalctl -u filebrowser.service
-- Journal begins at Fri 2021-12-17 19:23:01 EST, ends at Sat 2021-12-18 04:35:39 EST. --
Dec 17 19:23:13 DietPi systemd[1]: Started File Browser (DietPi).
Dec 17 19:23:15 DietPi filebrowser[841]: 2021/12/17 19:23:15 No config file used
Dec 17 19:23:15 DietPi filebrowser[841]: 2021/12/17 19:23:15 listen tcp 0.0.0.0:8084: bind: address already in use
Dec 17 19:23:15 DietPi systemd[1]: filebrowser.service: Main process exited, code=exited, status=1/FAILURE
Dec 17 19:23:15 DietPi systemd[1]: filebrowser.service: Failed with result 'exit-code'.

I'm not seeing anything that would conflict with the port.
I also have the dietpi dashboard installed which also seems to have file browser.

@Joulinar
Copy link
Collaborator

Can you share following

ss -tulpn | grep LISTEN

@jaguar489
Copy link
Author

jaguar489 commented Dec 18, 2021

root@DietPi:~# ss -tulpn | grep LISTEN
tcp   LISTEN 0      80                                          127.0.0.1:3306       0.0.0.0:*    users:(("mariadbd",pid=725,fd=21))  
tcp   LISTEN 0      511                                         127.0.0.1:6379       0.0.0.0:*    users:(("redis-server",pid=663,fd=7))
tcp   LISTEN 0      5                                             0.0.0.0:8080       0.0.0.0:*    users:(("python3",pid=828,fd=3))    
tcp   LISTEN 0      1024                                          0.0.0.0:80         0.0.0.0:*    users:(("lighttpd",pid=815,fd=4))   
tcp   LISTEN 0      500                                           0.0.0.0:8084       0.0.0.0:*    users:(("mono",pid=416,fd=5))       
tcp   LISTEN 0      10                                            0.0.0.0:8085       0.0.0.0:*    users:(("python3",pid=844,fd=5))    
tcp   LISTEN 0      1000                                          0.0.0.0:22         0.0.0.0:*    users:(("dropbear",pid=439,fd=4))   
tcp   LISTEN 0      128                                           0.0.0.0:8088       0.0.0.0:*    users:(("dietpi-dashboar",pid=41453,fd=6))
tcp   LISTEN 0      500                                           0.0.0.0:8989       0.0.0.0:*    users:(("mono",pid=831,fd=8))       
tcp   LISTEN 0      512                                           0.0.0.0:8096       0.0.0.0:*    users:(("jellyfin",pid=823,fd=288)) 
tcp   LISTEN 0      30                                 192.168.0.26%wlan0:6881       0.0.0.0:*    users:(("qbittorrent-nox",pid=820,fd=18))
tcp   LISTEN 0      30                                       127.0.0.1%lo:6881       0.0.0.0:*    users:(("qbittorrent-nox",pid=820,fd=16))
tcp   LISTEN 0      512                                                 *:7878             *:*    users:(("Radarr",pid=834,fd=146))   
tcp   LISTEN 0      511                                             [::1]:6379          [::]:*    users:(("redis-server",pid=663,fd=8))
tcp   LISTEN 0      1024                                             [::]:80            [::]:*    users:(("lighttpd",pid=815,fd=5))   
tcp   LISTEN 0      4096                                                *:22000            *:*    users:(("syncthing",pid=897,fd=17)) 
tcp   LISTEN 0      128                                                 *:21               *:*    users:(("proftpd",pid=660,fd=0))    
tcp   LISTEN 0      1000                                             [::]:22            [::]:*    users:(("dropbear",pid=439,fd=5))   
tcp   LISTEN 0      50                                                  *:1340             *:*    users:(("qbittorrent-nox",pid=820,fd=14))
tcp   LISTEN 0      4096                                                *:8384             *:*    users:(("syncthing",pid=897,fd=18)) 
tcp   LISTEN 0      30                   [fe80::e65f:1ff:fe5b:88ec]%wlan0:6881          [::]:*    users:(("qbittorrent-nox",pid=820,fd=26))
tcp   LISTEN 0      30       [2607:fea8:9600:f0:e65f:1ff:fe5b:88ec]%wlan0:6881          [::]:*    users:(("qbittorrent-nox",pid=820,fd=24))
tcp   LISTEN 0      30     [fd00:1cab:c00f:cfd2:e65f:1ff:fe5b:88ec]%wlan0:6881          [::]:*    users:(("qbittorrent-nox",pid=820,fd=22))
tcp   LISTEN 0      30                                           [::1]%lo:6881          [::]:*    users:(("qbittorrent-nox",pid=820,fd=20))

@Joulinar
Copy link
Collaborator

There is a mono instance running. Do you use something like sonarr?

@jaguar489
Copy link
Author

Yes both sonarr and radarr

@Joulinar
Copy link
Collaborator

Joulinar commented Dec 18, 2021

ok we produced a port conflict between mono and file browser. As workaround you could do following

cd /mnt/dietpi_userdata/filebrowser
/opt/filebrowser/filebrowser config set -p 8091
systemctl restart filebrowser.service

file browser should be available on port 8091 now.

@MichaIng
should we use port 8091 on new installations and migrate existing systems?

@Joulinar Joulinar added Bug 🐞 Workaround available 🆗 Workaround is available/has been implemented, but a definite solution should be found when possible. labels Dec 18, 2021
@Joulinar Joulinar added this to the v8.0 milestone Dec 18, 2021
@MichaIng
Copy link
Owner

Looks like. I'm wondering whether this is a Sonarr API on port 8084 or whether Mono itself always listens on this port for some reaons/runtime API. Can be tested with Radarr/Lidarr/Jacket on an ARMv6 RPi (1 and Zero), since all other architectures use the .NET core based versions without Mono.

MichaIng added a commit that referenced this issue Dec 19, 2021
- CHANGELOG | Mono: "mono-complete" won't be installed anymore but only "mono-devel" instead. This skips the XSP4 webserver service, which listens on port 8084 by default where it conflicts with File Browser. This only affects new instals. You can manually apply this change via "apt-mark manual mono-devel && apt --autoremove purge mono-complete". Many thanks to @jaguar489 for reporting this issue: #5093
MichaIng added a commit that referenced this issue Dec 19, 2021
- DietPi-Software | Mono: "mono-complete" won't be installed anymore but only "mono-devel" instead. This skips the XSP4 webserver service, which listens on port 8084 by default where it conflicts with File Browser. This only affects new instals. You can manually apply this change via "apt-mark manual mono-devel && apt --autoremove purge mono-complete". Many thanks to @jaguar489 for reporting this issue: #5093
@MichaIng MichaIng added Solution available 🥂 Definite solution has been done Enhancement 💨 and removed Workaround available 🆗 Workaround is available/has been implemented, but a definite solution should be found when possible. Investigating 🤔 labels Dec 19, 2021
@MichaIng
Copy link
Owner

We solved it differently now: #5099
Previously we had mono-complete installed, which pulls in an additional webserver services running on this port 8084 while Sonarr and the Mono-builds of Radarr, Lidarr and Jackett do not use this port and do not require anything provided by mono-complete. So it is not installed anymore now in favour of a smaller subset of Mono runtime and development packages, which does not include this unnecessary Mono XSP4 webserver service. You can manually apply this change:

apt-mark manual mono-devel
apt --autoremove purge mono-complete

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants