Closed perlman closed 3 years ago
Fixed in version 1.14.1 !
If you need the $CLOUD_FILES_HOME
feature, let's open another issue.
Thanks William!
The problem still exists with cloud-volume:
File "/opt/services/transform_service_dev/env/lib/python3.8/site-packages/cloudvolume/connectionpools.py", line 10, in <module>
from .secrets import google_credentials, aws_credentials
File "/opt/services/transform_service_dev/env/lib/python3.8/site-packages/cloudvolume/secrets.py", line 12, in <module>
CLOUD_VOLUME_DIR = mkdir(os.path.join(HOME, '.cloudvolume'))
File "/opt/services/transform_service_dev/env/lib/python3.8/site-packages/cloudvolume/lib.py", line 135, in mkdir
os.makedirs(path)
File "/usr/lib/python3.8/os.py", line 223, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/var/www/.cloudvolume'
Is this a leftover from before cloud-files?
Yep, sorry about that.
It's not completely obsolete because CV needs to check for boss and chunked graph tokens that aren't applicable to CloudFiles.
CV 3.1.1 is out and should fix at least that problem.
Cloud-files fails to start when run in a read-only environment:
The culprit appear to be a hard coded use of directories in the home directory here.
I am using cloud-volume to access a local volume, so authentication & secrets should not be required.
Apologies if I'm missing some obvious work around. One thought I have would be to allow something like $CLOUD_FILES_HOME to be used an override, allowing me to set the path to a temp directory.