Samba share from CentOS has unusual permission issues from Mac OS.

Factual Questions
1

This has been bugging me for a while, and I never seem to be able to find the source of the problem. So I thought I would post here to get ideas from those of you experienced with Samba shares hosted on CentOS and making them accessible to Macintosh desktop systems.

In our LAN, we have workstations which are Linux, Windows and Mac. I don’t recall when this problem first started with the Mac, but it seems to be over a year ago. And the behavior of the problem is inconsistent and not always reproducible.

CentOS Linux release 7.5.1804 (Core)
Samba version 4.7.1.

Macintosh Mac OS 10.13.6

Each workstation uses Samba user login smbuser.

This is the problem, and only on the Mac. You can create a directory on the Samba share, move them around between directories, rename them, delete them, without a problem most of the time. But then for some reason, and this is why I’m posting about it, I need some trouble-shooting tips here, a Mac user tries to move the folder from one directory to another on the Samba share and will be prompted to enter in a username and password. If the user enters in the smbuser and password, it doesn’t accept it. If even tried entering in user name root and the password, and while it does accept that, you it doesn’t let you move the folder.

I have looked into the permissions and the permissions are 0775. For trouble-shooting while it wouldn’t let me drag a folder and put it in another folder, I did a duplicate of the folder creating a “folder name copy” and I was able to drag elsewhere and rename it.

I have logged into the shell on the CentOS file server and doing a ls -ls, I could see the permissions and owner group and group are OK. I use the ‘stat’ command to confirm this, and it is an exact match. But for some reason, either Samba/CentOS or the Mac OS is not allowing some of these file/folder changes to the Samba share to take place.

I have looked in SMB logs and I don’t see anything there. Is there some place else to look so when it gets prompted for permissions I can gather more debugging information? But from where can this be done on the Mac or on Samba/CentOS?

This is only happening on the Mac, the Linux and Windows workstations don’t have this issue.

Here is a generic version of the smb.conf being used on CentOS for this LAN:

I’m open to suggestions to how to fix this problem. Willing to try things out too, of course. Thanks in advance!

2

Don’t assume that it is a permission problem just because the computer tells you so.

Computer systems are given only a limited number of ways that they can report failure, and frequently the reporting layer doesn’t actually know the cause of the functional error.

In your case, the directory move operation failed: all the interface knows is that it failed: it gives you a chance to try again as a different user.

I don’t know what is causing the problem, but since you suggest that it is inconsistent, possibilities to consider are (a) the MAC is making the folder the ‘active’ folder before trying to change it, (b) you are having trouble creating the hidden files used by the Mac © you are connecting with a protocol other than the one you think you are (ftp, nfs afp).

3

I’m not assuming anything at this point. I know from experience with Samba things like this relate to permissions and authentication for logins. But whatever those problems were, it was usually it worked or not. This doesn’t seem to follow a real pattern. Some folders in a directory won’t let you rename them, while others do. One thing is constant, when this does occur, it stays that way even if I restart Samba. The only work around has been to login through the shell and do things there.

For now, I have placed this in the smb.conf file:

Note that it is commented. This generates a lot of data for the log files. So next time this unexplained behavior occurs I’m going to uncomment this line, restart Samba and repeat the action. Then examine the logs to see if I can get more clues as to what is going on. Even if it were an error message or warning that said something like “Can’t establish foobaz on myfile” I would at least have something to research further.

The protocol is SMB. I have even removed the Mac’s hidden files in the directory/folder and that doesn’t stop this odd behavior. I would describe this Samba share environment as simple. I do know that adding the

to the smb.conf was needed for support an older Windows 7 system. But my research has not turned up that the Mac cares about ntlm.

It could be the “active” directory issue you describe, but what is causing the events to behave abnormally is the mystery.

I’ve never really had to dig into the higher level Samba logs before, so this will be a learning experience.

4

This is probably not the source of your problem, but do I understand correctly that each user is sharing auth credentials? It sounds like they’re sharing the same username/password pair.

If so, you should know (if you don’t already) that this is a pretty bad practice from a security perspective. Furthermore, there can be issues with the maximum number of concurrent sessions for a given user which might create the symptoms you describe.

Is there some reason why users are sharing auth credentials? Is there some reason they’re not using domain auth credentials?

5

Usually I would be concerned about security. However, this specific server running Samba is on a LAN for in-house use only. It isn’t accessible from the internet. So we don’t have the concern of who owns what file since everyone needs and has access to the same thing. This problem has occurred when I’m the only user on the system so I don’t think it is capacity related.

6

Oh! So the whole LAN is air-gapped, then? If so, why require a password at all?

How do you know you’re the only user on the system if you’re all sharing the same auth credentials? You may be alone in the office, but someone may have left a Finder window open or done something else that prevents their session from going stale. It’s just a theory, and whether you think it’s worth investigating isn’t really my concern.

Two things are unclear to me: 1) why you’re password-protecting the samba share in the first place, and 2) why you’re waiting for the problem to happen before you set that log level. You say that it “generates a lot of data,” and that’s precisely the point. You must be very tight on space if you can’t store the relevant samba logs. Even if your /var partition is tiny, you could write a little shell script to move the accumulated logs to a partition with more space. I mean, reading the logs is a pretty fundamental problem-solving step in situations like this.

7

I’ve found before that, if I didn’t put a password on a Samba share, some software would just not let me in.

Is it possible that moving the files to that folder would make the full path too long for one of the files? I ran into this issue before. The reason it caused problems is complicated, but it has to do with reusing file handles. I wound up adding the bold/underline part to my mount command, which fixed the issue.


USER=*user* PASSWD=*pass* mount.cifs //192.168.254.1/Users Users **-o nounix,noserverino**
8

Thanks, interesting. I will have to pay attention to the file/folder length to see if that’s part of the pattern to the problem occurring.

Was this problem you had with a Mac running a Samba client to connect to a Linux Samba server?