scouserontour

July 22, 2019

No worries, I just wanted to try your docker version.

Yes I am sure they are the correct device names.

From Unraid CLI:

root@Tower:~# ls -l /dev/sg9
crw-rw---- 1 root cdrom 21, 9 Jul 22 12:25 /dev/sg9
root@Tower:~# ls -l /dev/sr0
brw-rw---- 1 root cdrom 11, 0 Jul 22 12:25 /dev/sr0

July 17, 2019

I am unable to get it detect my USB DVD drive. I have added Extra Parameters: --device /dev/sr0 --device /dev/sg9 but MakeMKV states "The program can't find any usable optical drives".

From the console I can see the DVD has been passed through:

sh-5.0# ls -la /dev/sg*
crw-rw---- 1 root 6 21, 0 Jul 17 16:56 /dev/sg0
crw-rw---- 1 root 6 21, 1 Jul 17 16:56 /dev/sg1
crw-rw---- 1 root 6 21, 2 Jul 17 16:56 /dev/sg2
crw-rw---- 1 root 6 21, 3 Jul 17 16:56 /dev/sg3
crw-rw---- 1 root 6 21, 4 Jul 17 16:56 /dev/sg4
crw-rw---- 1 root 6 21, 5 Jul 17 16:56 /dev/sg5
crw-rw---- 1 root 6 21, 6 Jul 17 16:56 /dev/sg6
crw-rw---- 1 root 6 21, 7 Jul 17 16:56 /dev/sg7
crw-rw---- 1 root 6 21, 8 Jul 17 16:56 /dev/sg8
crw-rw---- 1 root log 21, 9 Jul 17 16:56 /dev/sg9

sh-5.0# ls -la /dev/sr0
brw-rw---- 1 root log 11, 0 Jul 17 16:56 /dev/sr0

If I use the same parameters in a different makemkv docker the drive is detected.

Any suggestions?

Thanks

Paul

User Customizations · January 24, 2019

I believe I have updated the symlinks to the new versions.

When I run:

/etc/rc.d/rc.pulseway start

I get the same error:

Starting Pulseway Daemon ... /usr/sbin/pulsewayd: symbol lookup error: /usr/sbin/pulsewayd: undefined symbol: CRYPTO_num_locks
Error!

User Customizations · January 24, 2019

I've upgraded to OS 6.7.0-rc1 and Pusleway has now stopped working.

This is the error I get:

Starting Pulseway Daemon ... /usr/sbin/pulsewayd: symbol lookup error: /usr/sbin/pulsewayd: undefined symbol: CRYPTO_num_locks
Error!

This is my config to get this far:

cp /boot/pulseway/config.xml /etc/pulseway/config.xml
cp /boot/pulseway/pulseway.id /var/pulseway/pulseway.id
ln -s /lib64/libssl.so.1.1 /usr/lib64/libssl.so.0.9.8
ln -s /lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.0.9.8

# As of version 6.6, you also need one for libidn
ln -s /usr/lib64/libidn.so.12 /usr/lib64/libidn.so.11

/etc/rc.d/rc.pulseway start

Any ideas on what I need to do next?

December 6, 2018

10 hours ago, nuhll said:

"An emergent use of /bin/false, as you identified, is as a null shell for users not allowed to log in. The system in this case will behave exactly as though the shell failed to run."

https://serverfault.com/questions/519215/what-is-the-difference-between-sbin-nologin-and-bin-false

cheers for the link and explanation

December 5, 2018

Hi, this is all very interesting and made me look at my system.

Here is the output I get:

grep adm /boot/config/passwd /etc/passwd
/boot/config/passwd:adm:x:3:4:adm:/var/log:/bin/false
/etc/passwd:adm:x:3:4:adm:/var/log:/bin/false

grep adm /boot/config/shadow /etc/shadow
/boot/config/shadow:adm::14824:0:99999:7:::
/etc/shadow:adm::14824:0:99999:7:::

So if I understand correct, adm doesn't require a password. Any ideas as to why that would be the case, if the default is :*:?

I have setup my router to DNAT to Plex on 32400 and linuxserver/letsencrypt on 80 and 443. I am running Unraid 6.6.6.

Thanks

January 8, 2016

Hi,

Im using v6.1.6 with the following docker containers :ownCloud, Plexmediaserver, TFTP-server (currently stopped) and UniFi.

For a while now I have been having frequent errors in my syslog, as in multiple times per day, and I have been unable to find the cause of the problem. I have been searching the forum with no success.

This is the syslog for today.

Jan 8 00:20:01 Tower sSMTP[881]: Creating SSL connection to host

Jan 8 00:20:02 Tower sSMTP[881]: SSL connection using DHE-RSA-AES256-SHA

Jan 8 00:20:04 Tower sSMTP[881]: Sent mail for xxxxxxxxxxxxx (221 mailfront03.xxxx.xxxx closing connection) uid=0 username=root outbytes=1177

Jan 8 02:15:26 Tower kernel: mdcmd (908): spindown 1

Jan 8 02:15:28 Tower avahi-daemon[17556]: avahi_normalize_name() failed.

Jan 8 02:15:28 Tower avahi-daemon[17556]: avahi_key_new() failed.

Jan 8 02:15:28 Tower avahi-daemon[17556]: server.c: Packet too short or invalid while reading probe record. (Maybe a UTF-8 problem?)

Jan 8 02:15:29 Tower avahi-daemon[17556]: avahi_normalize_name() failed.