samba - Jun 2023 - Occasional "Permission denied" errors when installing R packages onto a share

Hello,

When trying to store a user's personal R library on an SMB share (so that
users
without admin rights can have their personal libraries accessible from several
compute servers), some packages fail to install with a "Permission
denied" error
from "mv", while others install without problems. We have run out of
our own
ideas on how to fix this and would appreciate any help.

The user library by default is located under
"~/R/${SYSTEM_INFO}-library/${R_VERSION}/". R's installation
procedure runs
somewhat like this:

1. A subfolder named "00LOCK-${PKG_NAME}/00new/${PKG_NAME}" is created
inside
   the library folder.
2. Library binaries are compiled.
3. HTML documentation is created.
4. The folder "${PKG_NAME}" is moved up two levels.
5. The "00LOCK..." folder is removed.

Step 4 fails reproducibly for some packages, while succeeding for others. Here
is
a reproduction procedure in a Fedora 38 VM:

1. Install Fedora 38 Workstation (Fedora-Workstation-Live-x86_64-38-1.6.iso).
   Username: 'user'
2. Disable SELinux (edit /etc/selinux/config and set
"SELINUX=disabled") and
   reboot. Alternatively set up SELinux as described here:
   <https://docs.fedoraproject.org/en-US/quick-docs/samba/>
3. Set up and mount a basic Samba share:

   $ sudo dnf install samba
   $ sudo cat << 'EOF' >> /etc/samba/smb.conf
   [share]
     path = /home/user/share
     writable = yes
     valid users = user
   EOF
   $ sudo smbpasswd -a user
   $ mkdir /home/user/{share,R}
   $ sudo systemctl restart smb
   $ sudo mount -t cifs //localhost/share /home/user/R -o username=user,uid=user

4. Install R:

   $ sudo dnf install R

5. Start R (command line arguments are optional) and install the package
"xml2":

   $ R --quiet --no-save
   > install.packages('xml2',
repos='https://cloud.r-project.org')

   Confirm twice when asked about the personal library. This will only be needed
   on the first attempt to install a package.
6. The installation should fail with this message:

   mv: cannot move
'/home/user/R/x86_64-redhat-linux-gnu-library/4.3/00LOCK-xml2/00new/xml2'
   to '/home/user/R/x86_64-redhat-linux-gnu-library/4.3/xml2':
Permission denied
   ERROR:   moving to final location failed

Executing the same "mv" command manually in the shell after closing R
succeeds
however, and as far as I understand, all R is doing is calling out to
"mv": the
corresponding code is in
<https://svn.r-project.org/R/trunk/src/library/tools/R/install.R>,
Ctrl+F "moving to final location", second match.

Two counterexamples of when the installation succeeds: installing the package
"rlang" and the same package "xml2" but without the
documentation:

$ R --quiet --no-save
> install.packages('rlang',
repos='https://cloud.r-project.org')
> install.packages('xml2',
repos='https://cloud.r-project.org', INSTALL_opts='--no-help')
We also tried different servers to figure out whether the problem is with the
server or the client, and these are the findings:

- Samba: fails as described above
- Windows 8: fails as described above
- NetApp: succeeds

This to me rules out a client-side problem with "mount.cifs" since the
NetApp
setup works without problems. Since both Windows and Samba fail in the same way,
Samba seems to properly emulate the behavior of a Windows machine, so it
doesn't look like a bug in Samba but rather the expected behavior. So the
question is: Is there a way to configure the server so that this operation
succeeds?

Samba versions tested: 4.10.16 on CentOS 7, 4.17.5 on AlmaLinux 8.8, 4.18.3 on
Fedora 38.

Thank you,
Ilja

On 6/22/23 11:57, Heckmann, Ilja via samba wrote:
> 1. A subfolder named "00LOCK-${PKG_NAME}/00new/${PKG_NAME}" is
created inside
>     the library folder.
> 2. Library binaries are compiled.
> 3. HTML documentation is created.
> 4. The folder "${PKG_NAME}" is moved up two levels.
> 5. The "00LOCK..." folder is removed.
> 
> Step 4 fails reproducibly for some packages, while succeeding for others.
my guess is that the rename fails as the client has some open file 
inside (at any level) the renamed directory. Windows behaviour is to 
prohibit this and Samba follows suit.

With SMB1 you could enable UNIX extensions and that modify Samba 
behaviour to allow the rename, but unfortunately we don't have UNIX 
extensions for SMB2/3 yet.

The first step to analyze this would be getting a network trace and 
taking a look.

If the trace confirms my theory, you could modify can_rename() in 
source3/smbd/smb2_reply.c to disable the rename check, but beware that 
this violates the spec. A good compromise would be to add an option to 
can_rename() that would allow changing behaviour and then set this 
option via an smb.conf include file only for the Linux clients.

-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba
SAMBA+ Samba packages                   https://samba.plus/
SAMBA+ AIX Webinar        https://samba.plus/samba-webinars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20230622/cfbc3dc8/OpenPGP_signature.sig>