no way to read and write files on mounted samba share on hardy

[hva]

Binary package hint: samba

since i've upgraded to hardy i'm not able to use my samba shares anymore when mounted.
i used to mount a samba share from file server at boot through fstab, here is the fstab line:

//server/share /media/server_dati smbfs auto,iocharset=utf8,uid=user,gid=user,credentials=/root/.cifscredentials,noperm 0 0

share is correctly mounted, no error messages, and permissions on files and directory are correctly set, but despite this, i can't even read files on the mounted share, always given a "no permission" error. i cant process files through less or cat, can't move or delete them, can't copy them... no access at all, though ls reports good permissions and therefore i suppose i should be allowed to use them.
If i mount the same share through nautilus net resources i can access files perfectly, and fstab mounting under gutsy used to work as expected.

i tried changing fstab line with file_mode and dir_mode set to 0777 or 0770, but no luck: files seem to have right permissions but can't be read or written.

tried to use cifs instead of smbfs, but same results (i suspect in hardy they are now the same, isn't it?).
i think this is quite a serious step back.
will switch to nfs: since it's a client problem windows workstations should be able to access old samba shares as usual (the server is an old machine with a very old mandrake linux), but it would be nice to have it working again.

[Chuck Short (zulcss)]

Is there anything in your log files on the samba server?

Thanks
chuck

[TMwtP (de7utvalgte)]

I have the exact same problem. This is indeed a huge step back - I have all my music, movies and stuff on a file server. After upgrading everything is unusable. I can create new files and delete them, but I can't play existing mp3s.

[tonyw (tony-whyman)]

There certainly appears to be a problem with the Hardy CIFS/SMBFS implementation. For me it has broken a wine application that used smbfs/cifs to access a remote set of files.

We use an old Windows based account packages (TAS Books). Works fine and runs under Linux/wine, so no real need to replace it. It uses a Btrieve database implemented as a set of files in the same directory. In our deployment, the database files are on a remote server with the directory mounted as a remote share. This allows access from several clients (but not simultaneous). The setup worked fine under ubuntu 7.10. Both server and clients were upgraded to Hardy last weekend and this broke the application. It claims that the remote files are being used by a "Maintenance Utility"- although other wine apps can open them for reading.

The fstab entry seems pretty standard:

//myserver/tasdata /home/tony/tasdata cifs credentials=/etc/samba/mysecret,uid=1000,gid=1000,auto,rw 0 0

Restarting a client with the 2.6.22 kernel (no other change) fixes the problem and the application works. So the problem (change) seems to be in the kernel or one of its loadable modules.

The mounts appear to work, regardless of whether they are declared as cifs or smbs and the remote files are accessible through bash and text editors. All permissions appear correct - but something has changed - and that something breaks the application. As TAS Books is closed source, it's difficult to know what it is doing and why it can't see the files. My guess is that it can't get a file lock on one or more files - but that's just a guess. Alternatively, it may be something to do with opening a file for read/write.

Tony

[jan (jan-ubuntu-h-i-s)]

I have exaxctly the same problems. Due to this, my Ubuntu computer has started to be a nuisance, especially because downgrading back to 7.* is impossible, and gvfs cannot be disabled without removing Nautilus and the Ubuntu desktop. What a pain is hardy !

My configuration: 1 Ubuntu hardy destop, and a file server (90 MHz Pentium, 40Mb RAM) running another distro, with an old kernel 2.2.16-22. Using samba, no guest accounts, plain passwords, different UIDs for the same users on both machines.

I have performed the commands below
  515 cd /proc/fs
  517 smbmount //his01/jhh ~/t5
  519 cd cifs
  521 sudo sh -c 'echo 1 > traceSMB '
  522 sudo sh -c 'echo 3 > cifsFYI '
  523 cd ..
  524 smbumount ~/t5
...
  532 smbmount //his01/jhh ~/t5
  533 cat ~/t5/pldirs.txt
cat: /home/jhh/t5/pldirs.txt: Permission denied
  534 smbumount ~/t5

After the smbmount: the directory structure looks fine. On this particular file:
-rwxrwSrwx 1 jhh jhh 456 2008-04-12 14:26 pldirs.txt

Attached the logging. I've taken out the raw data blocks (hex codes).
At May 2 22:07:46 his08 kernel: [ 5020.107903] : the signature of the error

[jan (jan-ubuntu-h-i-s)]

In addition to the previous post, I also see strange behavior while connecting via Nautilus:
- directory displays OK.
- at opening a text file I get a strange authentication required pop-up, for a user called guest (see attached)
- then, everything seems to go fine after that.
- then an endless loop due to a circular reference in the fileserver filesystem, eating away all resources. May be caused by tracker trying to index the newly mounted filesystem.

[Marcin Mincer (marcin.mincer)]

The same problem. I have a smb share on server which is public and writeable, and with fstab like this:
//server/pub /media/pub smbfs guest,uid=1000,rw,iocharest=utf8,file_mode=0775,dir_mode=0777 0 0
only root can write to /media/pub (even though 1000 is uid of "normal" user). Files and dirs permissions seem to be ok.

Moreover Hardy can't umount share properly while shutting down and hangs before power is off. I have to umount shares manually before shutdown.

That's not the only problem with HH for me -- if you don't have to upgrade: DO NOT!

[tonyw (tony-whyman)]

Marcin, the unmount on shutdown problem has been noted elsewhere (bug #211631) and is probably a mis-ordering of the shtudown script.

[TMwtP (de7utvalgte)]

Hmm, I've been with the Ubuntu communty since 5.04, and this is the first time something as serious as this has occurred for me. For instance, I can browse my image files on the Samba server (a Fedora installation) as before, I even see thumbnails of my pics, but I can't open them. I can't play my audio files, I can't watch my videos.
I can put new files on the server from my Hardy, but can't copy them back locally.
I really can't live with this and must real soon face the perils of returning to 7.10. Of course the only way to do this is a clean install... aarrghh!

[Chuck Short (zulcss)]

As asked before is there anything in your logfiles?

Thanks
chuck

[TMwtP (de7utvalgte)]

My samba log files on the server doesn't show anything out of the ordinary. Remember - nothing has changed on the server, and as far as the server can tell I can access my files.

[jan (jan-ubuntu-h-i-s)]

I don't understand why it's set to incomplete all the time. People are requesting SERVER logs all the time, while a CLIENT log is attached. The bug clearly is in the CLIENT, not in the server, as the servers are always non-Ubuntu, unchanged systems of all kinds. If ever requesting a server log, please also indicate where in the attached CLIENT log you foresee that the Ubuntu people have messed up.

[abujafar (abujafar)]

I have the same problem.
I can mount and browse shares using nautilus or smbmount but i cannot read or write files.
Files Permissions are OK.
The server is Windows 2003 pc that shares a public access directory (no username/pass required)

[TMwtP (de7utvalgte)]

Problem solved for me!

http://ubuntuforums.org/showthread.php?t=707370&highlight=cifs+samba+hardy

Recompiling samba to use the smbfs libraries (as it should) did the trick.

[tonyw (tony-whyman)]

I can confirm that TMwtP 's solution also works for me. Recompiling samba on the client only and manually installing smbfs fixes the problem I had with Tas Books.

Looks like the CIFS client distributed with Hardy 8.04 is broken.

[jan (jan-ubuntu-h-i-s)]

Could you please help me out a little more on how to compile samba, so that I can try it as well ?

I installed git and autogen from the package manager.
Then I got the git package as described in:
http://wiki.samba.org/index.php/Using_Git_for_Samba_Development
I did autogen.sh in the samba/source directory, and then followed the instructions from
http://ubuntuforums.org/showthread.php?t=707370&highlight=cifs+samba+hardy
Now, no smbmount executable was generated.
furthermore 'make install' installed everything into /usr/local/samba.
With starting mount.cifs in that directory, I could not mount directories, but I suspect this has to do with that it's still using hardy's libraries.

[Steve Langasek (vorlon)]

There are several different sets of symptoms being described here, none of which are reproducible for me.
- the original bug report says that the file permissions on the local mount are correctly set, but the files are not readable or writable. This sounds like a permissions problem on the remote server, possibly because of a credentials problem?
- TMwtP reports that he can create new files and delete files on a cifs mount point, but can't read existing files. This is also very strange, and possibly points to a permissions issue either on the client, or on the server (again, the server permissions problem may point to an authentication problem).
- tonyw describes an application problem which may be a separate bug entirely.

For anyone seeing these problems with kernel CIFS mounts, can you please provide:
- version information about the server you're connecting to (if a Windows server, the version of the OS; if a Samba server, the version of Samba)
- for samba servers, the definition of the fileshare
- the exact commandline or fstab entry you're using when you experience the problem
- a full listing of server-side permissions on the shared directory, and the files contained within
- an ls -l of the client mount point, showing how the permissions appear on the client.

With this, it should be possible to track down these errors and find a solution for inclusion in Ubuntu 8.04.

[tonyw (tony-whyman)]

Jan,

You want to get the samba 3.0.28a archive from

http://us1.samba.org/samba/ftp/old-versions/samba-3.0.28a.tar.gz

expand it into a temporary location, cd to the source folder and enter the command:

./configure --with-smbmount --sysconfdir=/etc/samba --with-lockdir=/var/cache/samba --with-piddir=/var/cache/samba/ --with-configdir=/etc/samba

then enter "make" and all should be well. You will of course need the binutils package to be installed.

[Steve Langasek (vorlon)]

Jan,

For questions about building samba from source to re-enable the smbfs utilities, please follow up to the forums instead of to this bug report. This bug report should be kept focused on finding a solution to the actual bug that's preventing mount.cifs from working correctly (which, btw, I need more information on, per my previous comment).

Thanks!

[tonyw (tony-whyman)]

Steve,

To answer your questions about the bug I am seeing, I have compiled the following. Look below, there is a significant difference in the client side file permissions when cifs is used to mount the volume and when smbfs is used. This is fully repeatable and the listings below did not require system reboot, just different -t (cifs|smbfs) switches on the mount.

1. I first saw the problem after upgrading a single client to 8.04 (AMD 64 bit). The server was then Xubuntu 7.10 with standard up-to-date samba packages. This was then upgraded to 8.04 Xubuntu and the problem remained.

2. The definition of the share is:

[TASData]
 comment = TasBooks Data Files
 path = /raiddisk/shared/tasbooks
 valid users = @accounts
 force group = accounts
 read only = No
 acl check permissions = No
 directory mask = 0775
 force directory mode = 00
 browseable = No

3. The fstab is:

//olympus/tasdata /home/tony/tasdata cifs credentials=/etc/samba/tw.pw,uid=1000,gid=1000,auto,rw 0 0

4. The server side listing is:

-rw-rw-r-- 1 tony accounts 3584 2008-04-28 11:56 mt1pmt.b
-rw-rw-r-- 1 tony accounts 3584 2008-04-28 11:56 mt2pmt.b
-rw-rw-r-- 1 tony accounts 3584 2008-04-28 11:56 mt3pmt.b
-rw-rw-r-- 1 tony accounts 3072 2008-04-28 11:56 mt4pmt.b
-rw-rw-r-- 1 tony accounts 3072 2008-04-28 11:56 mtabacs.b
-rw-rw-r-- 1 tony accounts 6144 2008-04-28 11:56 mtabank.b
-rw-rw-r-- 1 tony accounts 3072 2008-04-28 11:56 mtabia.b
-rw-rw-r-- 1 tony accounts 26624 2008-04-28 11:56 mtabud.b
-rw-rw-r-- 1 tony accounts 3072 2008-04-28 11:56 mtacadv.b
-rw-rw-r-- 1 tony accounts 7680 2008-05-05 14:43 mtaccat.b
-rw-rw-r-- 1 tony accounts 10240 2008-05-15 22:13 mtacent.b
<truncated - all other files have the same permissions>

5. The client side listing (when mounted as CIFS) is:
-rw-rw-r-- 1 tony tony 3584 2008-04-28 11:56 mt1pmt.b
-rw-rw-r-- 1 tony tony 3584 2008-04-28 11:56 mt2pmt.b
-rw-rw-r-- 1 tony tony 3584 2008-04-28 11:56 mt3pmt.b
-rw-rw-r-- 1 tony tony 3072 2008-04-28 11:56 mt4pmt.b
-rw-rw-r-- 1 tony tony 3072 2008-04-28 11:56 mtabacs.b
-rw-rw-r-- 1 tony tony 6144 2008-04-28 11:56 mtabank.b
-rw-rw-r-- 1 tony tony 3072 2008-04-28 11:56 mtabia.b
-rw-rw-r-- 1 tony tony 26624 2008-04-28 11:56 mtabud.b
-rw-rw-r-- 1 tony tony 3072 2008-04-28 11:56 mtacadv.b
-rw-rw-r-- 1 tony tony 7680 2008-05-05 14:43 mtaccat.b
-rw-rw-r-- 1 tony tony 10240 2008-05-15 22:13 mtacent.b

The client listing when mounted as smbfs is:
-rwxr-xr-x 1 tony tony 3584 2008-04-28 11:56 mt1pmt.b
-rwxr-xr-x 1 tony tony 3584 2008-04-28 11:56 mt2pmt.b
-rwxr-xr-x 1 tony tony 3584 2008-04-28 11:56 mt3pmt.b
-rwxr-xr-x 1 tony tony 3072 2008-04-28 11:56 mt4pmt.b
-rwxr-xr-x 1 tony tony 3072 2008-04-28 11:56 mtabacs.b
-rwxr-xr-x 1 tony tony 6144 2008-04-28 11:56 mtabank.b
-rwxr-xr-x 1 tony tony 3072 2008-04-28 11:56 mtabia.b
-rwxr-xr-x 1 tony tony 26624 2008-04-28 11:56 mtabud.b
-rwxr-xr-x 1 tony tony 3072 2008-04-28 11:56 mtacadv.b
-rwxr-xr-x 1 tony tony 7680 2008-05-05 14:43 mtaccat.b
-rwxr-xr-x 1 tony tony 10240 2008-05-15 22:13 mtacent.b

7. The underlying problem is when the closed source TAS Books program tries...

[tonyw (tony-whyman)]

I think I have almost found the answer. Look at this bug:

https://bugzilla.samba.org/show_bug.cgi?id=2512

I turned off "Unix Extensions" on the server side and lo and behold I could mount the share on the client using CIFS and the program worked! It looks like CIFS is not telling the how truth when you do an ls -l on a remote share. It may report the local UID/GID as given on the mount, but when it comes to permission checking...

Unfortunately, turning off the Unix Extensions isn't an ideal answer as you lose things like symlinks. Making the UIDs and GIDs match over both client and server should allow Unix Extensions to be kept - but then you're back to the same UID management problems as for NFS.

[jan (jan-ubuntu-h-i-s)]

My server: an old linux server: Linux 2.2.16-22 #1 Tue Aug 22 16:16:55 EDT 2000 i586 unknown
/usr/sbin/smbd -V: Version 2.0.7

On the server: both accounts where the uid is the same as on the client, and (most) accounts where the uid differs from that on the client.
Passwords in plain text (local network, also supporting Windows XP en Windows 95 machines)

Shares: defined as:
[homes]
   comment = Home Directories
   browseable = no
   writable = yes

Command:
sudo mount -t smbfs //his01/jhh ~/t5 -o user=jhh

-----------

Did the client side log I (debug1.txt) attached to the bug report help you at all ?

 Mapping smb error code 12 to POSIX err -13
 Error in Open = -13
cifs_open returned 0xfffffff3
CIFS VFS: leaving cifs_open (xid = 30) rc = -13

netmisc is not coming from the samba git, so I looked it up at:
http://lxr.free-electrons.com/source/fs/cifs/netmisc.c
The mapping error string does not tell if it is a DOS or SVR error class. I guess it is a bad open mode:
 #define ERRbadaccess 12 /* Invalid open mode. */

If I look at the samba SERVER code, I guess that the new Hardy samba provides garbled (or improved ???) parameters to the open command, where map_open_params_to_ntcreate then breaks (rather than the PERMISSIONS) on the server.

The POSIX err -13 is then (incorrectly !) further propagated as a permissions error.

Furthermore: I am able to read the files using Nautilus, but I need to type my passwords a few times. It is just that mounting does not work. Therefore my first personal suspect were the interactions with the (for Hardy changed) gvfs and keyring.

[Steve Langasek (vorlon)]

Hi Jan,

The client-side log really only shows that the kernel driver got an error accessing the file, and mapped this to the EACCES, which I don't know to be incorrect.

The requested client- and server-side ls output, showing the respective permissions, would still be helpful here.

[Steve Langasek (vorlon)]

tonyw,

I'm glad to hear that you were able to get your application working!

Based on your output, I'm not convinced that your problem is the same as <https://bugzilla.samba.org/show_bug.cgi?id=2512>. For one thing, you mention that you're able to access the files from a text editor, so there at least doesn't seem to be a lack of read permissions; and in my experience, when unix extensions are used, whatever file permissions are shown on the client side are the ones that are actually enforced - and in your case the client permissions look ok.

One way to test whether permissions are the source of the problem, or whether it's some other aspect of Unix extensions causing the problem, would be to re-enable the Unix extensions on the server side and then use the 'noperm' option when mounting. If TAS Books works, then it's a permissions problem; if it doesn't work, then the problem lies with Unix extensions but not with the Unix permissions handling.

Finally, since this problem only occurs with a closed source application, it would be helpful to have some sort of client trace here: either a kernel client trace like the one Jan generated using the /proc/fs/cifs/traceSMB and /proc/fs/cifs/cifsFYI variables, or the output of 'strace -efile' showing what sort of file access the application is doing.

[jan (jan-ubuntu-h-i-s)]

Below the server side log, as for the file debug1.txt.
uid is same as on client, gid differs; gid is OK for client.
I did try to disable unix extensions on the client side, but this did not change the results
Further information on the systems that may help:
Under previous Ubuntu versions, I was able to mount this share with smbfs, but not with CIFS (probably due to permissions).

[2008/05/02 22:07:28, 1] smbd/service.c:make_connection(550)
  his08 (10.0.0.151) connect to service jhh as user jhh (uid=1015, gid=100) (pid 1795)
[2008/05/02 22:07:46, 0] smbd/nttrans.c:map_share_mode(443)
  map_share_mode: Incorrect value 80000000 for desired_access to file \pldirs.txt
[2008/05/02 22:07:52, 1] smbd/service.c:close_cnum(583)
  his08 (10.0.0.151) closed connection to service jhh
[2008/05/02 22:09:18, 1] smbd/service.c:make_connection(550)
  his08 (10.0.0.151) connect to service jhh as user jhh (uid=1015, gid=100) (pid 1797)
[2008/05/02 23:20:52, 1] smbd/reply.c:reply_sesssetup_and_X(925)
  Rejecting user 'jhh': authentication failed
[2008/05/02 23:21:41, 1] smbd/service.c:close_cnum(583)
  his08 (10.0.0.151) closed connection to service jhh

server side permissions
-rw-r--r-- 1 jhh users 456 Apr 12 14:26 pldirs.txt
and output on client side, after mount command:
-rwxrwSrwx 1 root root 456 2008-04-12 14:26 pldirs.txt

[Hiz (hi779)]

I had same problem as yours. and i just changed file manager to Thunar and no problem.
I believe this is a Nautilus bug. i suggest you better try to use another file manager before you messed up samba setting.

see also "Nautilus bug" there must be real solution.

[paraiko (paraiko)]

I'm experiencing similar problems and I definitely don't think it is only a nautilus problem.

I'm sharing a folder from a windows98 vmware guest and am automounting the folder, using cifs, via fstab on the host.
mounting is fine, without any error messages, but I can only acces directories. trying to manipulate the files on the commanline gives a permission error.

the permissions look as below. (I have no idea what the capital S means)

drwxrwxrwx 0 root root 0 2008-02-07 14:04 .
drwxr-xr-x 3 root root 4096 2008-05-22 06:24 ..
drwxrwxrwx 1 root root 0 2008-05-22 07:41 old
-rwxrwSrwx 1 root root 31624 2008-05-23 00:00 q_108143.dat
-rwxrwSrwx 1 root root 48039 2008-05-24 00:00 q_108144.dat
......

after a "sudo chmod 777 *" permissions are set as below.
drwxrwxrwx 0 root root 0 2008-02-07 14:04 .
drwxr-xr-x 3 root root 4096 2008-05-22 06:24 ..
drwxrwxrwx 0 root root 0 2008-05-22 07:41 old
-rwxrwxrwx 0 root root 31624 2008-05-23 00:00 q_108143.dat
-rwxrwxrwx 0 root root 48039 2008-05-24 00:00 q_108144.dat
........

I can access the files files for a certain period, but at some point the permissions revert back to the first situation.

I think it is actually on the point of the next file being written in the folder on the guest when the permissions change, but I haven't had the time to verify it yet.

[Malte Kleemeier (malte-kleemeier)]

Since I have not seen any new posts on this thread for some months, I would like to confirm the problems mentioned in the earlier bug reports:

1) After the upgrade to Ubuntu 8.04 I cannot access the files on a samba server any longer.
   When I try to mount the samba share by the following command line
   "smbmount //SERVER/share /mnt/localmountpoint -o rw,username=my_username"
   I get a "permission denied" error. I have been using this command for several years. I rechecked
   the permissions of /mnt/localmountpoint and they are ok.

   The server runs an older version of samba (2.x) with "security = user" and plaintext
   authentication. I cannot provide the exact configuration of this server because it is
   not administered by me.

2) All files on the server are still fully accessible when I use "smbclient //SERVER/share".

