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.

Sign up for GitHub

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

Jump to bottom

Cannot access optical drive on QNAP #53

Open
derekbsnider opened this issue Jul 19, 2019 · 29 comments
Open

Cannot access optical drive on QNAP #53

derekbsnider opened this issue Jul 19, 2019 · 29 comments

Comments

@derekbsnider
Copy link

I bought a QNAP because it was supposed to be easier to get 3rd party apps running, but it seems like Synology won here. Still, I believe it should be possible to get this working, but I'm having a lot of issues trying to figure it out.

Can someone here explain how to get this working on a QNAP with "Docker Station"? I have a USB Blu-Ray drive, which I can see from FileStation.

Thanks in advance
@jlesage
Copy link
Owner

jlesage commented Jul 21, 2019

Is it only for the optical drive part that you need help with? Are you able to create the container and access to UI of MakeMKV?

@derekbsnider
Copy link
Author

Yes, I can create the container and access the UI -- It says that no optical drive was found.

@jlesage
Copy link
Owner

jlesage commented Jul 24, 2019

Ok, so the problem is probably that you didn't exposed the required devices to the container.
If you look at the container's log, you should see messages telling that your drive is detected but is not working. Messages will also tell you which devices to expose.

@derekbsnider
Copy link
Author

Do you know how to expose the device using QNAP's "Container Station"?

@jlesage
Copy link
Owner

jlesage commented Jul 26, 2019

I don't have a QNAP to look at, but if you edit container's settings, I think there is a "Device" section.

@RyanRoberts210
Copy link

