[mythtv-users] Ubuntu Mythbackend issue
Ashu Desai
ashu.desai at gmail.com
Mon May 14 04:29:49 UTC 2018
On Sun, May 13, 2018 at 10:06 PM Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:
> 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 don't know the password for username "mythtv"
During installation, I tried to name my user as "mythtv" for consistency
sake, but Ubuntu didn't allow me saying it's reserved so I had to create
"myth" as a user
I do get mythtv as a username - quick search gave me a command:
myth at ScorpioOne:~$ cut -d: -f1 /etc/passwd
root
daemon
bin
sys
sync
games
man
lp
mail
news
uucp
proxy
www-data
backup
list
irc
gnats
nobody
systemd-timesync
systemd-network
systemd-resolve
systemd-bus-proxy
syslog
_apt
messagebus
uuidd
lightdm
whoopsie
avahi-autoipd
avahi
dnsmasq
colord
speech-dispatcher
hplip
kernoops
pulse
rtkit
saned
usbmux
myth
mysql
ntp
mythtv
sshd
vboxadd
statd
>
> 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.
You are correct - sorry I thought i had mentioned earlier - these are NFS
storage.
> 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.
>
I have a gig ethernet connection to the boxes, both at my home.
>
> 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?
>
Yes the storage are NFS mounted for everything
- Video
- TV
- metadata
- Music
- Pics
- live-tv
> 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
>
This is what it shows for me:
myth at ScorpioOne:~$ ps -ef | grep mythba
myth 4668 2188 0 23:29 pts/18 00:00:00 grep --color=auto mythba
mythtv 25292 1 0 May12 ? 00:06:01 /usr/bin/mythbackend
--quiet --syslog local7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20180513/20c1e227/attachment.html>
More information about the mythtv-users
mailing list