4

I have a FreeNAS box with 40 or so SMB shares. Mostly works no problem. Except for this one share where I can't create folder sometimes based on the name of the folder.

I noticed, because if I browse to the share within Windows and create a "New Folder", I just get a "permission denied" error (I assume this is because explorer makes a folder named "New Folder" first and then changes the name later). But if I browse to the directory from within my WLS instance, and create the folder named 'test' via mkdir, it creates it no problem.

Unless I try to make a folder 'New Folder' with mkidr.

This seems to be the case with a bunch of random folders, and from the FreeNAS box itself, I can create these folders no problem. The folders also certainly don't exist before hand, but if I create with FreeNAS, I'm able to delete them no problem from the places mounting these shares. But then not able to create them again.

This sounds like one of those problems where I'd just reboot the box, but around ~100 or so people are using it so I am trying to do this with as little down time as possible.


EDIT

This is still happening and I have no clue as to what's going on. Some test cases/examples that make no sense together

  • Making a new folder in my Documents named "New Folder" and copying it to my share results in permission deined.
  • Making a new folder called "New Folderx" in my Documents and copying it over works just fine. I can also rename this folder to anything except "New Folder"
  • On the server itself, running su -m brian -c 'mkdir "New Folder"' works no problem, and from Windows, I can rename or delete this folder.
  • "New Folder" is just an example folder that doesn't work, other folder names also randomly have these exact same issues
  • This is only true for the root of the share, inside other folders, I don't have these issues

some sanity checks

$ getfacl .
# file: ../Share
# owner: root
# group: company
       group:super:rwxpDdaARWcCos:fd-----:allow
            owner@:rwxpDdaARWcCos:fd-----:allow
            group@:rwxpDdaARWcCos:fd-----:allow

$ groups brian
brian super
$ sharesec -v 'Share'
REVISION:1
CONTROL:SR|DP
OWNER:
GROUP:
ACL:S-1-5-21-4096896313-3432959665-639265334-1283:ALLOWED/0x0/FULL
ACL:S-1-5-21-4096896313-3432959665-639265334-1287:ALLOWED/0x0/FULL
$ net groupmap list | grep super
super (S-1-5-21-4096896313-3432959665-639265334-1287) -> super
32
  • 1
    Ok, I wanted to make sure you have mutual understanding. I think I know where it crashes (the source code), but don't know the reason. Does it fail on names without any space?
    – tukan
    May 14, 2020 at 14:13
  • 1
    My guess is that the issue has to do with the ACL (samba and zfs (zfsacl)) could you try adding these flags to your share? nfs4:mode = special nfs4:acedup = merge nfs4:chown = yes (taken from here samba.org/samba/docs/current/man-html/vfs_zfsacl.8.html)
    – tukan
    May 14, 2020 at 14:23
  • 1
    Not sure if this helps, but this is also the only share I have where random new folders fail to inherit the permissions from the share folder correctly, maybe 1-2 times a day I have to manually set a folders permissions correctly (folders created by a service I have running on this machine) May 14, 2020 at 14:29
  • 1
    Ahh interesting, I didn't think about the inheritance problems being the source of it, it makes sense actually because it's the same problem for both folders. And the folder gets created with root only access, hmmm, somewhere else to look now May 14, 2020 at 17:41
  • 1
    I'll post that as an answer, which probably is not worth the bounty as it does not solve the issue, but you know what to look for now.
    – tukan
    May 14, 2020 at 18:11

1 Answer 1

2
+100

It appears that the root cause is connected to the fact that Brian has to:

This is also the only share I have where random new folders fail to inherit the permissions from the share folder correctly, maybe 1-2 times a day I have to manually set a folders permissions correctly (folders created by a service I have running on this machine)

The samba fails at the last moment when it tries to resolve already created filename at default: branch (!resolved_name) check_reduced_name function (you can follow the code further). The solution is connected to the resolution of the permission inheritance issue, where service has the same problems.

3
  • I'll come back to accept this for sure once I confirm that solving the inheritance issues is indeed the issue, but I've awarded the bounty anyway since you've been so helpful so far May 15, 2020 at 12:36
  • Oof, I was going to try just making a new ZFS dataset and point the samba share there instead, but the FreeNAS UI won't let me with the error "Error getting pool data", maybe there's larger issues at play here May 15, 2020 at 14:03
  • 1
    @BrianLeishman that sounds nasty, you definitely need to check your HW and zfs integrity. Thank you for the reward.
    – tukan
    May 17, 2020 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.