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

PermissionError: No folder could be found for config on update #400

Open
Coysh opened this issue Feb 10, 2025 · 12 comments
Open

PermissionError: No folder could be found for config on update #400

Coysh opened this issue Feb 10, 2025 · 12 comments

Comments

@Coysh
Copy link

Coysh commented Feb 10, 2025

Just updated to the latest image, logs:

aloja  | Maloja is starting!
maloja  | Traceback (most recent call last):
maloja  |   File "<frozen runpy>", line 189, in _run_module_as_main
maloja  |   File "<frozen runpy>", line 148, in _get_module_details
maloja  |   File "<frozen runpy>", line 112, in _get_module_details
maloja  |   File "/venv/lib/python3.12/site-packages/maloja/__init__.py", line 4, in <module>
maloja  |     from .pkg_global import conf
maloja  |   File "/venv/lib/python3.12/site-packages/maloja/pkg_global/conf.py", line 132, in <module>
maloja  |     maloja_dir_config = find_good_folder('config')
maloja  |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^
maloja  |   File "/venv/lib/python3.12/site-packages/maloja/pkg_global/conf.py", line 120, in find_good_folder
maloja  |     raise PermissionError(f"No folder could be found for {datatype}")
maloja  | PermissionError: No folder could be found for config
maloja  | 
maloja  | Maloja is starting!
maloja  | Traceback (most recent call last):
maloja  |   File "<frozen runpy>", line 189, in _run_module_as_main
maloja  |   File "<frozen runpy>", line 148, in _get_module_details
maloja  |   File "<frozen runpy>", line 112, in _get_module_details
maloja  |   File "/venv/lib/python3.12/site-packages/maloja/__init__.py", line 4, in <module>
maloja  |     from .pkg_global import conf
maloja  |   File "/venv/lib/python3.12/site-packages/maloja/pkg_global/conf.py", line 132, in <module>
maloja  |     maloja_dir_config = find_good_folder('config')
maloja  |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^
maloja  |   File "/venv/lib/python3.12/site-packages/maloja/pkg_global/conf.py", line 120, in find_good_folder
maloja  |     raise PermissionError(f"No folder could be found for {datatype}")
maloja  | PermissionError: No folder could be found for config

compose.yaml

version: "3.8"
services:
  maloja:
    image: krateng/maloja:latest
    container_name: maloja
    restart: unless-stopped
    ports:
      - 42010:42010
      - 42011:42011
    volumes:
      - ./config:/maloja/config
      - ./database:/maloja/database
      - ./logs:/maloja/logs
      - ./import:/maloja/import
    environment:
      - PUID=1000
      - PGID=1000
      - MALOJA_SKIP_SETUP=yes
      - MALOJA_FORCE_PASSWORD=password
networks: {}
@janaxhell
Copy link

Happening the same to me after update.

@Coysh
Copy link
Author

Coysh commented Feb 10, 2025

Turns out it was storage space for me, fixing that sorted things out

@janaxhell
Copy link

I have 160 Gb of free space where Maloja sits, not a storage issue for me.
My log is actually different, but happened exactly after update:

