I have a really strange problem with Samba running on Centos 7. I have some anonymous shares that are writeable by everyone. Usually I access these shares from a) windows pc's that are being repaired, and b) linux pc's that are mounting them via GVFS.
Just recently (I'm not sure when it started, potentially after a system-wide update on the server last week) I noticed that I cannot write to subdirectories of the shares when they are mounted via GVFS. I have tried it both on Linux Mint Qiana and Sylvia. I can edit, create, and delete files in the root of a share, but I can do none of those things in any subdirectory of any share on that sever. The error I get is "permission denied".
Strangely, these operations all work as expected at all levels via either: windows, smbclient, or mount.cifs.
Also, on the same linux pc's that fail to work correctly on this server, I have full write permissions on a similarly configured Debian server with shares mounted via GVFS so this leads me to believe it has something to do with the Centos 7 server rather than the GVFS implementation on the pc's.
Note that we only ever access these shares anonymously regardless of the connection method.
Here is my Samba config:
[global] workgroup = WORKGROUP server string = Samba Server %v netbios name = server1 security = user map to guest = bad user dns proxy = no unix extensions = no #============================ Share Definitions ============================== [shared] path = /shares/shared browsable =yes writable = yes guest ok = yes read only = no follow symlinks = yes [installers] path = /shares/installers browsable =yes writable = yes guest ok = yes read only = no follow symlinks = yes [tools] path = /shares/tools browsable =yes writable = yes guest ok = yes read only = no follow symlinks = yes wide links = yes [drivers] path = /shares/drivers browsable =yes writable = yes guest ok = yes read only = no [cdimages] path = /shares/cdimages browsable =yes writable = yes guest ok = yes read only = no [windows_sps_updates] path = /shares/windows_sps_updates browsable =yes writable = yes guest ok = yes read only = no
Here is my ownership, permissions, and selinux context info for those directories on the server:
drwxrwxrwx. nobody nobody unconfined_u:object_r:samba_share_t:s0 cdimages drwxrwxrwx. nobody nobody unconfined_u:object_r:samba_share_t:s0 drivers drwxrwxrwx. nobody nobody unconfined_u:object_r:samba_share_t:s0 installers drwx--x--x. nobody nobody system_u:object_r:samba_share_t:s0 lost+found drwxrwxrwx. nobody nobody unconfined_u:object_r:samba_share_t:s0 shared drwxrwxrwx. nobody nobody unconfined_u:object_r:samba_share_t:s0 tools drwxrwxrwx. nobody nobody unconfined_u:object_r:samba_share_t:s0 utilities drwxrwxrwx. nobody nobody unconfined_u:object_r:samba_share_t:s0 windows_sps_updates
And for a subdirectory:
-rwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 AfterTheRain.jpg -rwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 analyze_minidump.bat drwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 autoit scripts -rwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 AutoItX3.dll drwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 backup -rwxr--r--. nobody nobody system_u:object_r:samba_share_t:s0 cant_hug_every_cat.mp3 -rwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 devcpp-4.9.9.2_setup.exe -rwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 dilbert_kung_fu_coffee_cup.jpg -rwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 dilbert_kung_fu_coffee_cup.png -rwxr-xr-x. nobody nobody unconfined_u:object_r:samba_share_t:s0 dism.txt
And here are how the permissions show in that subdirectory when mounted via GVFS on a linux pc:
-rwx------ 1 lytithwyn lytithwyn 363665 Aug 19 2011 AfterTheRain.jpg -rwx------ 1 lytithwyn lytithwyn 129 Feb 4 2015 analyze_minidump.bat drwx------ 1 lytithwyn lytithwyn 0 Mar 8 2018 autoit scripts -rwx------ 1 lytithwyn lytithwyn 460104 Jun 1 2014 AutoItX3.dll drwx------ 1 lytithwyn lytithwyn 0 May 28 2014 backup -rwx------ 1 lytithwyn lytithwyn 2371114 Aug 20 15:54 cant_hug_every_cat.mp3 -rwx------ 1 lytithwyn lytithwyn 9326468 Mar 30 2017 devcpp-4.9.9.2_setup.exe -rwx------ 1 lytithwyn lytithwyn 489217 Jul 1 2015 dilbert_kung_fu_coffee_cup.jpg -rwx------ 1 lytithwyn lytithwyn 2663796 Aug 29 2013 dilbert_kung_fu_coffee_cup.png -rwx------ 1 lytithwyn lytithwyn 95 Feb 12 2018 dism.txt
I don't think the problem is with SELinux, as I don't get anything output from sealert -a /var/log/audit/audit.log that mentions anything about Samba after I've tried to alter a file. I've rebooted the server as well, just in case it was something transient and flaky.
** Edit (Additional info): Later I upgraded my own workstation to Linux Mint 19.1 (Tessa), and mounting via mount.cifs as guest stopped working; I got the same result in that I could not write to any directory below the top level.
After some experimentation with various options like "nounix" and various "vers=x" values which yielded no change, I found that if I supplied an empty password to mount.cifs instead of the "guest" option, it worked. Using the -v option to mount.cifs I got the following results:
sudo mount.cifs //server1/shared /home/lytithwyn/shares/shared/ -o guest,uid=lytithwyn -v
mount.cifs kernel mount options: ip=fdf2:754b:f75b::cd7,unc=\\server1\shared,uid=1000,user=,pass=********
sudo mount.cifs //server1/shared /home/lytithwyn/shares/shared/ -o uid=lytithwyn,password= -v
mount.cifs kernel mount options: ip=fdf2:754b:f75b::cd7,unc=\\server1\shared,uid=1000,user=root,pass=********
So that showed me that with the "guest" option, no username was specified, but with "password=", root was automatically supplied as the username. After that, trials revealed that manually specifying any username (even one that didn't exist either on the server or workstation) yielded a mount on which I could write to a directory at any level.
So I'm guessing it all comes down to the default options passed in by various mounting tools/helpers has changed across versions and perhaps the version of samba on my CentOS 7 is incorrectly handling situations where no username is passed in, i.e., that situation is not triggering the behavior specified by "map to guest = bad user"?
