I did docker compost up, everything seemed to install correctly, I don’t see any errors mentioned, but the app is not working on my system.
Any ideas?
1 Like
Hi there! I just ran into the same issue. Have you solved this?
➜ vidly docker-compose up
Starting vidly_db_1 ... done
Recreating vidly_backend_1 ... done
Recreating vidly_frontend_1 ... done
Attaching to vidly_db_1, vidly_backend_1, vidly_frontend_1
db_1 | 2022-09-15T04:18:48.701+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
backend_1 | /usr/local/bin/docker-entrypoint.sh: exec: line 8: ./docker-entrypoint.sh: Permission denied
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=500dd7be649f
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] db version v4.0.28
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] git version: af1a9dc12adcfa83cc19571cb3faba26eeddac92
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] allocator: tcmalloc
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] modules: none
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] build environment:
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] distmod: ubuntu1604
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] distarch: aarch64
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] target_arch: aarch64
db_1 | 2022-09-15T04:18:48.704+0000 I CONTROL [initandlisten] options: { net: { bindIpAll: true } }
db_1 | 2022-09-15T04:18:48.705+0000 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
db_1 | 2022-09-15T04:18:48.705+0000 I STORAGE [initandlisten]
db_1 | 2022-09-15T04:18:48.705+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
db_1 | 2022-09-15T04:18:48.705+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
db_1 | 2022-09-15T04:18:48.705+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=482M,cache_overflow=(file_max=0M),session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
db_1 | 2022-09-15T04:18:48.856+0000 I STORAGE [initandlisten] WiredTiger message [1663215528:856862][1:0xffffb8f1c000], txn-recover: Main recovery loop: starting at 16/4864 to 17/256
db_1 | 2022-09-15T04:18:48.934+0000 I STORAGE [initandlisten] WiredTiger message [1663215528:934235][1:0xffffb8f1c000], txn-recover: Recovering log 16 through 17
db_1 | 2022-09-15T04:18:49.001+0000 I STORAGE [initandlisten] WiredTiger message [1663215529:1510][1:0xffffb8f1c000], txn-recover: Recovering log 17 through 17
db_1 | 2022-09-15T04:18:49.040+0000 I STORAGE [initandlisten] WiredTiger message [1663215529:40523][1:0xffffb8f1c000], txn-recover: Set global recovery timestamp: 0
db_1 | 2022-09-15T04:18:49.050+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
db_1 | 2022-09-15T04:18:49.051+0000 I STORAGE [initandlisten] Starting to check the table logging settings for existing WiredTiger tables
db_1 | 2022-09-15T04:18:49.054+0000 I CONTROL [initandlisten]
db_1 | 2022-09-15T04:18:49.054+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
db_1 | 2022-09-15T04:18:49.054+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
db_1 | 2022-09-15T04:18:49.054+0000 I CONTROL [initandlisten]
db_1 | 2022-09-15T04:18:49.057+0000 I STORAGE [initandlisten] Finished adjusting the table logging settings for existing WiredTiger tables
db_1 | 2022-09-15T04:18:49.061+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
db_1 | 2022-09-15T04:18:49.064+0000 I NETWORK [initandlisten] waiting for connections on port 27017
vidly_backend_1 exited with code 126
frontend_1 |
frontend_1 | > vidly-frontend@0.1.0 start /app
frontend_1 | > react-scripts start
frontend_1 |
frontend_1 | ℹ ｢wds｣: Project is running at http://172.18.0.3/
frontend_1 | ℹ ｢wds｣: webpack output is served from
frontend_1 | ℹ ｢wds｣: Content not from webpack is served from /app/public
frontend_1 | ℹ ｢wds｣: 404s will fallback to /
frontend_1 | Starting the development server...
frontend_1 |
frontend_1 | Browserslist: caniuse-lite is outdated. Please run:
frontend_1 | npx browserslist@latest --update-db
frontend_1 |
frontend_1 | Why you should do it regularly:
frontend_1 | https://github.com/browserslist/browserslist#browsers-data-updating
frontend_1 | Compiled successfully!
frontend_1 |
frontend_1 | You can now view vidly-frontend in the browser.
frontend_1 |
frontend_1 | Local: http://localhost:3000
frontend_1 | On Your Network: http://172.18.0.3:3000
frontend_1 |
frontend_1 | Note that the development build is not optimized.
frontend_1 | To create a production build, use npm run build.
frontend_1 |
Granting permissions didn’t help.
Updating the Docker desktop from 4.2.0 to 4.12.0 fixed the issue.
It still doesn’t work on 4.12.0. To make it works I had to change docker-compose.yml on line 19 like this:
command: ["sh", "docker-entrypoint.sh"]
3 Likes
Thank you!! That worked for me as well
I had the same issue! and this line fixed it! Thank you for the fix and @codewithmosh maybe it’s a idea to update the zipfile 
Thank you @KaMZaTa ! It worked for me.