[GH-ISSUE #894] Sharing volume on macOS: "failed to determine if storage supports xattr" #137

New issue

Closed

opened 2026-03-03 12:08:38 +03:00 by kerem · 6 comments

kerem commented

2026-03-03 12:08:38 +03:00

Owner

Originally created by @tdeg on GitHub (Aug 18, 2022).
Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/894

Hi. I am trying to mount a volume between my host machine and docker container. My goal is be able to see the data that is getting uploaded outputted to a folder in my project's directory. After reading through the codebase my current configuration looks like this:

services:
  my_service:
    build:
      context: "."
      dockerfile: dev.Dockerfile
    depends_on:
        - db
    volumes:
      - .:/myservice
      - ./storage:/storage
    environment:
      STORAGE_EMULATOR_HOST: http://storage:4443
    ports:
      - 8080:8080
    networks:
      - network

  storage:
    image: fsouza/fake-gcs-server
    volumes:
      - ./storage:/storage
    ports:
      - 4443:4443
    networks:
      - network
    command:
      - "-scheme" 
      - "http"
      - "-backend" 
      - "filesystem"
  networks:
    network:

When running compose up, the container crashes with the following error:

level=fatal msg="couldn't start the server" error="failed to determine if \"/storage/\" supports xattr, consider using a different storage backend or a filesystem that supports it (e.g. not tmpfs on Linux): xattr.get /storage/ user.metadata: operation not supported"

If I remove the volume from the storage definition the container builds and I can access the buckets via cURL. Any help is greatly appreciated.

Originally created by @tdeg on GitHub (Aug 18, 2022). Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/894 Hi. I am trying to mount a volume between my host machine and docker container. My goal is be able to see the data that is getting uploaded outputted to a folder in my project's directory. After reading through the codebase my current configuration looks like this: ``` services: my_service: build: context: "." dockerfile: dev.Dockerfile depends_on: - db volumes: - .:/myservice - ./storage:/storage environment: STORAGE_EMULATOR_HOST: http://storage:4443 ports: - 8080:8080 networks: - network storage: image: fsouza/fake-gcs-server volumes: - ./storage:/storage ports: - 4443:4443 networks: - network command: - "-scheme" - "http" - "-backend" - "filesystem" networks: network: ``` When running compose up, the container crashes with the following error: ``` level=fatal msg="couldn't start the server" error="failed to determine if \"/storage/\" supports xattr, consider using a different storage backend or a filesystem that supports it (e.g. not tmpfs on Linux): xattr.get /storage/ user.metadata: operation not supported" ``` If I remove the volume from the storage definition the container builds and I can access the buckets via cURL. Any help is greatly appreciated.

kerem closed this issue

2026-03-03 12:08:38 +03:00

kerem commented

2026-03-03 12:08:39 +03:00

Author

Owner

@fsouza commented on GitHub (Aug 18, 2022):

Hmm yeah that won't work with the way we store metadata in the filesystem backend (we use extended attributes, which are not supported by Docker for Mac). What we usually recommend is to use the shared volume as the source and let fake-gcs-server manage the storage root, but in that case you wouldn't be able to see the files/directories in the host. Can you provide more details on your use case so we can figure something out?

@fsouza commented on GitHub (Aug 18, 2022): Hmm yeah that won't work with the way we store metadata in the filesystem backend (we use extended attributes, which are [not supported by Docker for Mac](https://docker-docs.netlify.app/docker-for-mac/osxfs/#extended-attributes)). What we usually recommend is to use the shared volume as the source and let fake-gcs-server manage the storage root, but in that case you wouldn't be able to see the files/directories in the host. Can you provide more details on your use case so we can figure something out?

kerem commented

2026-03-03 12:08:39 +03:00

Author

Owner

@tdeg commented on GitHub (Aug 18, 2022):

Ah okay. For the time being I will verify uploads via cURL but my use case is web scraping so I would love to be able to see the actual data that's being scraped outputted to a local dir. I have other ways of doing this but I was trying to simulate GCP much as possible locally.

@tdeg commented on GitHub (Aug 18, 2022): Ah okay. For the time being I will verify uploads via cURL but my use case is web scraping so I would love to be able to see the actual data that's being scraped outputted to a local dir. I have other ways of doing this but I was trying to simulate GCP much as possible locally.

kerem commented

2026-03-03 12:08:39 +03:00

Author

Owner

@fsouza commented on GitHub (Aug 18, 2022):

We do have a fallback in place for Windows where xattr isn't supported at all (we store the metadata in a JSON file). Perhaps what we could do is fallback automatically to the json format whenever the filesystem root doesn't support xattr, instead of assuming that anything that's not Windows supports it. Shouldn't be too hard I think

@fsouza commented on GitHub (Aug 18, 2022): We do have a fallback in place for Windows where xattr isn't supported at all (we store the metadata in a JSON file). Perhaps what we could do is fallback automatically to the json format whenever the filesystem root doesn't support xattr, instead of assuming that anything that's not Windows supports it. Shouldn't be too hard I think

kerem commented

2026-03-03 12:08:39 +03:00

Author

Owner

@fsouza commented on GitHub (Aug 18, 2022):

@tdeg can you try #897?

@fsouza commented on GitHub (Aug 18, 2022): @tdeg can you try #897?

kerem commented

2026-03-03 12:08:39 +03:00

Author

Owner

@tdeg commented on GitHub (Aug 18, 2022):