Failing to start with NFS-mounted output

[34will]

When the /output volume is mounted to an NFS (v4) share, the container fails to start with the error:

chown: /output: Invalid argument
[cont-init.d] 90-makemkv.sh: ERROR: Failed to take ownership and no write permission on /output.
[cont-init.d] 90-makemkv.sh: exited 1.

However I can confirm that I can write to the location.

[jlesage]

Did you check that the user configured as USER_ID/GROUP_ID does have write access ? This is what the failed check is doing.

[34will]

Yes, it does seem to have write access. I spun up a second container of justcontainers/base-alpine:latest to test the s6 compatibility, with that volume mounted in it. I then created a script to mimic the ownership tests:

#!/usr/bin/with-contenv sh

if s6-setuidgid 1000:1000 [ ! -w /output ]; then
        echo "No Write Access"
else
        echo "Write Access"
fi

if s6-setuidgid 1000:1000 mkdir /output/temp ; then
        echo "Write Access"
else
        echo "No Write Access"
fi

if [ ! -w /output ]; then
        echo "No Write Access"
else
        echo "Write Access"
fi

(I know the chown doesn't work because of the above errors) After running the above, I got the following output:

No Write Access
Write Access
Write Access

And I can verify that the /output/temp directory was successfully created.

So (to me) it looks like a weird interaction between s6-setuidgid and the bash [ -w <folder> ] check. I have had problems in the past with these kinds of volumes on my system, (NFSv4 on TrueNAS Core, i.e. FreeBSD) but they've largely worked because the other containers I've run just try the chown and assume that's good enough 😅 which is why is my pull request #116 I just added a flag to disable the check, since my above test script seems to indicate no problems actually writing to it.

Also, my issue and pull request on your HandBrake repo are the same issue and resolution.

[jlesage]

To have a complete picture of the problem, could you provide the output of ls -ld /output ?

I think that it should be possible to fix the check itself.

[34will]

ls -ld /output gives:

drwxrwxr--    3 42949672 42949672         3 May 19 00:48 /output/

[jlesage]

I adjusted the write test. Can you try the latest image to see if it fixes your issue ?

[34will]

Yes, that works great! Thank you for changing it. I do still have to run it with the TAKE_CONFIG_OWNERSHIP flag, because the /config folder has the same issue, so I don't know if you'd want to change the check there too.

Also, I know it's a lot to ask, but would you be able to adapt https://github.com/jlesage/docker-handbrake and https://github.com/jlesage/docker-mkvtoolnix to use this check too? I want to use them too, but this issue stops me with them as well. Much thanks!

[jlesage]

Thanks for confirming that the /output folder is now working for you. I will do the change for the /config folder as well.

And yes, I will make sure other contains are also fixed. There are no new images yet, but the fix for the /output folder is already propagated to other containers.

[Wobak]

Shouldn't you simply use the mount type nfs for the volume itself instead of tweaking that in the container?

[jlesage]

@34will, do you still have the same setup? I would be interested in your NFS server configuration.