SOLVED sickbeard Failed to set permission error

[pcloadetter]

The error:

Failed to set permission for /mnt/media/tvshows/General/SHOWNAME/Showname - S12E33.mkv to 664

I'm in the onset of setting everything up with my FreeNAS steup.
I have a single datastore called media. It is set up with windows permissions and owned by htpc:htpc ( rwxrwxr-x+)

Obviously sickbeard plugin is run as media (816), which is a member of htpc group. the tvshows folder is set to media:htpc (drwxrwxr-x+), as are all the subsequent sub directories.

I understand that 664 would be rw-rw-r--, but I don't you need x for media files? or would 664 be sufficient? Also, since sickbeard runs as media (816) which exists on the jail and the FN system, why wouldn't it be able to change the permissions as the owner of the folder?

 

[Joshua Parker Ruehlig]

the x flag means executable for files so you don't need it. it means something different for folders, so you shouldn't remove it from them.

read points 2-3 under the facts section. it explains your conundrum
https://forums.freenas.org/index.ph...plugins-write-permissions-to-your-data.27273/

 

[pcloadetter]

I read the facts, but I'm feeling a bit dense and don't see the issue.

 

[Joshua Parker Ruehlig]

I read the facts, but I'm feeling a bit dense and don't see the issue.

in what userland is sickbeard in the htpc group? The FreeNAS host or the jail sickbeard is installed to?

 

[pcloadetter]

FreeNAS host
htpc group (1001) members:
htpc (1001)
media (816)
johndoe (1002)

Sickbeard Jail
cat /etc/group
htpc:*:1001:media

 

[Joshua Parker Ruehlig]

from the information you've given me it should work. but I know nothing about windows permissions so I don't know if that complicates things.

 

[pcloadetter]

Thank you. I am glad I'm not imaging an issue. I can't imagine how windows permissions would be a big issue here. I tried as root and I got a permission denied as well.

My NFS share does have Maproot User: set to media, for any odd mapping issue that could have occured

 

[Joshua Parker Ruehlig]

Thank you. I am glad I'm not imaging an issue. I can't imagine how windows permissions would be a big issue here. I tried as root and I got a permission denied as well.

My NFS share does have Maproot User: set to media, for any odd mapping issue that could have occured

if root can't do it, something else is going on here that isn't standard Unix permissions.

 

[pcloadetter]

I tried as root from the FreeNAS host, and has the same issue. I can't understand how that's even possible.

 

[danb35]

The problem is that your dataset is set for Windows permissions, which means it uses Windows ACLs rather than standard Unix permissions. When that is set, you won't be able to use chmod/chown in that dataset. You may be able to resolve this issue by switching the dataset to use Unix permissions instead.

 

[pcloadetter]

Will I need to reboot? I did a quick test with not good results. I have to step out for a few, but I'll pick up shortly.

 

[pcloadetter]

So I believe the problem has to do with extended attributes

/mnt/xxx/media# lsattr
---------------- ./downloads
---------------- ./movies
---------------- ./tvshows

I'm not the most knowledgeable, but my 2 choices are:
1. Find a way to recursively strip extended attributes
2. delete and re-create the datashare. Long as it is named the same, my remote mount points should all still work.

Any thoughts to removing all the attributes?

Additional information:

It looks like the additional permissions came from creating a CIFS share. I never had extended attributes until I did that. But now, it seems that everything is working as expected... further testing though tomorrow.