Locking files while using Bind mounts

Hi All,

I am using a Ubuntu VM and trying to host docker containers on it.

The docker container is running a C# application (Net Core). In my code, I am trying to acquire an exclusive lock on a file and it is not working reliably. Here is the scenario:

1. I am defining mount binds as part of create options.
{
“HostConfig”: {
“Binds”: [
“/var/foo:/var/foo”
]
}
}

I also tried adding
“Mounts”: [
{
“Type”: “bind”,
“Source”: “/var/lib/azuremediaservices”,
“Destination”: “/var/lib/azuremediaservices”,
“Mode”: “”,
“RW”: true,
“Propagation”: “shared”
}
]
but it did not help.

2. I create my first container with the above setting and as part of the code I create a file /var/foo/lock.lock and try to acquire an exclusive lock using FileStream C# API.

3. The code runs fine and no exception is thrown while lock is acquired. I can see the file showing up on the host.

4. When I create the second container with identical settings, I expect the second container code to fail when it tries to get the lock. This works fine the first time and I can see the failure.

5. When I shutdown both the container and look at the host, I can still see the lock file. (That is also as expected)

6. When I start container 1, it is able to acquire the lock again.

7. When I start container 2, it is also able to acquire the lock and it does not fail.

8. From this point on, they lock is not honored unless, I delete /var/foo on the host and then it gets recreated as part of container 1 execution.

Any clue what am I doing wrong? Do I need any specific settings so that the lock is honored all the time?

I am suspecting this has something to do with bind propagation or how the file access is passed between container and the host.

As a side note: content of other files are being shared between containers as expected. Honoring the lock is the only issue.

Thanks
VB

I was able to figure out the issue. It had nothing to do with bind mounts. It was a bug in my code where the FileStream was getting disposed prematurely allowing other module to acquire the lock in an unpredictable manner.
We can close this topic.

Thanks.