ShaneIsrael / fireshare

Self host your media and share with unique links

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unknown Error

li-ruida opened this issue · comments

When I just completed the deployment and entered the web interface, it prompted me "Unknown Error". If I went to the login interface and submitted the login form, it prompted me "An unknown error occurred while trying to log in".

This is my docker-compose.yaml:

services:
  fireshare:
    container_name: fireshare
    image: shaneisrael/fireshare 
    ports:
      - "8887:80"        
    volumes:
      - ./data:/data        
      - ./processed:/processed 
      - ./videos:/videos  
    environment:
    - ADMIN_PASSWORD=admin 

I restarted and redeployed many times, didn't solve the problem.
My operating system environment is win10, both chrome and edge encountered errors.
The following is the log information:

2023-02-08 15:36:45 -------------------------------------
2023-02-08 15:36:45 
2023-02-08 15:36:45 User uid:    1000
2023-02-08 15:36:45 User gid:    1000
2023-02-08 15:36:45 -------------------------------------
2023-02-08 15:36:45 
2023-02-08 15:36:45 rm: cannot remove '/jobs.sqlite': No such file or directory
2023-02-08 15:36:46 2023-02-08 07:36:46,419 INFO    __init__.update_config:27 | Validating configuration file...
2023-02-08 15:36:46 INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
2023-02-08 15:36:46 INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
2023-02-08 15:36:47 2023-02-08 07:36:47,130 INFO    __init__.update_config:27 | Validating configuration file...
2023-02-08 15:36:47 2023-02-08 07:36:47,195 INFO    schedule.init_schedule:17 | Initializing scheduled video scan. minutes=5
2023-02-08 15:36:47 /usr/local/lib/python3.9/site-packages/apscheduler/util.py:94: PytzUsageWarning: The zone attribute is specific to pytz's interface; please migrate to a new time zone provider. For more details on how to do so, see https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
2023-02-08 15:36:47   if obj.zone == 'local':
2023-02-08 15:36:47 /usr/local/lib/python3.9/site-packages/apscheduler/triggers/interval.py:66: PytzUsageWarning: The normalize method is no longer necessary, as this time zone supports the fold attribute (PEP 495). For more details on migrating to a PEP 495-compliant implementation, see https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
2023-02-08 15:36:47   return self.timezone.normalize(next_fire_time)
2023-02-08 15:36:47 [2023-02-08 07:36:47 +0000] [105] [INFO] Starting gunicorn 20.1.0
2023-02-08 15:36:47 [2023-02-08 07:36:47 +0000] [105] [INFO] Listening at: http://127.0.0.1:5000 (105)
2023-02-08 15:36:47 [2023-02-08 07:36:47 +0000] [105] [INFO] Using worker: gthread
2023-02-08 15:36:47 [2023-02-08 07:36:47 +0000] [107] [INFO] Booting worker with pid: 107
2023-02-08 15:36:47 [2023-02-08 07:36:47 +0000] [108] [INFO] Booting worker with pid: 108
2023-02-08 15:36:47 [2023-02-08 07:36:47 +0000] [109] [INFO] Booting worker with pid: 109

I figured out what was causing the error in a new attempt.
When I try to load into the main screen or the login screen,the request url is http://localhost:5000/api/config
but port 5000 is not the local port set
So I made a new deployment and set the port to 5000:

services:
  fireshare:
    container_name: fireshare
    image: shaneisrael/fireshare 
    ports:
      - "5000:80"        
    volumes:
      - ./data:/data        
      - ./processed:/processed 
      - ./videos:/videos  
    environment:
    - ADMIN_PASSWORD=admin

The service is running normally.
I think it is a misconfiguration of nginx, which caused the default port of flask to be requested.

Changing that port shouldn't matter. You could have it be anything, it doesn't need to be 5000 or 8080 which is the default so long as it maps to port 80 in the container.

Port 5000 in the log is referencing the internal fireshare server that runs inside the container which does use port 5000 which is what nginx proxies the api requests too.

I'm not sure what was causing your problem or why it got fixed after changing that port unless that port was in use by some other service on your machine. However, I am certain that changing it was not what fixed the issue.

You can change it to port 5010 for example and it would still work correctly.

I am sure that in the windows environment, if the port is not changed to 5000, there will be a bug, and there is no port conflict. I can enter the web interface, but part of the service request port of the web interface is 5000.
I just tested everything working fine in a linux environment.
In the chrome developer tool, you can see the project deployed in the windows environment, but the following request cannot be requested
img

loggedin config public?sort=updated_at+desc

Request URL: http://localhost:5000/api/config
Referrer Policy: strict-origin-when-cross-origin
Provisional headers are shown
Learn more
Accept: application/json, text/plain, */*
Referer: http://localhost:8887/
sec-ch-ua: "Not_A Brand";v="99", "Google Chrome";v="109", "Chromium";v="109"
sec-ch-ua-mobile: ?1
sec-ch-ua-platform: "Android"
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Mobile Safari/537.36

But in linux environment:
img
The request port is all right.

I have tried other containers in windows environment and did not produce similar problems.

Ah I know whats happening. It's because you are accessing it via "localhost". The frontend does a url check and if it sees that the url is localhost it will use port 5000 for the api requests. This is so that you don't have to do anything special to develop on fireshare when running it locally outside of docker.

Thus why it works correctly when you change the port to 5000 in the dockerfile.

If you left the port at 8080 or something else but instead accessed it via 127.0.0.1 or from a domain name it would work as expected.

Problem solved, thanks

Just saw this and it solved my issue. I was also using localhost to access it.
Since it took me 2hrs to find what was the issue and find the solution here, maybe this should be said somewhere in the documentation btw.

@Chillsmeit Yes, thank you for reminding me of this issue. I will update the README.

Instead of updating the README, I have address the root issue.

You should now be able to update the port mapping in the docker-compose.yml file to any port you want and access it via localhost without issue as long as you are using that port.

#226