Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

cp to NFS: operation not permitted, empty file created, and then works on 2nd try

Western Digital Drives - The Preferred Drives of FreeNAS and TrueNAS CORE

jlkbah

Newbie
Joined
Oct 8, 2019
Messages
2
I just set up FreeNAS on an old desktop to act as an NFS and SMB share for a network of Linux (CentOS 7.?) and Windows 10 systems. I can successfully mount the NFS on the Linux side and read/write the SMB share on the Win10 side. Both point to the same location in my ZFS pool. Unfortunately, there's a quirk to the NFS. If I attempt to copy a file to the NFS (i.e. cp source.file /mnt/nfs_destination), I receive an error:

cp: cannot create regular file '/mnt/nfs_destination/source.file': Operation not permitted

If I do a "ls -al" on the destination folder, I'll see an empty file was created (something along the lines like below):

ls -al /mnt/nfs_destination/
-rwxrwx--- 1 nfsnobody nfsnobody 0 Oct 8 2019 source.file

If I then try the command to copy to the NFS again, it succeeds without an issue. This happens for every file I try to copy to the NFS: operation isn't permitted, but an empty file is created, and succeeds on a retry. Using a graphical desktop environment in Linux, I get the same issue where a dialog appears that the operation wasn't permitted, but if I select retry, it then asks if I want to overwrite the 0 byte file, which succeeds when I say yes.

In short, I can write to the NFS, but not in a way that I would expect. Copying files from and removing files from the NFS works without issue. Touching a file on the NFS works without issue too. What do I have wrong with my setup here? Any help is greatly appreciated!
 

KrisBee

Neophyte Sage
Joined
Mar 20, 2017
Messages
1,135
To my mind, simultaneously sharing the same data(set) via NFS and SMB is what you'v got wrong. Sounds like a recipe for inconsistent results. You might get a way with it if one or other of the two protocols is configured for read-only access.
 

jlkbah

Newbie
Joined
Oct 8, 2019
Messages
2
Thanks for the suggestion KrisBee. I actually started again from scratch this morning and saw this behavior before I had setup the SMB sharing. I just disabled SMB and tried again to be sure and the behavior still persists.

In my mind, this feels like a race condition or impatience on the part of the Linux system. If you can't put data into a file until it first exists, and if it takes too long to create the file node in the inode tree, the cp operation fails. Do I possibly have a bad timeout value in my fstab? I set timeo=20. I will adjust that to see if things improve.
 

stewartLG

Neophyte
Joined
Dec 21, 2016
Messages
11
I'm finding myself with the same problem. Here's what that looks like, from the client side:

root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso# ls -l
total 0
root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso# cp /home/big_raid/bitnami-gitlab-8.5.1-0-linux-x64-installer.run .
cp: cannot create regular file './bitnami-gitlab-8.5.1-0-linux-x64-installer.run': Operation not permitted
root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso# ls -l
total 1
-rwxrwxrwx 1 4294967294 root 0 Jul 1 19:58 bitnami-gitlab-8.5.1-0-linux-x64-installer.run
root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso# cp /home/big_raid/bitnami-gitlab-8.5.1-0-linux-x64-installer.run .
root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso# ls -l
total 1
-rwxrwxrwx 1 4294967294 root 360344049 Jul 1 19:58 bitnami-gitlab-8.5.1-0-linux-x64-installer.run
root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso# rm bitnami-gitlab-8.5.1-0-linux-x64-installer.run
root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso# ls -l
total 0
root@griffin:/mnt/ScarfolkProxmoxBackups/template/iso#
jlkbah, did you ever get anywhere with this issue? I'm running FreeNAS-11.3-U3.1.
 
Top