[mythtv-users] Ubuntu Mythbackend issue

[Stephen Worthington]

On Sun, 13 May 2018 18:56:42 -0500, you wrote:

>On Sun, May 13, 2018 at 11:55 AM Stephen Worthington <
>stephen_agent at jsw.gen.nz> wrote:
>
>> On Sun, 13 May 2018 10:47:45 -0500, you wrote:
>>
>> >I see "can't write to" issue and some "AutoExpire: CalcParams(): Max
>> >required Free Space: 1.0 GB w/freq: 15 min" thing which when I search
>> seems
>> >to be some TV Tuner issue
>>
>> You can ignore the "Autoexpire:" messages - they are normal.  It just
>> means that mythbackend has looked at all the storage groups and
>> checked that they have enough free space.  If they do not, it will
>> choose some recordings to expire to create enough free space.  Always
>> make sure your storage groups have enough free space unless you want
>> old recordings to expire.  I leave a minimum of 20 Gibytes free at all
>> times.
>>
>> The "can't write to" messages come about by mythbackend writing a zero
>> length file ".test" to each storage group directory on startup.  If it
>> fails to create the file, or fails to be able to delete it, it will
>> give the "can't write to" message and will not use that storage group
>> directory for writing until the next time it is started.
>>
>> So, first, take a look and see if your storage group directories
>> contain .test files, and what their ownership and permissions look
>> like.  Then manually delete them if they are there.  If you have had a
>> permissions problem that has caused the .test files to be left behind
>> undeleted, then I think the test fails on creating new ones, hence the
>> need to manually delete them after you fix the permissions.
>>
>> Then, try creating the .test files yourself as the user that
>> mythbackend runs as (mythtv).  Log in as root and do this:
>>
>> su - mythtv -c touch "<storage group path>/.test"
>>
>> And try deleting them again:
>>
>> su - mythtv -c "rm <storage group path>/.test"
>>
>> If either command does not work, then you need to fix the ownership
>> and permissions until it does work.
>
>
>so i am slightly confused. Here's what I have:
>
>BE user - myth  (no "tv"), mythconverg user: mythtv
>FE user - mythtv
>
>In ubuntu BE, i don't have "root". so i always log in as "myth" and when I
>do, it let's me do the touch and rm the .test

So does the backend user "mythtv" exist and have "mythtv" group?  That
is important.  So what does this command show:

su - mythtv -c "groups"

This is what I get:

root at mypvr:~# su - mythtv -c "groups"
mythtv dialout cdrom audio video

I am not sure why it has "dialout", but the other groups are
important.

>When we test permissions, do we test the "mythtv" because the FE as well as
>the DB user is "mythtv" or do we test "myth" because that's the BE user?

Mythbackend runs as user mythtv on the backend box.  Mythfrontend runs
as whatever user you run your desktop under on the frontend box.  Both
of those users normally have "mythtv" as an additional group on their
respective boxes.  The group IDs of the "mythtv" groups on the two
different boxes will not usually be the same, hence the are not the
same group.

>I gather the DB user "mythtv" comes in play later once FE talks to the BE,
>but the file permissions AND ownership is what confuses me.
>
>My share "/usr/local/media/metadata" is currently showing as
>
>myth at ScorpioOne:~$ ls -ahl /usr/local/media/
>total 208K
>drwxrwsr-x   9 nobody 4294967294   91 May  7 01:07 .
>drwxr-xr-x  11 root   root        127 May 11 14:24 ..
>drwxrwsr-x   4 root   mythtv       35 May  2 08:43 Data
>drwxrwsr-x   2 root   mythtv        6 May  7 01:07 live-tv
>drwxrwsr-x   2 nobody 4294967294 128K May 13  2018 metadata
>drwxrwsr-x 185 nobody 4294967294  20K May 12 23:11 Music
>drwxrwsr-x 103 nobody 4294967294 4.0K Jan  1 09:26 Pics
>drwxrwsr-x   4 root   mythtv       38 May  7 01:34 TV
>drwxrwsr-x   8 root   mythtv      108 Apr 13 12:47 Videos

For storage groups, the ownership and permissions of the mythbackend
user on the backend box are what matters.  Mythbackend normally runs
as user "mythtv" and group "mythtv" in Ubuntu.  Mythfrontend talks to
mythbackend for access to the storage group files, so for access to
the recordings, its ownership and permissions do not matter as all
that traffic happens over TCP/IP connections between mythbackend and
mythfrontend.  The normal setup for any storage group directory that
mythbackend has to access is to be ownership mythtv:mythtv with user
and group access both set to execute (=directory access), read and
write (chmod u=xrw,g=xrw).

However, it is possible to access things other than through storage
groups.  Both mythmusic (which is a plugin that runs entirely in
mythfrontend) and mythvideo (which is a builtin part of mythfrontend)
have settings for paths they can use to directly access things via the
normal access paths of the frontend box they are running on.  These
paths are in addition to the storage group settings they also have. So
it depends on how you have them set up - if you have them access
things via their storage groups, then the same rules apply as for any
storage group - access is via mythbackend and the ownership and
permissions of mythbackend are what matter, and access happens from
the backend box.  But if you are using the local system paths, access
to things via those paths uses mythfrontend's ownership and
permissions, and happens from the frontend box.  The local paths are
also different for each frontend - the frontend settings are stored in
the "settings" table with a different hostname field value for each
frontend.  So each frontend can access the videos or music in the
storage groups via the backend, and also potentially different videos
and music stored locally via the frontend.

I think mythgallery and its replacement (mythimage?) work the same way
as mythmusic and mythvideo.

Storage directories are set up in mythtv-setup on the backend box. The
local directories for a frontend are set up in mythfrontend on each
frontend box.

So, I find your /usr/local/media ownership a bit strange.  For a
start, the listing shows that the metadata, Music and Pics directories
have an unknown group (group ID 4294967294).  That normally only
happens if they are network mounted from a different PC, where the
group IDs and user IDs do not match those on the local PC.  If they
were local they would normally have been created using existing local
users and groups and would be displayed with the name rather than a
number.  Is that what is going on?  That really can cause problems!
And having your recording directories mounted on other boxes means
that the bandwidth to them is limited by the Ethernet connection to
the other boxes, and that can cause failed recordings when the traffic
is too large.

And even more strange is that the /usr/local/media/ directory itself
is nobody:4294967294.  So is that directory a network mount on a
different box?

The other directories (Data, live-tv, TV and Videos) all have root
ownership.  That is not necessarily fatal, as they do have mythtv
group ownership, but it is not normal.  They ought to be mythtv user
ownership.

And all the files under the storage group directories also should be
mythtv:mythtv ownership.

It would also be a good idea to check that mythbackend is running as
user mythtv.  Is this something like what "ps -ef | grep mythba" shows
for you?

root at mypvr:~# ps -ef | grep mythba
mythtv    3480     1  8 May11 ?        06:22:36 /usr/bin/mythbackend
--quiet --syslog local7 -v record,dvbcam
root     18746  7172  0 14:39 pts/2    00:00:00 grep --color=auto
mythba