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

fanotify events do not work between containers #309

Open
2 of 3 tasks
isage opened this issue May 16, 2018 · 4 comments
Open
2 of 3 tasks

fanotify events do not work between containers #309

isage opened this issue May 16, 2018 · 4 comments

Comments

@isage
Copy link

isage commented May 16, 2018

  • This is a bug report
  • This is a feature request
  • I searched existing issues before opening this one

Expected behavior

fanotify events are emitted for shared volumes in all containers using that volume

Actual behavior

fanotify events for shared volumes do not propagate from one container to another, or from host to container

Steps to reproduce the behavior

Create a container with a directory mounted from host. Create or modify any file in that directory on host. No fanotify events are emitted in container.

Output of docker version:

Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:18:46 2018
 OS/Arch:      linux/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:16:59 2018
  OS/Arch:      linux/amd64
  Experimental: false

Output of docker info:

Containers: 2
 Running: 2
 Paused: 0
 Stopped: 0
Images: 109
Server Version: 18.03.1-ce
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 96
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 apparmor
Kernel Version: 3.19.0-74-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.813GiB
Name: dev-is
ID: HHZR:NR67:YMT4:J3CS:WTVU:WCEU:DTFQ:AJQZ:H77B:YQ5L:OD76:P65V
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.)

@arkanoid87
Copy link

same problem here

@cpuguy83
Copy link
Collaborator

cpuguy83 commented Jun 2, 2019

It seems like fanotify does not work across namespaces or bind mounts.

https://www.spinics.net/lists/kernel/msg2110225.html

But I am really not familiar with it.

@arkanoid87
Copy link

any news on this?

events generated from a container in mounted dir/volume are not detected from fanotify running on host or same container

@thaJeztah
Copy link
Member

See the message above; looks like this is a limitation of the kernel

matthewsilva pushed a commit to matthewsilva/dirmon that referenced this issue Apr 28, 2020
Added Mount-based recursive directory monitoring
	(NOTE: The mount-based monitoring does not behave as
	 expected yet, see docker/for-linux#309
	 and https://www.spinics.net/lists/kernel/msg2110225.html)
	(NOTE: Mount-based monitoring currently only monitors
	 the recurisve file tree when accessed through the newly
	 created mount in /temp/dirmon, which makes this useless
	 as of right now. Looking for a workaround because
	 mount-based monitoring is the only easy way to do
	 recursive monitoring without having to do our own
	 recursive mark-building in every provided directory)
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

4 participants