Executables on Linux require a special "Executable flag".
If you have installed RR via Windows, it might be the case that this flag was not set on your fileserver.
In this case use the RR setup application and start it on any Linux machine.
Browse to the RR folder and use the button "Apply executable rights only".
RR applications require GLIBCXX 3.4.15 (CentOS 7+, Ubuntu 16+).
If you need/want to check the library versions supported by your distribution:
GLIBCXX can be checked with one of these commandlines
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX
You need to have these packages installed:
•tcsh (C-Shell)
RR 8.x uses csh for its render scripts.
If you want to dublicate your bash environment, please add these commands to your \render_apps\_setenv\lx\_global.sh
bash$ env > /tmp/bash.env
csh$ env /tmp/bash.env
If you get this error message, then your systems Qt version is not the same as RRs Qt version.
The version that your system uses is stated first "incompatible Qt library (version 0x4080...".
The second is the version that RR uses "with this library (version 0x408"
On some system, you can update Qt 4.x to the latest Qt 4.x version with the command "yum update qt".
Otherwise we offer QT libraries in multiple versions.
Download the version that fits your system and replace the files in RR/bin/lx64/lib/.
Qt 4.8.5 |
|
Qt 4.8.6 |
|
Qt 4.8.7 - GLIBC 2.12 |
|
Qt 4.8.7 - GLIBC 2.17 |
Recommended distributions are all the "redhat-style" linux distros (same as most other 3D and comp software manufactures recommend): CentOS (Fedora, Mandrake)
KDE is preferred, but not required (Gnome works as well)
RR was also well tested with the (K)Ubuntu distribution.
This does not mean that Suse and Debian are not working, we have tested all.
But we recommend the other distributions.
Then you need to check your render applications for supported Linux distributions.
The Foundry recommends CentOS.
For example Maya has some limitations on Ubuntu.
From the readme file for /usr/autodesk/maya2020/support/python/2.7.11:
To work around this, one can exchange the RHEL 6.x build of _hashlib.so with a version built on Ubuntu 14.04.4
Copy your unbuntu _hashlib.so and _ssl.so into /usr/autodesk/mayaxxxx/support/python/2.7.11/ and replace the Redhat/CentOS file.
You have 2 options to mount your file shares.
1) You tell the rrClient to mount shares.
Please open rrConfig, tab "paths and drives" and add your fileserver share.
2) You let the system mount all shares via fstab.
Please see next section.
If your RR files are on a samba or windows fileserver, then you have to mount the fileserver share to a local directory.
1.Create a mount point/directory, for example create the folder /mnt/RRender.
2.Edit the file /etc/fstab, add a line:
//192.168.0.15/RRShare /mnt/RRender cifs username=myShareUser,password=myPassword,noperm,uid=myRRUser,gid=users,file_mode=0777,dir_mode=0777 0 0
You have to replace some variables to match your environment:
//192.168.0.15/RRShare |
Set this to the fileserver IP and share name. |
myShareUser,myPassword |
Add a user that is able to access the fileserver. You do not need to have this user on linux, the user+password is send to the server. |
myRRUser |
The user you use for running RoyalRender. |
Important: Do not forget an empty line at the end of the fstab file!!
3.After you have edited the file, execute the command
mount -a
If there is any problem with the fstab, it will be printed.
XSAN:
One customer had to add more flags to connect to a XSAN server, his fstab setting was:
//10.0.100.200/media/ cifs credentials=/home/parallels
/.smbcredentials,noperm,iocharset=utf8,uid=thankyou,thankyouall,file_mode=0777,dir_mode=0777,nounix,noserverinfo,sec=ntlmssp 0 0
Newer Windows fileserver:
You might need to add smb3 and ntlmssp:
1.//192.168.0.15/RRShare /mnt/RRender cifs username=myShareUser,password=myPassword,noperm,uid=myRRUser,gid=users,file_mode=0777,dir_mode=0777,sec=ntlmssp,vers=3\.0 0 0
If you need to use Docker to run applications, then you have to create a Docker config file for the RR image.
Usually the rrAutostartservice caches the rrClientconsole application locally and starts it.
If you want to use Docker instead, create a Dockerfile with the commandline
CMD ["RR/bin/lx64/startlocal", "rrClientconsole ", "-service"]
Note: Replace "RR" with the path to your RR installation.
Nothing else is required. RR runs on most Linux distributions without the requirement to install any additional library packages.
And the above command does not require any files to be installed locally.
The application caches the rrClient locally in /tmp.
And you always use the latest RR version which is required if you update RR.
On Linux, it is sometimes more complicated with the access rights of the output frames and folders if they are created by RR.
There
There is the UMask which can be set in the mount command (file_mode=0777,dir_mode=0777) or for a user/application environment (~/.bashrc).
There is a setting in rrConfig, tab "Other" to tell RR to set Read+Write+Browse (777) permissions on these folders.
First, it depends on the application that creates the folder.
a) Submission
If they do not exist, then there is the rrSubmitter that creates the main and all AOV/framebuffer/channel output folders. (Only known AOV folders as shown in the job info )
In addition, the rrSubmitter supports two commandline flags and a config option
•-NoOutFolderCreation: Does not create folders at submission
•-SetOutFolderUserRights: Sets 777 on folders (read+write+browse)
•rrConfig, tab Other: Same option as commandline -SetOutFolderUserRight via a checkbox.
If you do not use any flag, then the output folder is created with this UMask:
•if it was set: mount option on the artists machine
•otherwise the artists environment setting
b) Job queue receive/job check
•The rrServer creates the main output folder if it does not exist (any more).
Please see "c) Rendering" for more information about the UMask.
c) Rendering
It is possible that either the rrClient or the render application creates folders and files
With job option "Local Render Out" enabled:
•The rrClient creates output files and additional AOV folders that do not exist (but not the main output folder).
Without job option "Local Render Out":
•The render application creates output files and additional AOV folders that do not exist.
Now it depends on how you start the RR applications (which is inherited to the render application)
Application mode:
If you have started the rrServer or rrClient in application mode, then output files and folder are created with this UMask:
•if it was set: mount option on the machine
•otherwise the current users environment setting
Service mode:
If you have started rrServer or rrClient in service mode (should be default for a permanent installation), then output files and folder are created with this UMask:
•if it was set: mount option on the machine
•if it was set: otherwise UMask override of the RR service/daemon (change via rrWorkstationInstaller)
•otherwise the system default