3) When I tweak the SecurityFlags (as described in the readme file of the cifs kernel module) by
   "echo 0x37 > /proc/fs/cifs/SecurityFlags", I can mount the samba share by "smbmount".
   After that I can see the files on the server, but I have no access to them (cannot
   read/write/create files, although the file permission listed by "ls -al" are ok).

I have setup a minimal samba server on my box and found that the current cifs implementatation
in the kernel has great difficulties when connecting to a samba server which requires plain text
authentication (that is setting "encrypt passwords = no" in "smb.conf"). So far I have not been
successful in mounting any share on this test server as long as it runs with the
"encrypt passwords = no"-setting (I always got permission denied errors, tweaking the SecurityFlags
had no effect). Everything worked fine when I turned on password encryption.

When looking at the kernel source of the cifs module I could not find any code that would send
passwords in plaintext to the samba server. There seems to be always some encryption taking place.
The same issue is also discussed on
http://www.nabble.com/No-connection-using-plain-text-password-td18611280.html
where Bart Oldeman suggests a patch, which adds code for handling plain text authentication
to the cifs module (http://lists.samba.org/archive/linux-cifs-client/2008-March/002815.html)

Applying this patch and recompiling the cifs module resolved the problems (at least for me).

I would be glad if the patch could be approved by the developers of cifs kernel module. If
possible a corrected version of the kernel should distributed by Ubuntu soon. Not being able
to mount samba shares seems to be an annoying problem for quite many users of Ubuntu 8.04.

[Steve Langasek (vorlon)]

Malte,

Please file a separate bug report for your issue, which is unrelated to the other issues discussed in this bug report.

Plaintext authentication with CIFS is, I believe, a marginal use case anymore; I won't rule out the possibility of including a fix for this in an update to Ubuntu 8.04, but for reasons of security I would encourage you to look into moving away from plaintext passwords for your use.

[Oleg (petrovo)]

It appears that this problem affects me as well.
I have Intrepid Ibex 2.6.27-7-generic kernel. Since upgrade to Intrepid, I cannot access samba folders.
My samba server is 2.0 (shipped with OpenWrt). I am mounting with simple fstab line:
//asus-router/torrents /mnt/torrents smbfs user,username=user,password=****** 0 0
Like the initial reporter, I can mount and browse share fine, but cannot read/write files (all other rights are OK). Same share works fine with Windows and Mac OS X.
When I try to read something from share, samba server has this in log:

[2008/11/16 20:46:42, 0] smbd/nttrans.c:map_share_mode(443)
  map_share_mode: Incorrect value 80000000 for desired_access to file \Starikam.tut.ne.mesto.2007.DivX.DVDRip_BestVideo.avi

More information on possible issue here: https://dev.openwrt.org/ticket/2865
Looks like CIFS client bug.

[bigal50 (bigal50)]

This appears to be a duplicate of at bug at https://dev.openwrt.org/ticket/2865

Try mounting in fstab using this
For a non-password protected share with read/write permission use
//netbiosname/sharename /media/sharename cifs guest,rw,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

For a password protected share with read/write permission.
//netbiosname/sharename /media/sharename cifs user,username=user,password=******,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

New > Incomplete

[Steve Langasek (vorlon)]

If the servers where people are seeing this problem are all openwrt running Samba 2.0, then it appears this is a known incompatibility dating back to 2004. I could open a bug report upstream asking for Linux CIFS compatibility with Samba 2.0, but if it hasn't been fixed so far, it's unlikely that anyone will fix it now.

Why is OpenWRT shipping with a version of Samba that was superseded 8 years ago?