Bug 25521 - The increasing brokenness of mounting SMB systems in Mageia
Summary: The increasing brokenness of mounting SMB systems in Mageia
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-03 20:05 CEST by Rod Goslin
Modified: 2022-08-12 23:49 CEST (History)
1 user (show)

See Also:
Source RPM: draxtools
CVE:
Status comment:


Attachments

Description Rod Goslin 2019-10-03 20:05:40 CEST
Description of problem:
This report is to a large extent a repeat of report 22011, from which nothing seems to have transpred, and from which the situation has worsened.
The difficulty lies in the ability to mount SMB shares in Draxtools, as a component of the Control Centre. Historically, this has always been a bit flaky. Particularly in the 'search for servers' which notably fails far to often to find servers which are there.
Generally one of the requirements for access to a remote SMB share, is the access username and password on the remote unit. This was once covered, but at some point the option of entering a password was removed. At the time, I believe of Mga5,a change was made that I do applaud. It had been noticed that in fstab, the username and password were in clear, and a system I shall call 'Credentials' was added. In this the password was held in an entry in /etc/samba, which was only readable by root. You did not have to use this. In which case on bootup the user would be asked for the password, which rather defeated the purpose of hiding it Oddly, too, in Mga5 the new Credentials system only applied to 32 bit machines while 64 bit machines ran only the old system. In Mga7, we seem to have reverted to the old, pre-Credentials system. After a great number of attempts, recently, on a new build the search servers function did, in fact turn up a new server, the consequent fstab entry was of the old pre-Credentials style.
A further point, which has never been addressed, is that the 'server search function, when it works, returns a server name. Which it duly enters into the fstab entry. This subsequently does not work, since the mount operation requires an IP address. The machine cannot resolve this, until an appropriate entry in /etc/hosts is made.
When I upgraded to Mga6 on some of my machines, I gave up on the 'official' process and simply typed out the whole process from scratch. A further point, is that as laid out, the fstab entry will create a viable mount to a remote server, bu the subsequent file structure  will be entirely owned by root, which meant that the user can only write to the share as root.I used various subterfuges which drew a certain amount of ire on the Mageia Forum, to run Konqueror, my File Manager of choice, as root. At Mga5, I did a lot of research into this, and consequently found, and not in any Mageia chronicles, that if I added 'uid= (user id) and gid=(group id), to the fstab command line, the mount was created with normal ownership and rw rights as any other entry. Later, I realised that since this was a boot function, it would assign the same rights when logged in as someone else. Not that that matters to me since all my machines are single owner use


Version-Release number of selected component (if applicable):
All versions to current


How reproducible:
At all times


Steps to Reproduce:
1.try to add a ahared directory within Mageia Control Centre
2.
3.
Comment 1 Rod Goslin 2019-10-04 14:14:21 CEST
Some more thoughts on the uid gid aspect of smb shares. The solution I reached some time back of adding a uid and gid entry to the fstab file, as mentioned above is not a 'suits all' solution. It has occurred to me that if I create a new user, lets call him/her 'share'. Share will have the unusual attributes of having read/write rights for owner, group AND world. If the boot process is carried out in the normal way, the remote server(s) will appear as owned by 'share', but will be writeable by anyone logged in. It matters not that the file structure is owned by someone else, anything you copy off the remote will, of course be owned by the copier. The default fstab raised by Draxtools (If you can make it work) mounts the remote file structure as owned by root, and is not writebale to by user, as I've stated above. I can't see any problem with this, but I'm entirely open to being corrected.
Comment 2 Rod Goslin 2019-10-05 02:50:56 CEST
A further comment on this matter comes to mind. The first action in the Draxtools Access SMB function is to search for servers. This only works sporadically, and sometimes not at all. But when it does, it reports remote servers by name and not by IP address, Neither the mount function, nor the /etc/fstab entry will work, since the operating system requires an address,in the absence of an entry in the /etc/hosts file  I've recently added another Drobo box to my LAN, which both Windows,and Android could immediately see and work with when the new unit was connected and powered up. In the Android case all that was required was to type in the IPaddress, username and password. and it was done.
David Walser 2019-10-21 23:19:23 CEST

Product: Infrastructure => Mageia
CC: sysadmin-bugs => (none)
Assignee: sysadmin-bugs => bugsquad
Component: BuildSystem => RPM Packages
Version: unspecified => Cauldron

David Walser 2019-10-21 23:19:51 CEST

Assignee: bugsquad => mageiatools

Comment 3 Aurelien Oudelet 2020-08-06 21:27:59 CEST
Hi, sorry for taking this so long.

Do you run a firewall on your Mageia setup?

CC: (none) => ouaurelien

Comment 4 Rod Goslin 2020-08-06 21:57:47 CEST
Yes. The usual one from the MCC
Morgan Leijström 2022-08-12 23:49:25 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=22011


Note You need to log in before you can comment on or make changes to this bug.