Tvheadend

What? Why is a mounted filesystem, owner root, permissions 0777, a broken one? Thats´s the general way to do this. Why do i have to change to owner of the mount to hts? Especially if you also use the mount for other purposes.
Of course adding a way to disable the chown/chmod would be best. However, as far as i understand linux permissions, chowning the file/dir is completely USELESS, because either the parent dir is owned by hts and therefore the new file/dir is already owned by it or parent dir is owned by someone else and it will fail, because only the owner (or root) can chown.

Just set the 0777 permission mode in your DVR profile. It should be enough to make your configuration live. It's very specific in non-linux way..

This does not work, as in the function makedirs() - src/utils.c first chown is called, which as I already pointed out will fail.

There's condition 'if (!err && gid != -1 && uid != -1)' - makedirs() is called from src/dvr/dvr_rec.c with both gid, uid variables set to -1.

Okay now i got, but still would be great if you could add the ability to set the directory_permissions to -1 and this would like the chown skip the chmod

What about this ?

diff --git a/src/utils.c b/src/utils.c
index 850e28d..8244741 100644
--- a/src/utils.c
+++ b/src/utils.c
@@ -503,7 +503,7 @@ makedirs ( const char *inpath, int mode, gid_t gid, uid_t uid )
         err = mkdir(path, mode);
         if (!err && gid != -1 && uid != -1)
           err = chown(path, uid, gid);
-        if (!err)
+        if (!err && mode != (st.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)))
           err = chmod(path, mode); /* override umode */
         tvhtrace("settings", "Creating directory \"%s\" with octal permissions " 
                              "\"%o\" gid %d uid %d", path, mode, gid, uid);

Sorry, it was wrong. A better solution:

