standardnotes / syncing-server

[Deprecated: Use our new Node server: https://github.com/standardnotes/syncing-server-js]
https://standardnotes.org
GNU Affero General Public License v3.0
209 stars 48 forks source link

standardnotes_app container crashes with "Permission denied" #164

Closed va1entin closed 3 years ago

va1entin commented 3 years ago

I've been trying to set up standardnotes on my Raspberry Pi 4B with 4GB RAM using docker-compose as advised in the documentation here.

The image build succeeds but afterwards the standardnotes_app_1 container keeps crashing with this error in the logs:

Prestart Step 3/4 - Migrating database
/usr/local/lib/ruby/2.6.0/fileutils.rb:239:in `mkdir': Permission denied @ dir_s_mkdir - /syncing-server/tmp (Errno::EACCES)
        from /usr/local/lib/ruby/2.6.0/fileutils.rb:239:in `fu_mkdir'
        from /usr/local/lib/ruby/2.6.0/fileutils.rb:217:in `block (2 levels) in mkdir_p'
        from /usr/local/lib/ruby/2.6.0/fileutils.rb:215:in `reverse_each'
        from /usr/local/lib/ruby/2.6.0/fileutils.rb:215:in `block in mkdir_p'
        from /usr/local/lib/ruby/2.6.0/fileutils.rb:200:in `each'
        from /usr/local/lib/ruby/2.6.0/fileutils.rb:200:in `mkdir_p'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/store.rb:79:in `dump_data'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/store.rb:59:in `commit_transaction'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/store.rb:50:in `block in transaction'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/store.rb:46:in `synchronize'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/store.rb:46:in `transaction'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/cache.rb:139:in `push_paths_locked'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/cache.rb:122:in `block in reinitialize'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/cache.rb:116:in `synchronize'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/cache.rb:116:in `reinitialize'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache/cache.rb:16:in `initialize'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache.rb:45:in `new'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/load_path_cache.rb:45:in `setup'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap.rb:26:in `setup'
        from /usr/local/bundle/gems/bootsnap-1.4.8/lib/bootsnap/setup.rb:31:in `<top (required)>'
        from /syncing-server/config/boot.rb:4:in `require'
        from /syncing-server/config/boot.rb:4:in `<top (required)>'
        from bin/rails:3:in `require_relative'
        from bin/rails:3:in `<main>'

I'll gladly provide more info or test solutions.

dgraziotin commented 3 years ago

Ugly workaround (likey, I have the same issue on a Synology and hope it works for the RPi).

Mount the folders /syncing-server/tmp, /syncing-server/log, and /syncing-server/db separately (create the dirs outside standardnote folder) and chmod -R 777 the hell of them.

Your resulting volumes entry should look like this (I mount them under /volume1/docker/standardnotes-data)

volumes:
      - .:/syncing-server
      - /volume1/docker/standardnotes-data/tmp:/syncing-server/tmp
      - /volume1/docker/standardnotes-data/log:/syncing-server/log
      - /volume1/docker/standardnotes-data/db:/syncing-server/db
bkarakoc commented 3 years ago

I'm having the same issue. I've tried the solution from @dgraziotin but now it's giving an error for /syncing-server/tmp/cache directory with the same message. @va1entin were you able to fix it?

dgraziotin commented 3 years ago

@devgrips are you by chance running the container as root? I found out it was the real issue, related to all those permission errors and others I thought I had.

karolsojko commented 3 years ago

This might be related to #99

After talking to @standarius we are considering to revert the mentioned PR above until a proper fix is applied that will allow linux Docker users to run it without "permissions denied" issues.