Today, in Container Station, Settings, Advanced Settings, Device, there is a drop down menu with 5-6 choices. I can get the drive recognized enough by choosing Input and setting the Privileged checkbox. This allows the container to see it (sg# only) and for me to rip with it. The auto-eject does not work.

@derekbsnider
Copy link
Author

Today, in Container Station, Settings, Advanced Settings, Device, there is a drop down menu with 5-6 choices. I can get the drive recognized enough by choosing Input and setting the Privileged checkbox. This allows the container to see it (sg# only) and for me to rip with it. The auto-eject does not work.

How do you actually mount the drive inside the container?

@RyanRoberts210
Copy link

If you follow those steps during your container setup this "mounts" the drive in the container, i.e. makes it accessible to the container. You should see it detected in the Console of Container Station when it starts up the container. This all assumes you are using Container Station to setup the container and not ssh or something else.

@derekbsnider
Copy link
Author

derekbsnider commented May 27, 2020 via email

@RyanRoberts210
Copy link

RyanRoberts210 commented May 27, 2020 via email

@derekbsnider
Copy link
Author

derekbsnider commented May 27, 2020 via email

@RyanRoberts210
Copy link

RyanRoberts210 commented May 27, 2020 via email

@jlesage
Copy link
Owner

jlesage commented Jun 1, 2020

Could you provide the output of:

ls -l /dev/

and

docker exec <name of the container> lsscsi -g -k

@derekbsnider
Copy link
Author

derekbsnider commented Jun 2, 2020 via email

@JSeluga
Copy link

JSeluga commented Dec 30, 2020

Did this ever get figured out on a QNAP device. I am running into the same issues.

@J-miahL
Copy link

J-miahL commented May 28, 2021

The only way I am able to expose the drive is in privilege mode, and running and stopping the container once prior to connecting the drive. I modified the permission for both sr0 and sg4 to R-X for everyone. The UID and GUID is setup to user/everyone not admin/administration. It might just be a QNAP limitations, since I have another container that requires privilege mode to expose the render for hardware acceleration.

@briandaymsft
Copy link

Did this ever get figured out on a QNAP device. I am running into the same issues.

I am also curious if @derekbsnider figured out a way as I'm faced with pretty much the same issue now. For all intents and purposes, it appears the device is exposed to my container, but MakeMKV itself doesn't find it.

@derekbsnider
Copy link
Author

@briandaymsft I never got it working, but I didn't end up trying the last few things recommended (modifying /dev/sr0 /dev/sg4 permissions, etc). I wasn't sure if it was just the type of drive I'm using is not compatible with the QNAP hardware, but I'm up for trying again.

I would really like to be able to rip directly to the QNAP if possible, as it would reduce any network bottlenecks, and I was hoping to set things up to just be able to put a DVD or BluRay into the drive, have it automatically rip it, and open the drive when complete, so it was completely automated (aside from interaction with the physical discs).

@briandaymsft
Copy link

Thanks for the update @derekbsnider , I'm going through some of the same steps over here, #160, so if I find anything that works I'll share it.

@J-miahL
Copy link

J-miahL commented Jan 23, 2023 via email

@briandaymsft
Copy link

For less advance users, boot the NAS first and then plug in the drive. After that you can create a privilege container. I don't remember if you have to select anything under device, but you may need to expose USB devices. The container should see the device. Note you must re-plug the drive if the container is stopped for any reason prior to restarting the container.

So far, I've not seen any change in behavior when making it a privileged container. Maybe my sequence of events is off. I could try it again just to see if I can force it, but I'd prefer to not run privileged if I can. Even if it would show up once while privileged it would give me hope there's a way to make it work perhaps with your other method. :)

@briandaymsft
Copy link

So far, I've not seen any change in behavior when making it a privileged container. Maybe my sequence of events is off. I could try it again just to see if I can force it, but I'd prefer to not run privileged if I can. Even if it would show up once while privileged it would give me hope there's a way to make it work perhaps with your other method. :)

I tried again with --privileged and not specifying any --device values, and I tried with --privileged and the two --device values, still nothing. Really odd. I'll try the permissions method sometime tomorrow.

@J-miahL
Copy link

J-miahL commented Jan 23, 2023 via email

@derekbsnider
Copy link
Author

Are you setting up the container via terminal or using the Container App? The first method can only be done via terminal.

Could you please provide details on how to properly set this up and get it working via the terminal?

Thank you! :)

@J-miahL
Copy link

J-miahL commented Jan 23, 2023 via email

@J-miahL
Copy link

J-miahL commented Jan 23, 2023 via email

@briandaymsft
Copy link

Are you setting up the container via terminal or using the Container App?

I'm doing it via SSH. My trials and tribulations are over in #160 , not trying to detail this one tooooo much. :)

@briandaymsft
Copy link

briandaymsft commented Jan 24, 2023 •
edited
Loading

For the more advanced user, I would recommend setting up a shell and giving rw permissions to the /dev/srx and /dev/sgy that corresponds to the drive. Make sure the user running the container is the same as the user or part of the group granted rw access. Then make sure you expose the device with the - device variable when setting up the container. Notes these permission erase upon reboot.

I now have initial success, @J-miahL. Based on your tip above it got me going in the proper direction. :)

Here are my /dev permissions for the necessary devices (for my setup) are currently, so only the 'admin' account has access and nobody else.

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 created a container with the following command via shell, and for the first time specified zero for both USER_ID and GROUP_ID given what I saw above to see if it behaves any different. I'll change this later once I figure out the magic combo so the container isn't running as admin.

docker run -d --name=MakeMKV-2 -p 5800:5800 -v /docker/appdata/makemkv:/config:rw -v /share/Movies/:/output:rw --device /dev/sr0 --device /dev/sg4 -e USER_ID=0 -e GROUP_ID=0 jlesage/makemkv

With the above command, boom, MakeMKV sees my USB ASUS drive and ripped on the first try. 👍🏻

Now I should just have to go back and setup the permissions appropriately with a user other than admin. :) Thank you!

@briandaymsft briandaymsft mentioned this issue Jan 24, 2023
Open
@J-miahL
Copy link

J-miahL commented Jan 24, 2023 via email

@jlesage jlesage mentioned this issue Feb 13, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@jlesage @derekbsnider @JSeluga @briandaymsft @RyanRoberts210 @J-miahL