You are not logged in.
Pages: 1
In my home LAN I run a Samba file server. Since the last kernel update I have no longer write access to the shares because all files belong to root (permistion 755). Kernel 4.13 apparently uses SMB3 as standard and unix extension seem not to work (?). How can I get write permission for normal users?
My smb.conf looks like this:
[global]
bind interfaces only = Yes
interfaces = 172.17.2.23/255.255.255.0
server string = server
workgroup = GROUP
os level = 2
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
guest account = root
map to guest = Bad User
security = USER
keepalive = 30
dns proxy = No
idmap config * : backend = tdb
...
[Scanner]
comment = My Scanner
path = /mnt/Data/Data/Scanner
guest ok = Yes
read only = No
...
The corresponding line in the fstab:
//172.17.2.23/Scanner /home/thomas/Scanner cifs password= 0 0
Last edited by Thomas_Do (2017-10-03 11:03:00)
Offline
https://bbs.archlinux.org/viewtopic.php?id=230324
Edit: is arch / 4.13 client, server or both?
Last edited by seth (2017-09-29 20:55:44)
Offline
My problem is different, I can connect but read-only due to changed file permissions.
Edit: is arch / 4.13 client, server or both?
The problem appeared when the client was updated. Meanwhile the server runs 4.13, too. No difference.
I have an other client with 4.12 that works fine.
Offline
Tried to explicitly add "mapposix" to the options?
Offline
Tried to explicitly add "mapposix" to the options?
Just tried, no difference.
Offline
This random google up suggest it might relate to the protocol version. https://forum.synology.com/enu/viewtopic.php?t=120065
So I'd still suggest to try eg. "vers=2.0" (resp. any version < 3.0, maybe even 1.0 - just to isolate the problem)
Offline
I tried this already. But after your suggestion I tried again with a reboot instead of unmount & remount. And really, "vers=1.0" works (2.0 does not). Thanks a lot for your help! However, I will leave this thread unsolved, hoping for sugestions how to configure samba with up-to-date protocols.
Offline
I'd though suggest to mark this as resolved and open a new thread that focuses on the actual problem (seems this has been a problem before) in subject and first post.
Alternatively edit this one, but the following discussion might distract readers.
Offline
Try setting log level in smb.conf default = 0 max = 10 and examine the log output for vers=1.0 compared to vers=2.0?
Offline
I tried this already. But after your suggestion I tried again with a reboot instead of unmount & remount. And really, "vers=1.0" works (2.0 does not). Thanks a lot for your help!
That helped me as well. Thanks, seth.
I am running samba on a Banana Pi Pro with bananian, by the way.
Offline
I'd though suggest to mark this as resolved and open a new thread that focuses on the actual problem (seems this has been a problem before) in subject and first post.
Alternatively edit this one, but the following discussion might distract readers.
I am not sure I understand what you mean with "the actual problem (seems this has been a problem before)". As I stated in my first post, I think that the recent change in the samba protocol leads to a different handling of unix file permissions. This led in my case to the observed read-only restriction.
What I would like to find out is, how to pass the original file permissions to a samba share using SMB2 and SMB3. If this is not possible, I would like to know, what alternatives could be used to get a simlar result.
Try setting log level in smb.conf default = 0 max = 10 and examine the log output for vers=1.0 compared to vers=2.0?
I did that but can not find any hint to solve the problem.
Offline
The actual problem is that, as we figured, this does not work in higher SMB versions (at all) - so your problem is that mapposix (resp. "something" in the unix extensions) does not work on higher level SMB, not that the latest kernel release introduced a technical regression. The only reason for your problem is the altered SMB version default (1.0 -> 2.x)
The idea is that stressing this a bit more prominent w/o the noise of the following comments in this thread might help to get a better response on the issue.
Offline
You might also want to review these settings
guest account = root
map to guest = Bad User
Even if it is not a security issue for your system this appears to be a relatively unusual combination that may not see much testing.
Offline
Even if it is not a security issue for your system this appears to be a relatively unusual combination that may not see much testing.
Thanks for your comment. You are right, this configuration it is a little unusual. Changing these settings has no effect on the problem, though.
Offline
I mark this thread as solved because I found a workaround. Thanks all who helped!
SMB2 and SMB3 apparently have no implementation for the unix extensions:
Note that when connecting using SMB2 or SMB3 protocols
the UNIX extensions are no longer available inside the
smbclient command set. This is due to UNIX extensions
not yet being defined for the SMB2 or SMB3 protocols.
Offline
Do tell us what is the workwaround...
Offline
read the thread? esp. post #7 ...
Offline
Thanks!
Offline
Pages: 1