1

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"?

Your Answer

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

Browse other questions tagged or ask your own question.