+#define FILE_MODE_BITS(x) (x&(S_IRWXU|S_IRWXG|S_IRWXO))
+
 int
 makedirs ( const char *inpath, int mode, gid_t gid, uid_t uid )
 {
@@ -503,7 +505,8 @@ makedirs ( const char *inpath, int mode, gid_t gid, uid_t uid )
         err = mkdir(path, mode);
         if (!err && gid != -1 && uid != -1)
           err = chown(path, uid, gid);
-        if (!err)
+        if (!err && !stat(path, &st) &&
+            FILE_MODE_BITS(mode) != FILE_MODE_BITS(st.st_mode))
           err = chmod(path, mode); /* override umode */
         tvhtrace("settings", "Creating directory \"%s\" with octal permissions " 
                              "\"%o\" gid %d uid %d", path, mode, gid, uid);

Nice, I did think of that but I didn't you could acces the permissions so easily

Hi,

I'm having the exact same issue since I've upgraded from tvheadend 3.4.

Now I'm running 'HTS Tvheadend 4.0.8~wheezy' (armhf).
I'm recording on an external USB disk with exFAT file system.
Here's the fstab line:

/dev/sda1       /dvr    exfat-fuse      defaults,user,uid=hts,gid=hts   0      0

It's recording in /dvr/recordings. All directories and files are owned by the hts user, with 755 permissions.

ls -al /dvr
total 388
drwxr-xr-x  1 hts  hts  131072 Jan  1  1970 .
drwxr-xr-x 24 root root   4096 Mar 29  2015 ..
drwxr-xr-x  1 hts  hts  131072 Feb  3 23:03 recordings
drwxr-xr-x  1 hts  hts  131072 Mar 31  2015 timeshift

The hts user is also the one running tvheadend:

ps -efH
...
hts        571     1  1 Jan09 ?        12:18:58   /usr/bin/tvheadend -f -u hts -g video

It was running rock solid for more than a year before the upgrade (many kudos for that!)
However, now it regularly fails to record programs. As it stands, my only option is to downgrade back to 3.4.

Can you please reopen or advice how to fix this?

Oh ... I'm just checking the tvheadend Configuration, and I see in the following settings in the Recording tab:
Recording File Options: File Permissions: 0664
Subdirectory Options: Directory Permissions: 0775

Should I set them to 0755?

Thanks,
Bram.

Setting them to 755 might fix the problem. You can always test that by:

sudo -u hts chown *permission* /dvr/records/someNewDir

No, it doesn't help. Which, in hindsight, is obvious. Since the check to avoid setting the permission isn't in place.
That means I'll have to downgrade :-(

Bram.

Hi
I am no Micro$oft fan boy, but I do live in the real world.
External xTB USB drives are very useful, and nearly always come pre-formatted NTFS.
The wonderful work done by the NTFS-3G people is the best solution when used with nix systems.
Reformatting the drive with ext fs is poor, because ext fs drivers for windows are not as good or as flexible as the NTFS-3G solution.

After this bug was rejected, implying that any non ext fs system is "broken", I was forced to go down the NTFS-3G "usermapping" route.
This is a bit involved, I would think that the less tech savy people may find it difficult, espesially if they have a "Home Premium" edition of windows (GUI Users & Groups removed).
I think this should not be nessessary, the NTFS-3G "Simple" method should be OK. The drive is mounted with 777 and everything appears as owned by root:root.
The files created by TVH are not the crown jewels or my bank details, they are normally temporary versions of TV programs that were broadcast free to air.

1. TVH should not fail to record when it has write permissions in the parent folder.
2. Probably worked OK before because TVH ran as root, but now runs as hts.
3. It fails because it attempts to change the owner and permissions, not because of what it is trying to set them to. Even trying to set them to the same as the parent folder (root:root 777) will produce an error.
4. I think the problem stems from tvh trying to create the folder or file and set the owner and permissions in a SINGLE operation.
5. The failure to set the owner and/or permissions is then interpreted as a failure to create the folder or file (so recording fails).
6. Separating the two things could solve it without any need to change the GUI or have the user make any setting in TVH.

I am not a C/C++ person (Java is my experience), but here is some pseudo code. So long as TVH has RW permission in the parent folder, recording will succeed and only an error in the log will be produced when using a non nix fs. It doesn't include iteration to create a folder hierarchy, but you get the point :-

Create folder/file (do not attemp to set owner/permissions, they will be inherited, allow OS/FS to take care of it)
    Fail
        Log SEVERE error, insufficient privelages to create folder / file
        exit(failed)
    Success
        Set owner/permissions as per recording profile
            Fail
                Log WARN or INFO error, could not set owner / permissions
                continue
            Success
                all good - continue
        end of "Set owner/permissions as per recording profile" 
        Yeh - Pass file back to Recording process for recording.
End of  "Create folder/file 

Hope this helps
Les

You should read the code:

https://github.com/tvheadend/tvheadend/blob/master/src/utils.c#L487

If you are experienced in Java (like me) you will be able to read this. Java and C++ have the same syntax.
And you will see, what is already discussed here, chown is never called:

Jaroslav Kysela wrote:

There's condition 'if (!err && gid != -1 && uid != -1)' - makedirs() is called from src/dvr/dvr_rec.c with both gid, uid variables set to -1.

Below you can also see that, on the old code just chmod is called, that´s why currently the fix is to mount as hts and set the permissions in the webgui to the same as the mount is, but now with Jaroslav Kysela´s fix it now first checks if the wanted permission isn´t already set.

May I ask is actions to check permissions to write are taken when: task created or when task start?
This will solve more problems with writing, if action taken when task created.
Making http://kodi.wiki/view/NFO_files file with some info from EPG to destination will be great solution.

Jaroslav Kysela wrote:

Sorry, it was wrong. A better solution:

[...]

Hi Jaroslav,

Is there any chance a patch will come to the 4.0 branch and released in the apt repositories? I think your fix should work. All directories and files are mounted as 0755 (and owned by hts), so if I would set the configuration accordingly, your fix would avoid calling chmod, resolving the problem.

Thanks,
Bram.