QNAP not passing Optical drive to container.
briandaymsft opened this issue · comments
TS-664 with QTS 5.0.1.2248
ContainerStation 2.6.3.592 (2022/12/08)
I'm having trouble getting my USB attached ASUS drive exposed to the container. I've seen a handful of other QNAP threads, but so far the tricks they've done have not worked for me. QTS itself sees/mounts the drive but passing it to the container is the challenge.
After reading the instructions the first thing I did was create a container and look at the logs to get my missing device IDs. I only get one real device ID of /dev/sg4 and the other is a simple hyphen.
[cont-init.d] 95-check-optical-drive.sh: found optical drive [-, /dev/sg4], but it is not usable because:
[cont-init.d] 95-check-optical-drive.sh: --> the host device - is not exposed to the container.
[cont-init.d] 95-check-optical-drive.sh: --> the host device /dev/sg4 is not exposed to the container.
Apparently QNAP shell does not have lsscsi installed. If I run df -Th I do see a UDF partition on /dev/sr0 with a file size matching the DVD currently in the drive.
/dev/sr0 udf 7.3G 7.3G 0 100% /share/external/DEV3302_-1
Running sudo parted -l also sees the drive.
Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only.
Error: /dev/sr0: unrecognised disk label
Model: ASUS BW-16D1HT (scsi)
Disk /dev/sr0: 7854MB
Sector size (logical/physical): 2048B/2048B
Partition Table: unknown
Disk Flags:
Adding --device /dev/sg4 to the docker command leaves only the "the host device - is not exposed" error in the log, but the container does not see the drive with that device alone.
So far, I have tried these steps in order, but so all have resulted in MakeMKV not seeing the drive.
- Creating the container with only --device /dev/sg4
- Creating the container with both --device /dev/sr0 and --device /dev/sg4
- Creating the container using both above devices and with USER_ID and GROUP_ID specified as an admin account.
- Creating the container with --privileged
- Added "input" on the advanced settings on the container, but this caused the container to never fully start or at least not be available via HTTP. After removing this option, the container was again accessible.
- Stopped the container, turned off the drive, turned on the drive, waited for QTS to see the disc, started the container.
I'll keep playing with it to see if I can find a reliable combo/process as others seem to have found their own in the past.
Can also see them in ls - /dev from the host machine.
crw------- 1 admin administrators 21, 0 2023-01-09 13:22 sg0
crw------- 1 admin administrators 21, 1 2023-01-09 13:22 sg1
crw------- 1 admin administrators 21, 2 2023-01-09 13:22 sg2
crw------- 1 admin administrators 21, 3 2023-01-09 13:22 sg3
crw------- 1 admin administrators 21, 4 2023-01-23 10:01 sg4
brw------- 1 admin administrators 11, 0 2023-01-23 10:02 sr0
I should have pasted the command I'm using from shell to create the container.
docker run -d --name=MakeMKV-2 -p 5800:5800 -v /docker/appdata/makemkv:/config:rw -v /share/Media/Movies/RipOutput:/output:rw --device /dev/sr0 --device /dev/sg4 jlesage/makemkv
docker exec MakeMKV-2 lsscsi -g -k
[0:0:0:0] disk Seagate ST14000NM001G-2K SN03 - /dev/sg0
[1:0:0:0] disk Seagate ST14000NM001G-2K SN04 - /dev/sg1
[2:0:0:0] disk Seagate ST14000NM001G-2K SN03 - /dev/sg2
[3:0:0:0] disk Seagate ST14000NM001G-2K SN03 - /dev/sg3
[29:0:0:0] cd/dvd ASUS BW-16D1HT 3.10 - /dev/sg4
Another thread with the same issue led me to what appears to be a resolution.
In short, my /dev/sr0 and /dev/sg4 devices are set so only the built-in admin account has any permission at all. I've never touched these; this appears to be how they are out of the box with QNAP QTS.
crw------- 1 admin administrators 21, 4 2023-01-23 10:01 sg4
brw------- 1 admin administrators 11, 0 2023-01-23 10:02 sr0
If I create the container with USER_ID=0 and GROUP_ID=0 without --privileged, then everything works fine. I now need to go alter those permissions, and setup the container to use an account other than the built-in admin account then retest.
I may be getting somewhere. First, adding r-x with chmod for "other" on sr0 and sg4 seemed to make no difference, even if running the container as another UID/GID.
I just tried this, and it seemed to work. Will play with it a bit and see how it goes. Elsewhere I've seen these perms may reset if the drive is removed and reattached in the future.
- Created a user specifically for the container.
- Ran sudo setfacl -m u:username:rx sr0
- Ran sudo setfacl -m u:username:rx sg4
- Created a container using the user's UID/GID for USER_ID and GROUP_ID, as well as --device for /dev/sr0 and /dev/sg4
- The container sees the drive.
I'm curious as to why you use setfacl vs chown/chmod. Are these modifications retained after reboot?
I'm curious as to why you use setfacl vs chown/chmod. Are these modifications retained after reboot?
I'll experiment a bit to see if they stick. My thought was I'd like to leave the default permissions alone as much as possible, then add an additional access control entry for my needs. It is probably due to a couple past scars I have from modifying default ACLs in a system, then the system or app decided it wanted to set them back to default after a software update. :)
Since my last past I ended up using a group, as you mentioned you did, so the setfacl used -m g:groupname:rx instead and the group has the user I'm running the container under in it as a member.
I rebooted the NAS and the permissions are in fact reset even when using setfacl.
Post-reboot...
getfacl sg4
file: sg4
owner: admin
group: administrators
user::rw-
group::---
other::---
getfacl sr0
file: sr0
owner: admin
group: administrators
user::rw-
group::---
other::---
I added the permissions back, restarted the container, and MakeMKV sees the drive once again. It would be nice to find a way to make these persistent. I come from a couple decades of Windows Server background, so this is some new territory for me.
I tried editing the crontab but the crontab file gets overwritten at restart as well. Since my sever is on 24/7 I figure it wasn't too much of a hassle to reset the permission on reboots.
Have you noticed that /dev/sr0 does not get passed through with the latest iteration of the container?
@J-miahL I'm also having this problem, I'm running the latest version of the container (v23.06.1). Interestingly I have some amount of control over the drive from within the container, running eject /dev/sr0 (my device) causes the drive to eject, however lsscsi specifies - for the drive's device name and makemkv says it does not detect a drive. I can use this drive fine in other systems (nixos, macos, ubuntu) on other hosts and I can use it in a virtual machine on the QNap itself [but I would assume that's true because the VM has drivers]. Additionally the QNap recognizes the disk and even gives it the volume name in the UI. It's really quite curious why the tools in the docker container have such a hard time with it.
I did this to get it working (synology docker)
chmod 777 /dev/sg4That was all I needed for the drive to be pass through to the docker container.
In the logs it still says it isn't, but in the application it's there and reads disks.
After that I added it to the start of the docker CLI script before "docker run" so that it would automatically apply if the NAS was rebooted or drive [dis]connected.