strange file permission problems (gvim creating 4913 file)

[raymod2]

I'm running FreeNAS-9.1.1-RELEASE-x64 (a752d35) and I am seeing a very strange file permissions problem while accessing a CIFS share from my Windows 7 machine:

1) navigate to the share folder (\\freenas\share) with Windows Explorer
2) right click and select New->Text Document, name it foo.txt
3) open the file with gvim (a file called .foo.txt.swp is created)

At this point I can exit gvim, .foo.txt.swp will be deleted, and I can delete foo.txt. If I continue with the next step things get weird.

4) enter some text into the file, save it, and quit gvim

Now a file called 4913 appears in the current directory. The Read-Only attribute is set on this file and foo.txt. If I try to delete either file I get an error that says "This action can't be completed because the file is open in another program". If I try to remove the Read-Only attribute I get an error that says "An error occurred applying attributes to the file: \\freenas\share\4913 Access is denied." The only way to remove the files is to SSH into FreeNAS and delete them from the Unix command line.

Can anyone shed some light on what is causing this?

 

[raymod2]

I spent hours trying to figure this out and finally, out of desperation, I performed a "Reset to factory defaults" and reimported the pool. I used the same settings as far as I can tell but now the problem is gone.

 

[raymod2]

I moved my CIFS share mount point to a different pool and the problem is back. A factory reset is not working this time. Has nobody else run into this problem?? I am considering going back to 8.0.2 at this point even though that will require rebuilding one of my pools.

 

[raymod2]

Another data point. If the directory has 755 permissions (ie. write permission only for the owner) then I can create a file in that directory over CIFS but I cannot rename it or delete it. It says "You require permission from FREENAS\guest to make changes to this file". Which is strange because I am using "Anonymous" for the CIFS authentication model and the "Guest account" is set to "guest". Doesn't that mean that file operations performed over CIFS use the guest account? Why would I require permission from FREENAS\guest if I *am* guest?

 

[cyberjock]

No, there is no FreeNAS/guest. Guest account is not a real account. It's more like the absence of any other permissions granting access. And if you created an account called "guest" you have made a horrible mistake.

 

[raymod2]

Creating a guest account is a horrible mistake?

From http://doc.freenas.org/index.php/Windows_(CIFS)_Shares#Configuring_Anonymous_Access:

Create a guest user account to be used for anonymous access in Account → Users → Add User

 

[raymod2]

More strange behavior:

If I uncheck "Disable password login" for the guest account and then reboot the problem goes away. If I then check "Disable password login" and reboot the problem comes back. Also, I am now seeing the following error in the console:

Nov 9 12:54:48 freenas smdb[3282]: [2013/11/09 12:54:48.237419, 0] ../libcli/auth/ntlm_check.c:54(smb_pwd_check_ntlmv1)
Nov 9 12:54:48 freenas smdb[3282]: smb_pwd_check_ntlmv1: incorrect password length (74)
Nov 9 12:54:48 freenas smdb[3282]: [2013/11/09 12:54:48.237938, 0] ../libcli/auth/ntlm_check.c:54(smb_pwd_check_ntlmv1)
Nov 9 12:54:48 freenas smdb[3282]: smb_pwd_check_ntlmv1: incorrect password length (74)

 

[raymod2]

If anyone wants to reproduce this below are the steps to perform after booting from a fresh image. This is 100% reproducible for me.

1) Network->Interfaces->Add Interface
Interface name = freenas
IPv4 Address = 192.168.1.7
IPv4 Netmask = 255.255.255.0
2) Network->Global Configuration
IPv4 Default Gateway = 192.168.1.1
Nameserver 1 = 192.168.1.1
3) Storage->Volumes->Auto Import Volume
4) Account->Users->Add User
Username = guest
Create a new primary group for the user = unchecked
Primary Group = wheel
Full Name = anonymous access
Disable password login = checked
5) Storage->Volumes->/mnt/WD20EARX-RAIDZ->Change Permissions
Owner (user) = guest
6) Services->Control Services->CIFS Settings (wrench icon)
Authentication Model = Anonymous
Guest account = guest
Allow Empty Password = checked
7) Services->Control Services->CIFS (turn on)
8) Sharing->Windows (CIFS) Shares->Add Windows (CIFS) Share
Name = share
Path = /mnt/WD20EARX-RAIDZ
Allow Guest Access = checked
Only Allow Guest Access = checked

 

[raymod2]

Has anyone been able to reproduce this? I feel like I am talking to myself in here.

 

[milesf]

I am having the same permissions issue. (FREENAS 9.1.1 + Windows 7)
I can copy a file to the CIFS share, but when I try to delete it, I get the "you require permission from FREENAS\guest to make changes" error.
The permissions of the file are the following: "-rw-rw-rw- guest guest test.txt"

Is it a mistake to create a "guest" account? If so, the CIFS documentation needs to remove that step.
It makes sense that there could be a "guest" account mixup the CIFS user has special "guest" access which means no permissions, but then the file gets written with under the different "FREENAS\guest" user account. Later, the CIFS user with no permissions is unable to modify files owned by the "FREENAS\guest" account.

-----

While writing this post, I did a little more troubleshooting and discovered a workaround/solution. But I want to keep the initial post content to add search terms which may help others who are having the same problem.

I found that I can delete files from a directory if I change the directory permissions from "drwxr-xr-x guest guest" to "drwxrwxrwx guest guest". It's still a mystery why I could create files but not delete them in the former configuration.

 

[raymod2]

I opened another thread with further discussion here:

http://forums.freenas.org/threads/bizarre-symptoms-using-guest-account-on-cifs-share.16352/

I also opened a bug report:

https://bugs.freenas.org/issues/3396

The solution was to use "Local User" instead of "Anonymous" as the Authentication Model. You can still access the share without entering credentials using "Local User" and the problems described above will be avoided.