I currently have OOD 3.1.9
SELinux enabled
We are still testing OOD for production use.
When we upload files or directories, they work fine, but for some reason, they do not inherit the group ownership of the parent directory.
How can I fix this?
This was actually a bugfix in 3.1.9. The issue I suspect is that you’re not actually able to chown that file to that group. You’ll see errors in /var/log/ondemand-nginx/$USER/error.log for the same.
On that same file in the same directory - are you able to open a shell and chown to that group manually? I suspect you can’t.
Here’s the relevant block of code where we attempt to chown, but rescue and log the failure to do so.
The error shows operation not permitted.
Are you able to open a shell and chown the file to the group you’d expect?
Hi @jeff.ohrstrom. Picking this up from my colleague…
Your assumption is correct, users uploading files do not have the necessary permission to chown to the group, which is intended.
Based on the findings from another recent issue
(File upload and posix acl support - updated)
related to FileUtils.mv versus FileUtils.cp, for the handle_upload function in posix_file.rb, I’ve achieved the desired behavior by enabling setgid on all home directories and switching mv to cp.
What are your thoughts on this approach?
Hi and welcome!
To cp we’d need to rm the temp file as well I think. I’ll have to look into FileUtils.mv as the other topic seems to suggest it’s doing a chown by itself.
One other thing worth mentioning: after making the change from mv to cp, uploads to a /scratch directory that is in an AWS FSx for Lustre filesystem throw an error for upload failed, but still successfully complete the upload
Edit: with the above behavior, the file is present within the filesystem, but is not shown within the OOD console
@jeff.ohrstrom, any idea why the change would have the resulting behavior on the/scratch FSx Lustre directory?
This is the behavior you’re referring to?
Do you use the allowlist on your files? This could cause it to not show up, if the file is actually a symlink that points outside of the allowlist paths.
Another issue could be non-utf8 characters. You’d see errors in /var/log/ondemand-nginx/$USER/error.log if this were the case.
Indeed, that behavior. We aren’t using the allowlist on file paths so wouldn’t be that. Oddly not getting any errors in the /var/log/ondemand-nginx/$USER/error.log files, but do see 403 responses for uploads to the /scratch directory from the /var/log/ondemand-nginx/$USER/access.log.