Samba works only if share is empty? [Solved, workaround]

[sturge]

Please forgive me if I've forgotten protocol. It's been many years since I've asked for help.

Scenario:
I have four computers, each running Mint 18.1 KDE. Each has the same user (dorian), and the same shared folder (/home/dorian/Public). From each, I can see the other three via samba. From any, I can read and edit existing files in the share on any other PC, but I can only write if the share is empty to begin with. That is to say, if on PC1 I create or move a file to /home/dorian/Public, that action will make that folder unwritable from any other PC. But if on PC1 /home/dorian/Public is empty, I can create as many files as I like from PC 2, PC3, etc.

smb.conf is default save for two lines added to [Global]:

Code: Select all

force user = dorian
name resolve order = bcast host lmhosts wins

I have followed every instruction at viewtopic.php?f=42&t=224391 , adapting for KDE (kdesudo kate) where appropriate.

I have also created a samba user on each (same as login for all four PCs) and the avahi bit from viewtopic.php?f=157&t=185410?f=157&t=185410#p960482 , and ensured the firewall is open to ports 137, 138, 139, 445, 5353 bidirectional.

May I ask for help from the local gurus, please? But please, treat me like I'm twelve and tell me line by line what I need to do. I'm not young, but I am relatively ignorant on this subject.

testparm -s

Code: Select all

Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "syslog" option is deprecated
Processing section "[printers]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_STANDALONE

# Global parameters
[global]
        server string = %h server (Samba, Ubuntu)
        server role = standalone server
        map to guest = Bad User
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        unix password sync = Yes
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        name resolve order = bcast host lmhosts wins
        dns proxy = No
        usershare allow guests = Yes
        panic action = /usr/share/samba/panic-action %d
        idmap config * : backend = tdb
        force user = dorian


[printers]
        comment = All Printers
        path = /var/spool/samba
        create mask = 0700
        printable = Yes
        browseable = No


[print$]
        comment = Printer Drivers
        path = /var/lib/samba/printers

net usershare info --long

Code: Select all

[Public]
path=/home/dorian/Public
comment=
usershare_acl=Everyone:F,
guest_ok=y

[altair4]

Note: I am not a regular KDE user. I have it in a VBox guest but I try to stay away from it if at all possible. At this level it shouldn't matter but if KDE is doing something funky ....

Let me see if I understand the symptoms correctly:

You have a share created on PC1 at /home/dorian/Public.
All the client machines can read, edit individual existing files within, and can even add new files to the share.
But if you as the local user on PC1 add a file to the /home/dorian/Public folder:

** Client machines can still read and edit existing files
** But are prohibited from adding new files

Erm ... this is a new one to me. What are the permissions of the Public folder when it becomes un-writeable:

Code: Select all

ls -dl /home/dorian/Public

The ability to edit an existing file is in fact a write so this is a peculiar problem that only affects new client additions to the folder? I have never seen or even read about such a symptom before/

[sturge]

You understand correctly, sir. Thank you for taking the time!

At all times, ls -dl /home/dorian/Public yeilds:

drwxrwxrwx 2 dorian dorian 4096 May 21 11:55 /home/dorian/Public

And you are correct in that this only occurs if the local user adds a file to the share. From that point, no new file can be created by a remote user, even though I use the same linux credentials from all 4 PCs, and each PC has the same samba credentials. If the folder is empty and a remote user creates a file, the local user is unaffected.

For clarity's sake, this isn't just on PC1, this vexing circumstance is repeated on all 4 of them.

[altair4]

I'm going to have to think about this a bit since I can't see - at the moment - how any of that is possible.

[sturge]

New datum:

It seems I can create as many files as i like as a remote user _until_ I refresh Dolphin. Then Dolphin's "Create New..." menu line is grayed out. This is true to and from any of the four PCs. Interestingly, it's also true when I use smb:// to attempt this on the _local_ machine.

I'm beginning to suspect a bug in Dolphin, though I have no proof.

Is there a method of testing this via terminal to take Dolphin out of the mix?

[altair4]

it's also true when I use smb:// to attempt this on the _local_ machine.

That was the key that allowed me to reproduce your symptom.

I have replicated your Public share on my VBox Mint KDE system and I can add new files with or without any added files locally from my normal ( Ubuntu, Xubuntu, .. ) system with no problems. Then I tried to add a file via samba locally on the KDE system itself and the "Create New" is in fact greyed out.

So I went old school and did a direct smbclient connection:

** First I created a test file in my home directory:

Code: Select all

touch sample.txt

** Then I made the connection:

tester@vmin18kde ~ $ smbclient -U guest //192.168.1.163/public
WARNING: The "syslog" option is deprecated
Enter guest's password:
Domain=[WORKGROUP] OS=[Windows 6.1] Server=[Samba 4.3.11-Ubuntu]
smb: \>

