Bug #3459
File and Directory permissions - PVR fails to record
0%
Description
After upgrading from 3.4 to 4.0.8.3 - I have the following problem.
settings: Unable to create dir "_recording path/station~~~etc_/The-Big-Bang-Theory": Operation not permitted
dvr: Recording error: "The Big Bang Theory": Unable to create directories
Although it sometimes does record !! (The operation IS permitted and it sometimes creates the directory after giving the error)
When it doesn't record, it sits with the red recording icon on, but the info icon says "Waiting for program to start"
This means TVH can't be relied upon to make any recordings.
The problem is that TVH is trying to set the permissions even though it has all the permissions it needs to create the directories and files.
The disk is a large ntfs one, and is mounted in the simple way that allows all permissions. Everything created becomes owned by root/users.
Every user has all permissions, but cannot change the permissions/owner.
I do not want/need to set up the drive in the more complicated way, with credentials file etc.
I think the long term solution might be to have a checkbox in the recordings profile - "Do not set permissions" - above each permissions box, and disable those boxes when checked.
Is there a short term solution such as a setting somewhere in TVH's config files to stop TVH attempting to change the permissions to avoid this error.
I tried running as root, setting the config dir to hts, but the web interface kept asking for credentials, but none worked.
History
Updated by Jaroslav Kysela almost 9 years ago
- Status changed from New to Rejected
I don't like this proposal - to add such code only to support broken filesystems. TVH sets permissions using chown/chmod which is standard unix way. Just remove these calls in your installation, if you like - function makedirs() - src/utils.c .
Updated by Ne Name almost 9 years ago
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.
Updated by Jaroslav Kysela almost 9 years ago
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..
Updated by Ne Name almost 9 years ago
This does not work, as in the function makedirs() - src/utils.c first chown is called, which as I already pointed out will fail.
Updated by Jaroslav Kysela almost 9 years ago
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.
Updated by Ne Name almost 9 years ago
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
Updated by Jaroslav Kysela almost 9 years ago
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);
Updated by Jaroslav Kysela almost 9 years ago
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);
Updated by Ne Name almost 9 years ago
Nice, I did think of that but I didn't you could acces the permissions so easily
Updated by Bram de Greve almost 9 years ago
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.
Updated by Ne Name almost 9 years ago
Setting them to 755 might fix the problem. You can always test that by:
sudo -u hts chown *permission* /dvr/records/someNewDir
Also you can test it in the WebGui. Enable debug ouput then create a Test recording at the current time and look what it prints
Updated by Bram de Greve almost 9 years ago
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.
Updated by Les H almost 9 years ago
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.
- TVH should not fail to record when it has write permissions in the parent folder.
- Probably worked OK before because TVH ran as root, but now runs as hts.
- 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.
- I think the problem stems from tvh trying to create the folder or file and set the owner and permissions in a SINGLE operation.
- The failure to set the owner and/or permissions is then interpreted as a failure to create the folder or file (so recording fails).
- 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
Updated by Ne Name almost 9 years ago
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.
Updated by saen acro almost 9 years ago
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.
Updated by Bram de Greve over 8 years ago
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.
Updated by Jaroslav Kysela over 8 years ago
- Status changed from Rejected to Fixed
The chmod can fail now for some (not all) subsystem. The configuration directories should be on partition where the permission can be maintained.
I pushed this commit to both 4.0 and 4.1 trees:
v4.0.8-9-gce82e79
v4.1-1480-g8eb4f40