Jail accounts denied access to mountpoints despite generous permissions

[rudds]

I've run into a problem where all jail accounts besides root are now being denied access to mountpoints on my main storage pool, despite the permissions seeming more than generous enough to allow access. This setup worked fine until I started experimenting with Windows and Unix ACLs and permissions on my pool, but at this point I've reverted entirely to Unix permissions and I don't understand how the below isn't working.

Code:

root@plex [/] # ls -l | grep media
drwxrw-rw-   7 floog  wheel     7 Feb  2 21:28 media
root@plex [/] # id plex
uid=972(plex) gid=972(plex) groups=972(plex),0(wheel)
root@plex [/] # sudo -u plex -Hs
% pwd
/
% cd media
media: Permission denied.

In this example from my Plex jail, media is a mountpoint configured in the FreeNAS GUI that points to my main pool, floog is an account in the base system that owns the dataset/directory, and the GID for the wheel group is the same in the base system and the jail. But despite the plex user being a member of the owner group and the directory being read-writable by everyone, the plex user still can't access the mountpoint. Same problem for another jail that houses a music server. Is there something obvious I'm missing here?

 

[Patrick M. Hausen]

media is missing the group x bit. Necessary to cd into a directory and to access files therein.

 

[rudds]

Well crap, guess I'm in the "know just enough to be dangerous" phase of learning basic *nix concepts. Thanks for the tip -- I assumed making the directory readable would be good enough.

Is there a way to make chmod (or the FreeNAS GUI) differentiate between files and directories so I can recursively set the permissions (755 and 644, respectively) on my datasets?

Edit: found a good answer to my own question that worked well, thanks again.

 

[Patrick M. Hausen]

chmod -R u=rwX,og=rX will set x bit only for directories and executable files.

HTH,
Patrick

 

[anodos]

chmod -R u=rwX,og=rX will set x bit only for directories and executable files.

HTH,
Patrick

The "x" should be lower-case.

 

[Patrick M. Hausen]

Nope. That's the point. "X" in upper case means, set x only for directories or for files that already have it set (probably because they are executables).

 

[anodos]

Nope. That's the point. "X" in upper case means, set x only for directories or for files that already have it set (probably because they are executables).

Oh, whoops. Thanks for pointing that out.