We are setting up a network share with Samba that is meant as external storage for a Linux server (Fedora 35). Reading and writing files works, permissions seem to be set up properly. But there are problems with two operations that we would like to be able to do. Both of them work on the same machine if the target directory is not on the share.
The first one is using the share to store Conda environments. The setup is roughly like this:
ln -s /mnt/share/$username/.conda /home/$username/.conda
conda create -n test bottle
(You might have to add conda-forge for the above command to succeed, conda config --add channels conda-forge). The second command aborts with several messages like these:
CondaVerificationError: The package for ncurses located at /home/$username/.conda/pkgs/ncurses-6.2-h58526e2_4
appears to be corrupted. The path 'lib/terminfo'
specified in the package manifest cannot be found.
SafetyError: The package for ncurses located at /home/$username/.conda/pkgs/ncurses-6.2-h58526e2_4
appears to be corrupted. The path 'share/terminfo/E/Eterm'
has an incorrect size.
reported size: 2224 bytes
actual size: 842 bytes
Conda tries to install 25 packages, with only four of them producing errors, which means the remaining ones probably install fine, but I'm not sure since there is no environment created in the end.
The second problem is with R. When the user library is put onto the share (ln -s /mnt/share/$username/R /home/$username/R), installing some packages (apparently those using a staged install) fails. For example, if you try to install rlang from within R with install.packages('rlang'), it will fail at the end with this message:
mv: cannot move '/mnt/share/$username/R/x86_64-redhat-linux-gnu-library/4.1/00LOCK-rlang/00new/rlang' to '/mnt/share/$username/R/x86_64-redhat-linux-gnu-library/4.1/rlang': Permission denied
ERROR: moving to final location failed
There are packages that install without problems. This particular issue can be worked around by e.g. adding a parameter like this:
install.packages("rlang", INSTALL_opts = '--no-lock')
But 1) it would be great to not have to need workarounds, and 2) not every program that we will want to use will have a built-in solution like this.
So I'm wondering, is this a fundamental limitation with network shares or Samba in particular, or did we just miss something during setup? This is the smb.conf, which is mostly stock, modified by realm join --membership-software=samba --client-software=winbind, some extra settings as recommended by the Samba docs, and permissions set up from a Windows machine using Computer Management:
[global]
workgroup = DOMAIN
security = ads
passdb backend = tdbsam
printing = cups
printcap name = cups
load printers = yes
cups options = raw
kerberos method = secrets and keytab
template homedir = /home/%U@%D
template shell = /bin/bash
realm = DOMAIN.LOCAL
idmap config DOMAIN : range = 2000000-2999999
idmap config DOMAIN : backend = rid
idmap config * : range = 10000-999999
idmap config * : backend = tdb
winbind use default domain = no
winbind refresh tickets = yes
winbind offline logon = yes
winbind enum groups = no
winbind enum users = no
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes
[share]
path = /srv/share
read only = no
acl_xattr:ignore system acl = yes