Maloja is starting!
Maloja v3.2.
https://github.com/krateng/maloja
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/venv/lib/python3.12/site-packages/maloja/__main__.py", line 82, in <module>
    @mainfunction({"l":"level","v":"version","V":"version"},flags=['version','include_images','prefer_existing'],shield=True)
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/doreah/control.py", line 47, in decorator
    wrapper()
  File "/venv/lib/python3.12/site-packages/doreah/control.py", line 41, in wrapper
    result = func(*args,**kwargs)
             ^^^^^^^^^^^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/maloja/__main__.py", line 113, in main
    return action(*args,**kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/maloja/__main__.py", line 36, in run_server
    setup()
  File "/venv/lib/python3.12/site-packages/maloja/setup.py", line 47, in setup
    copy_initial_local_files()
  File "/venv/lib/python3.12/site-packages/maloja/setup.py", line 36, in copy_initial_local_files
    shutil.copytree(src, dst, dirs_exist_ok=True)
  File "/usr/lib/python3.12/shutil.py", line 600, in copytree
    return _copytree(entries=entries, src=src, dst=dst, symlinks=symlinks,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/shutil.py", line 554, in _copytree
    raise Error(errors)
shutil.Error: [(<DirEntry 'predefined'>, '/mljdata/rules/predefined', '[Errno 1] Operation not permitted'), (PosixPath('/venv/lib/python3.12/site-packages/maloja/data_files/config/rules'), PosixPath('/mljdata/rules'), '[Errno 1] Operation not permitted')]

@krateng
Copy link
Owner

krateng commented Feb 10, 2025

Is your /mljdata/rules folder writable to the docker user? Can you check making it full permissions (777) to make sure?

@janaxhell
Copy link

janaxhell commented Feb 10, 2025

I've set all my containers to use my admin user, so it reflects 998:100. If now it's not accessible, something changed in the code, it worked fine for at least a year without me touching anything and Watchtower updating when legit.
Anyway no, it seems that /rules is not 777

root@openmediavault:/srv/dev-disk-by-uuid-5b67514d-485e-4306-873e-b1cbb54ccf99/Config/Maloja/malojadata# find ./ -perm 777 -type f
./.lastmalojaversion
./apikeys.yml
./settings.md
./cache/images.sqlite
./settings.ini
./malojadb.sqlite
./auth/auth.ddb

The folder /rules is present, but not seen as 777 and it's empty. Timestamp says created 02/06/2023, so one and a half year ago. Never given problems.

version: '3.3'
services:
    maloja:
        image: krateng/maloja
        environment:
            - PUID=998
            - PGID=100
            - MALOJA_DATA_DIRECTORY=/mljdata
            - MALOJA_FORCE_PASSWORD=xxxxxxxxxxx
        ports:
            - '42010:42010'
        restart: unless-stopped
        volumes:
            - '/srv/dev-disk-by-uuid-5b67514d-485e-4306-873e-b1cbb54ccf99/Config/Maloja:/mljdata'

@janaxhell
Copy link

Just to try, I have chmod 777 rules/ , but it keeps spitting the same error.
Any advice?

@krateng
Copy link
Owner

krateng commented Feb 12, 2025

I can only really imagine permissions errors, not sure why it would change after an update. Is the sub-directory predefined also 777?

@janaxhell
Copy link

janaxhell commented Feb 12, 2025

I have chmodded to -R 777 rules/ and all its contents.
If you tell me what to keep to maintain all my data, I can try to completely erase and redeploy to see if it fixes.
Anyway there is something wrong somewhere, because I never touch a working container after deploy, and maloja always worked fine between updates.
For context, I have 83 containers running on the same machine (OMV 6 x64) with no permission problem.

EDIT
There is definitely something wrong in the last update. I have forced the deploy to previous 3.2.3 version and it works fine, no error, i can access the UI.

Maloja v3.2.3
https://github.com/krateng/maloja
Various external services can be used to display images. If not enough of them are set up, only local images will be used.
	Last.fm API Key found.
	Spotify API ID found.
	Spotify API Secret found.
	Currently not using a TheAudioDB API Key for image display.
Password has been set.
[server] Starting up Maloja server...
[server] Listening on *:42010
[dbcache] Cache: Size: 2538 | Hits: 8/2546 | Estimated Memory: 6 MiB
[dbcache] Entity Cache: Size: 2 | Hits: 0/3 | Estimated Memory: 1 KiB
[dbcache] System RAM Utilization: 80.0%
[dbcache] 80.0% RAM usage, clearing cache!
[dbcache] Cache: Size: 0 | Hits: 0/0 | Estimated Memory: 72 B
[dbcache] Entity Cache: Size: 0 | Hits: 0/0 | Estimated Memory: 72 B
[dbcache] System RAM Utilization: 80.0%
[sqldb] Database Cleanup...
[sqldb] Database Cleanup complete!

@krateng
Copy link
Owner

krateng commented Feb 12, 2025

Could you delete all the files from inside /mljdata/rules/predefined, and then also temporarily move all files out of /mljdata/rules if you have any. If that makes it work, try moving back your custom rule files.

@janaxhell
Copy link

No, it doesn't solve.
Also now after doing as you asked, I reverted to 3.2.3, but now it doesn't work as well anymore even chmodding to 777 with this error:

Maloja is starting!
Traceback (most recent call last):
  File "<frozen runpy>", line 189, in _run_module_as_main
  File "<frozen runpy>", line 148, in _get_module_details
  File "<frozen runpy>", line 112, in _get_module_details
  File "/venv/lib/python3.12/site-packages/maloja/__init__.py", line 4, in <module>
    from .pkg_global import conf
  File "/venv/lib/python3.12/site-packages/maloja/pkg_global/conf.py", line 139, in <module>    os.makedirs(maloja_dir_config,exist_ok=True)  File "<frozen os>", line 225, in makedirs
PermissionError: [Errno 13] Permission denied: '/mljdata:3.2.3'

Also both /rules/rules.info and all files inside /predefined are default, I compared those created by new deploy by-byte and they are the same.

@krateng
Copy link
Owner

krateng commented Feb 13, 2025

Alright guess a redeploy it is then, you need your malojadb.sqlite file most of all, and potentially your settings.ini and apikeys.yml. If you have custom images, your images folder; and all non-symlink files in rules if you have custom rules (the ones you manually created basically). I'd temporarily backup the whole data folder just in case, but those should have all you need.

@janaxhell
Copy link

Yes, a complete erase + backup-restore did the trick, it works now. Wonder what happened between updates. Thanks!

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

No branches or pull requests

3 participants