<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, May 13, 2018 at 10:06 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 13 May 2018 18:56:42 -0500, you wrote:<br>
<br>
>On Sun, May 13, 2018 at 11:55 AM Stephen Worthington <<br>
><a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>> wrote:<br>
><br>
>> On Sun, 13 May 2018 10:47:45 -0500, you wrote:<br>
>><br>
>> >I see "can't write to" issue and some "AutoExpire: CalcParams(): Max<br>
>> >required Free Space: 1.0 GB w/freq: 15 min" thing which when I search<br>
>> seems<br>
>> >to be some TV Tuner issue<br>
>><br>
>> You can ignore the "Autoexpire:" messages - they are normal. It just<br>
>> means that mythbackend has looked at all the storage groups and<br>
>> checked that they have enough free space. If they do not, it will<br>
>> choose some recordings to expire to create enough free space. Always<br>
>> make sure your storage groups have enough free space unless you want<br>
>> old recordings to expire. I leave a minimum of 20 Gibytes free at all<br>
>> times.<br>
>><br>
>> The "can't write to" messages come about by mythbackend writing a zero<br>
>> length file ".test" to each storage group directory on startup. If it<br>
>> fails to create the file, or fails to be able to delete it, it will<br>
>> give the "can't write to" message and will not use that storage group<br>
>> directory for writing until the next time it is started.<br>
>><br>
>> So, first, take a look and see if your storage group directories<br>
>> contain .test files, and what their ownership and permissions look<br>
>> like. Then manually delete them if they are there. If you have had a<br>
>> permissions problem that has caused the .test files to be left behind<br>
>> undeleted, then I think the test fails on creating new ones, hence the<br>
>> need to manually delete them after you fix the permissions.<br>
>><br>
>> Then, try creating the .test files yourself as the user that<br>
>> mythbackend runs as (mythtv). Log in as root and do this:<br>
>><br>
>> su - mythtv -c touch "<storage group path>/.test"<br>
>><br>
>> And try deleting them again:<br>
>><br>
>> su - mythtv -c "rm <storage group path>/.test"<br>
>><br>
>> If either command does not work, then you need to fix the ownership<br>
>> and permissions until it does work.<br>
><br>
><br>
>so i am slightly confused. Here's what I have:<br>
><br>
>BE user - myth (no "tv"), mythconverg user: mythtv<br>
>FE user - mythtv<br>
><br>
>In ubuntu BE, i don't have "root". so i always log in as "myth" and when I<br>
>do, it let's me do the touch and rm the .test<br>
<br>
So does the backend user "mythtv" exist and have "mythtv" group? That<br>
is important. So what does this command show:<br>
<br>
su - mythtv -c "groups"<br>
<br>
This is what I get:<br>
<br>
root@mypvr:~# su - mythtv -c "groups"<br>
mythtv dialout cdrom audio video<br></blockquote><div><br></div><div>I don't know the password for username "mythtv"</div><div>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</div><div><br></div><div>I do get mythtv as a username - quick search gave me a command:</div><div><br></div><div><div>myth@ScorpioOne:~$ cut -d: -f1 /etc/passwd</div><div>root</div><div>daemon</div><div>bin</div><div>sys</div><div>sync</div><div>games</div><div>man</div><div>lp</div><div>mail</div><div>news</div><div>uucp</div><div>proxy</div><div>www-data</div><div>backup</div><div>list</div><div>irc</div><div>gnats</div><div>nobody</div><div>systemd-timesync</div><div>systemd-network</div><div>systemd-resolve</div><div>systemd-bus-proxy</div><div>syslog</div><div>_apt</div><div>messagebus</div><div>uuidd</div><div>lightdm</div><div>whoopsie</div><div>avahi-autoipd</div><div>avahi</div><div>dnsmasq</div><div>colord</div><div>speech-dispatcher</div><div>hplip</div><div>kernoops</div><div>pulse</div><div>rtkit</div><div>saned</div><div>usbmux</div><div>myth</div><div>mysql</div><div>ntp</div><div>mythtv</div><div>sshd</div><div>vboxadd</div><div>statd</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I am not sure why it has "dialout", but the other groups are<br>
important.<br>
<br>
>When we test permissions, do we test the "mythtv" because the FE as well as<br>
>the DB user is "mythtv" or do we test "myth" because that's the BE user?<br>
<br>
Mythbackend runs as user mythtv on the backend box. Mythfrontend runs<br>
as whatever user you run your desktop under on the frontend box. Both<br>
of those users normally have "mythtv" as an additional group on their<br>
respective boxes. The group IDs of the "mythtv" groups on the two<br>
different boxes will not usually be the same, hence the are not the<br>
same group.<br>
<br>
>I gather the DB user "mythtv" comes in play later once FE talks to the BE,<br>
>but the file permissions AND ownership is what confuses me.<br>
><br>
>My share "/usr/local/media/metadata" is currently showing as<br>
><br>
>myth@ScorpioOne:~$ ls -ahl /usr/local/media/<br>
>total 208K<br>
>drwxrwsr-x 9 nobody 4294967294 91 May 7 01:07 .<br>
>drwxr-xr-x 11 root root 127 May 11 14:24 ..<br>
>drwxrwsr-x 4 root mythtv 35 May 2 08:43 Data<br>
>drwxrwsr-x 2 root mythtv 6 May 7 01:07 live-tv<br>
>drwxrwsr-x 2 nobody 4294967294 128K May 13 2018 metadata<br>
>drwxrwsr-x 185 nobody 4294967294 20K May 12 23:11 Music<br>
>drwxrwsr-x 103 nobody 4294967294 4.0K Jan 1 09:26 Pics<br>
>drwxrwsr-x 4 root mythtv 38 May 7 01:34 TV<br>
>drwxrwsr-x 8 root mythtv 108 Apr 13 12:47 Videos<br>
<br>
For storage groups, the ownership and permissions of the mythbackend<br>
user on the backend box are what matters. Mythbackend normally runs<br>
as user "mythtv" and group "mythtv" in Ubuntu. Mythfrontend talks to<br>
mythbackend for access to the storage group files, so for access to<br>
the recordings, its ownership and permissions do not matter as all<br>
that traffic happens over TCP/IP connections between mythbackend and<br>
mythfrontend. The normal setup for any storage group directory that<br>
mythbackend has to access is to be ownership mythtv:mythtv with user<br>
and group access both set to execute (=directory access), read and<br>
write (chmod u=xrw,g=xrw).<br>
<br>
However, it is possible to access things other than through storage<br>
groups. Both mythmusic (which is a plugin that runs entirely in<br>
mythfrontend) and mythvideo (which is a builtin part of mythfrontend)<br>
have settings for paths they can use to directly access things via the<br>
normal access paths of the frontend box they are running on. These<br>
paths are in addition to the storage group settings they also have. So<br>
it depends on how you have them set up - if you have them access<br>
things via their storage groups, then the same rules apply as for any<br>
storage group - access is via mythbackend and the ownership and<br>
permissions of mythbackend are what matter, and access happens from<br>
the backend box. But if you are using the local system paths, access<br>
to things via those paths uses mythfrontend's ownership and<br>
permissions, and happens from the frontend box. The local paths are<br>
also different for each frontend - the frontend settings are stored in<br>
the "settings" table with a different hostname field value for each<br>
frontend. So each frontend can access the videos or music in the<br>
storage groups via the backend, and also potentially different videos<br>
and music stored locally via the frontend.<br>
<br>
I think mythgallery and its replacement (mythimage?) work the same way<br>
as mythmusic and mythvideo.<br>
<br>
Storage directories are set up in mythtv-setup on the backend box. The<br>
local directories for a frontend are set up in mythfrontend on each<br>
frontend box.<br>
<br>
So, I find your /usr/local/media ownership a bit strange. For a<br>
start, the listing shows that the metadata, Music and Pics directories<br>
have an unknown group (group ID 4294967294). That normally only<br>
happens if they are network mounted from a different PC, where the<br>
group IDs and user IDs do not match those on the local PC.</blockquote><div><br></div><div>You are correct - sorry I thought i had mentioned earlier - these are NFS storage. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> If they<br>
were local they would normally have been created using existing local<br>
users and groups and would be displayed with the name rather than a<br>
number. Is that what is going on? That really can cause problems!<br>
And having your recording directories mounted on other boxes means<br>
that the bandwidth to them is limited by the Ethernet connection to<br>
the other boxes, and that can cause failed recordings when the traffic<br>
is too large.<br></blockquote><div><br></div><div>I have a gig ethernet connection to the boxes, both at my home.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And even more strange is that the /usr/local/media/ directory itself<br>
is nobody:4294967294. So is that directory a network mount on a<br>
different box?<br></blockquote><div><br></div><div>Yes the storage are NFS mounted for everything</div><div><ul><li>Video</li><li>TV</li><li>metadata</li><li>Music</li><li>Pics</li><li>live-tv </li></ul></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The other directories (Data, live-tv, TV and Videos) all have root<br>
ownership. That is not necessarily fatal, as they do have mythtv<br>
group ownership, but it is not normal. They ought to be mythtv user<br>
ownership.<br>
<br>
And all the files under the storage group directories also should be<br>
mythtv:mythtv ownership.<br>
<br>
It would also be a good idea to check that mythbackend is running as<br>
user mythtv. Is this something like what "ps -ef | grep mythba" shows<br>
for you?<br>
<br>
root@mypvr:~# ps -ef | grep mythba<br>
mythtv 3480 1 8 May11 ? 06:22:36 /usr/bin/mythbackend<br>
--quiet --syslog local7 -v record,dvbcam<br>
root 18746 7172 0 14:39 pts/2 00:00:00 grep --color=auto<br>
mythba<br></blockquote><div><br></div><div>This is what it shows for me:</div><div><br></div><div><div>myth@ScorpioOne:~$ ps -ef | grep mythba</div><div>myth 4668 2188 0 23:29 pts/18 00:00:00 grep --color=auto mythba</div><div>mythtv 25292 1 0 May12 ? 00:06:01 /usr/bin/mythbackend --quiet --syslog local7</div></div><div><br></div><div><br></div></div></div>