Hi,

Being new to Samba I am having issues with some of the files in a share I created. In the ITK-Backup share. I can copy most of the files in the share but for some files, I get "You need permission to perform this action. You require permission from Unix User\'user name here' to make changes to this file". What is strange is that from a Windows File Explorer window, I can copy most of the files in the directory without any errors. Really hard for me to troubleshoot when some of the files I can copy and some I can not in the same directory. I've tried changing permissions but that didn't work. I have no problems with the other shares and I can copy all files. Any help would be appreciated.

Here is the smb.conf for reference:


[global]
workgroup = 4HIMFG
server string = Samba Server %v
netbios name = ccicentos
security = user
map to guest = bad user
dns proxy = no

# Debug logging information
log level = 2

#============================ Share Definitions ==============================

[ITK-Backup]
path = /usr2
browsable =yes
writable = no
guest ok = yes
read only = yes

[ITK-Share]
path = /usr2/f11/csv
browsable =yes
writable = yes
guest ok = yes
read only = no

[ITK-StyLnk]
path = /usr2/stay-linked
browsable =yes
writable = no
guest ok = yes
read only = yes

Please identify one file that you CAN work with, and one you CANNOT, and show the permissions AND OWNERSHIP on those two files. This form the LINUX side please, using 'ls'.

Hi,

Here you go...

-rwxrwxrwx. 1 barkegroup barkegroup 2048 Jan 10 12:22 /usr2/data/ccidata/APRPOD file I CAN work with
-rwxrwxrwx. 1 barkegroup barkegroup 9776 Aug 25 15:34 /usr2/data/ccidata/APRECN file I CANNOT work with

Note: files have no extensions.

Thanks,
Tim

Interesting!
I had suspected that there would be a difference, but none is visible.

Is "barkegroup" the user a user in Linux (in /etc/passwd) or in AD? Or both? If you use ls -u and ls -g on these files do the NUMERIC owner and group match?

Is the "barkegroup" the GROUP exist in Linux (/etc/group) or in AD or both?

If you try this and it fails, have you run fuser against it on the linux side to see if it is locked by a process?

Do you have just plain permission sets or are you using ACL on the linux host as well?

I think so. I believe that is what is causing the issue after some research. I did a test on one file that I cannot work with and made a break through. I copied it to a temp directory and then back to the working directory on the Linux side and then I was able to work with it on the Windows side. Did this with other files that I couldn't work with and same results and I was able to work with the files on the Windows side. I am now able to work with all files in the working directory on the Windows side with no permissions issues.

Would this be caused by ACLs? How can I tell if the Linux host is using ACLs? Is there anyway I can compare ACL permissions with a file that I can work with and a file I cannot work with?

These files I am trying to work with are files that were loaded on the server for our ERP system by a consulting group and were loaded before Samba was installed and initiated.

You can run

If it shows just output that is the same as wrx there are no ACL policy affecting the files. ACL is usually permissions and a plus sign to show there are ACLs.



-rwxrwxrwx+


It does however not make sense to me why the files work after being moved to temp and back.

Looking carefully at your output, i was on phone before and did not see this.


-rwxrwxrwx.

You see that dot after the permission... i bet that you are running a system with SELinux. It makes perfect sense now.

Output the directory using

I am very sure you will see something like samba_share_t somewhere.

This tells selinux that it is ok to allow access to this file because it is marked to be useable by samba. If it is anything other than that say http_cahche_t or whatever, selinux says, look samba, nice try but this file has noghing to do with your job so you ain't gonna use this sorry. Selinux will then block samba accessing that file.

So all files in that directory has to be labeled with the correct SElinux context.

This sort of thing may happen if you copy http files etc without relabelling them on the linux side.

Check if you have selinux enabled with
If it is an issue in the future you could run something like

So that will tell selinux to label all files in specified directory and subfolders to samba share context and it will survive reboots.

Seeing you made your own share directories that are non standard, run those and then it should magically work next time.

It will also automatically relable file created to that directory

1 members found this post helpful.

That worked perfectly! It was the SELinux security.

Thank you.