Side note: I could not run smbclient specifying the host name ( vmin18kde in my case ) or the mDNS qualified host name ( vmin18kde.local ) only by ip address. I don't know why that happens but it's another problem for another time.

** Then I added the file I created to the share:

smb: \> put sample.txt
putting file sample.txt as \sample.txt (0.0 kb/s) (average 0.0 kb/s)

And then I disconnected:

smb: \> quit

Your intuition was correct as the sample.txt file was added to the share.

On the surface it looks like a dolphin samba client issue but I will play around with this a bit more. Maybe it's just how dolphin created the samba usershare that's the issue.

[altair4]

I have a workaround if you are interested. Mount the share using CIFS:

I created a mount point in my home directory:

Code: Select all

mkdir /home/tester/SMBShare

Then I manually mounted that hosts samba share to that mount point:

Code: Select all

sudo mount -t cifs //vmin18kde.local/Public /home/tester/SMBShare -o username=guest,password=xxx,uid=1000,nounix

The /home/tester/SMBShare folder gives me write access to the share through Dolphin.

To unmount the share:

Code: Select all

sudo umount /home/tester/SMBShare

You can set this up in fstab so you don't have to do all this by adding a line that looks like this:

Code: Select all

//vmin18kde.local/public /home/tester/SMBShare cifs username=guest,password=xxx,uid=1000,nounix,noauto,user 0 0

This share will not mount at boot but on demand:
** You will get a link on the side panel of Dolphin automatically.
** Selecting it will mount the share.

You seem t have a lot of machines there and unfortunately you would have to add each one to fstab ~ /home/tester/PC1Share, PC2Share, etc,...

The following is not something I'd recommend since I don't know what the long term affects of doing something like this would be to KDE but I installed Thunar which is XFCE's file manager and it works just fine with this. That makes me think it is in fact a Dolphin bug.

EDIT: Just found a bug report on this: cant write to smb shares which has write access
There must not be a lot of KDE + Samba users.

[sturge]

Sir, you are both clever and generous. Thank you so much for your help!

[sturge]

I've found another, simpler workaround:

Don't work in the top shared directory. Subdirectories always seem writable.

Also, it seems to be a bug in kioslave, not Dolphin directly.

[altair4]

That is one wacky bug.

The following is more of an FYI:

There is one advantage to the fstab method should this be an issue. You can set the version of SMB that mount.cifs uses to communicate with the server. A Linux samba server like it's Windows and MacOS counterparts will auto-negotiate the SMB version it uses with the client all the way up to SMB3.

But when you connect to the server with a Linux file manager you are limited to SMB1. When you connect with a mount.cifs ( as in fstab ) you are also connecting by default with SMB1 but mount.cifs allows you to alter it so that you can specify the highest protocol level that your Linux server can accept with the option vers

In the example I gave above the line in fstab would look like this:

//vmin18kde.local/public /home/tester/SMBShare cifs username=guest,password=xxx,uid=1000,nounix,noauto,user,vers=3.0 0 0

If these shares are only used for occasional file transfers it most likely wont make any difference and I am always an advocate for the simplest solution but running at SMB3 is far more efficient and faster that SMB1

[sturge]

Good to know, and I may yet do that. I wonder why Linux wouldn't negotiate with Linux. Hmm, now I wonder if that smb3 can't be specified another way, like in smb.conf. Guess I'll have something to read about over the weekend

My hunch on the bug: Someone may have just mistakenly referenced or copied cdfs instead of cifs; once written, the writable bit would flip.

EDIT: That was fast! This is from update notes on Samba 4.1.

The default protocol for smbclient and smbcacls is still SMB1 (the NT1 protocol dialect). An SMB2 or SMB3 connection can be selected in one of two ways. The easiest way to test the new protocol connection is to add the -mMAX_PROTOCOL command line switch to either smbclient or smbcacls.

[altair4]

Running Linux on the desktop is all about managing bugs. How many can you tolerate? How many are you comfortable using workarounds? How long will you put up with them?

You can in fact set the default client smb dialect higher than SMB1 ( or NT1 in samba-speak ) with the parameter client max protocol in smb.conf. This doesn't affect a cifs mount since mount.cifs isn't controlled by smb.conf.

The reason it's not set that way by default is because of another bug that breaks netbios network browsing for hosts.

Right now, I can open up my file manger or run smbtree and see all of the hosts in my network by their netbios names. If I were to set client max protocol = SMB3 I would see none of them. The only hosts I would see would be those that announce their presence using an Avahi ( or Apple's Bonjour ) service announcement because they don't use netbios. That’s fine in an all Linux or a Linux / MacOS network - not so much if Windows is involved and Windows owns the desktop space..