Connectshares – Does it still work?

[Member olsztyn]

Helpful

Up

0

::

SamK wrote:

When you ran the “mount -t cifs…” command earlier, it returned an error message “mount error(112): Host is down”. If you do a web search on that error you will find very large numbers of users reporting it, both from other Linux distros and Windows systems. Some also mention the shares being sometimes seen and sometimes not seen. They are not using Findshares and Connectshares, so those are not the cause of the intermittent behaviour or inability to connect.

Making invalid claims about of “shaky, unreliable and moody” behaviour is unhelpful, unwanted, and unlikely to elicit assistance.

I can see from your above explanation (trust you as expert in networking) that instability and unreliability of networking is inherent in Linux regardless of distro and I should have not blamed Connectshares for this, as these unreliability issues can be (and likely are) due to underlying software. So I apologize for jumping to conclusion and pointing to Connectshares as the cause of these problems.
Subsequent to your above response I have done some additional testing from which it appears that such unreliability exists also in the other only distro I have left, Peppermint 9. It seems also a hit or miss experience.
It seems to prove your point that unreliability of networking in Linux is not specific to antiX/Connectshares.
So again, my apologies…
Although these revelations are surprising to me it seems you are right and I do not have much choice but to put up with these issues and live with the limited expectations and recognizing that such issues are likely related to mismatch of SMB versions, which you point out and it is hard to support broad range of them.
Thanks again and best regards…

• This reply was modified 3 years, 1 month ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin SamK]

Helpful

Up

0

::

Apology accepted.

olsztyn wrote:

…instability and unreliability of networking is inherent in Linux regardless of distro…

That is simply wrong. Networking is rock solid. It is every bit as reliable as Windows. Because there are reports of problems from both Linux and Windows users, applying your flawed logic means that networking in Windows is also unstable and unreliable. That is not the case.

olsztyn wrote:

It seems to prove your point that unreliability of networking in Linux…

I have not made that point. You are making an incorrect statement.

olsztyn wrote:

…I do not have much choice but to put up with these issues…

Of course you must decide what to accept, however, others have resolved similar issues.

[Member olsztyn]

Helpful

Up

0

::

SamK wrote:

Of course you must decide what to accept, however, others have resolved similar issues. Do you want to continue collaborating to attempt to resolve the problems with your set-up?

Thank you samK for your willingness to continue this challenge…

One thing I want to make clear though:
What matters to me is not resolving this issue (like some other issues) just for my own sake, namely to make my antiX instance be able to SMB connect to that my specific NAS server for which I reported this issue. This would be selfish of me to waste your precious time on my individual case. At this point antiX (Connectshares) is able to connect to my another NAS server, so I can work around this issue.

Instead, what matters to me is to have one capable Linux system (and antiX seems to fit that role in many respects) that I (or others) can use regardless into which machine or network I plug it in, which implies broad support for hardware and network.

The fact other users were able to resolve similar network connect issues (likely with your help) just for their own sake and are happy it works for them is not encouraging if such individual fixes are not translated (ported) to antiX or other Linux distros for general enhancement.

So if you are willing to spend more time on this, please do this as only for the sake of antiX, not my own specific case.
Thanks again and Best Regards…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin SamK]

Helpful

Up

0

::

olsztyn wrote:

At this point antiX (Connectshares) is able to connect to my another NAS server, so I can work around this issue.

The fact that Connectshares successfully connects to one of your NAS boxes but not to a different one of your NAS boxes, is a clear indication that Connectshares is working OK. It also confirms the mount command on which Connectshares depends is also working OK. Additionally, it points clearly to your other NAS box as the seat of your connection problem.

olsztyn wrote:

Thank you samK for your willingness to continue this challenge…

In post #33788 I mentioned that diagnosing matters on your NAS server is something you alone must undertake. I do not have your NAS BOX, or any knowledge about how it is set up, or the configuration of your shares. These constraints mean I am unable to provide suitable guidance.

olsztyn wrote:

…what matters to me is to have one capable Linux system (and hey antiX seems to fit that role in many respects) that I (or others) can use regardless into which machine or network I plug it in.

Asking for an inbuilt fit with all of the many different types of network is infeasible. Not even Microsoft provides that.

olsztyn wrote:

The fact other users were able to resolve similar network connect issues […] just for their own sake and are happy it works for them is not encouraging if such individual fixes are not translated (ported) to antiX or other Linux distros for general enhancement.

What you see as someone resolving a matter “just for their own sake” is often activating a switch or function which has been included in the software to cater for that issue. It has not been provided for the sake of that user alone, it is there for anyone and everyone to use if the need arises. An example of this is the capability to specify the SMB/CIFS version for a case of protocol mismatch mentioned previously in this thread.

SMB/CIFS is a Microsoft product. Keeping in step with changes in protocol made by Microsoft cannot be achieved until after Microsoft have released it. A time delay is inevitable. Unless you chose otherwise, the mount command you are employing in Connectshares comes from a stable software repository which by design only applies security upgrades to the software to keep it safe but stable. Feature upgrades are usually incorporated in the next major release of the operating system.

Additionally some cases (e.g. the protocol mismatch) get a fix incorporated within the Linux kernel. Since kernel v4.13.5 the default is for the client and server to negotiate the highest possible protocol version greater than or equal to 2.1.

In your opening post you mention you are using kernel v4.19. Using that you are able to establish a connection to one of your NAS boxes. In turn that implies both your network client and NAS server have negotiated a use of SMB/CIFS protocol greater than or equal to 2.1.

Because the same network client cannot establish a connection to a different NAS box it may imply that a SMB/CIFS protocol version cannot be negotiated. If that is the case it might be because the protocol in use on your NAS is v1.0 and therefore needs to be specified explicitly when attempting to make a connection. Of course all that is guesswork because you have not provided the relevant information requested previously in this thread. The issue could be attributable to many other things including the set up of your NAS and configuration of your shares.

To test run the following commands in your home directory.

mkdir testmnt

sudo mount -t cifs //192.168.0.6/Files testmnt --verbose -o vers=1.0,domain=workgroup,username=francis 

ls testmnt

[Member olsztyn]

Helpful

Up

0

::

Thanks again samK for this SMB lesson. I learn something new every day…
So I have executed the above command and mapping share did work. Therefore if you do not mind I would appreciate suggestions:
– How do I need to specify SMB 1.0 in Connectshares, rather than executing such cli commands
– Having mapped share through such cli it appears that subsequent disconnecting (unmounting rather) in File manager comes back with Error: udevil: denied 71: ‘/home/demo’ is not an allowed media directory. Rebooting/shutting down antiX hangs and requires hard shutdown (forced power off). Would you suggest how to disconnect so antiX shuts down normally?
– Share mapped through cli above is not available in Disconnectshares to be able to disconnect. How can I make it visible to Disconnectshares?
I suppose if there is a way to specify SMB version in Connect shares this would make it visible in Disconnectshares?

Thanks again…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin SamK]

Helpful

Up

0

::

olsztyn wrote:

…disconnecting (unmounting rather) in File manager comes back with Error […] how to disconnect so antiX shuts down normally?

Do not use a file manager.
Run the following command in a terminal.
sudo umount testmnt

Before dealing with Connectshares some further tests are needed now you are able to make a successful connection.

Run the following commands in your home directory.

mkdir testmnt

sudo mount -t cifs //192.168.0.6/files testmnt --verbose -o vers=1.0,domain=workgroup,username=francis 

ls testmnt

Note that command is all lowercase letters including your “Files” share.

Repeat that test to your NAS box that does not employ SMB/CIFS protocol v1.0 using the following adjusted command.
sudo mount -t cifs //ip-address/share-name testmnt --verbose -o domain=workgroup,username=francis

Again note it is all lowercase letters including the share name.

[Member olsztyn]

Helpful

Up

0

::

Thanks.
Output from the first (SMB 1, for which Connectshares does not work):
$ sudo mount -t cifs //192.168.0.6/files testmnt –verbose -o vers=1.0,domain=workgroup,username=francis
Password for francis@//192.168.0.6/files:
mount.cifs kernel mount options: ip=192.168.0.6,unc=\\192.168.0.6\files,vers=1.0,user=francis,domain=workgroup,pass=********
demo@antix1:~

Output from the second one (NAS for which Connectshares does work):

$ sudo mount -t cifs //192.168.0.5/files testmnt –verbose -o domain=workgroup,username=francis
Password for francis@//192.168.0.5/files:
mount.cifs kernel mount options: ip=192.168.0.5,unc=\\192.168.0.5\files,user=francis,domain=workgroup,pass=********
demo@antix1:~

In either case ls testmnt shows share directory corresponding to particular share. SMB Shares are being connected successfully using these CLI commands for both NAS boxes.

Thanks again.

• This reply was modified 3 years, 1 month ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin SamK]

Helpful

Up

0

::

olsztyn wrote:

In either case ls testmnt shows share directory corresponding to particular share. SMB Shares are being connected successfully using these CLI commands for both NAS boxes.

Those tests confirm you should use lowercase letters for everything in command line tests and when we come to configure Connectshares.

You have just demonstrated that using the word “files” for your share works the same as using “Files”. By staying with lowercase letters it will be case insensitve i.e. it will work with files, Files, and fILEs.

These final 4 tests will verify your clients work with both variations of passing credentials to the different NAS servers.

In each test replace xxxxx with your password to access the share

TESTS 1 & 2
Make a connection to the NAS box that uses SMB/CIFS v1.0

sudo mount -t cifs //192.168.0.6/files testmnt --verbose -o vers=1.0,domain=workgroup,username=francis,password=xxxxx

ls testmnt

sudo umount testmnt

ls testmnt

sudo mount -t cifs //192.168.0.6/files testmnt --verbose -o vers=1.0,domain=workgroup,user=francis,pass=xxxxx

ls testmnt

sudo umount testmnt

TESTS 3 & 4
Make a connection to the NAS box that uses the higher version of SMB/CIFS

sudo mount -t cifs //ip-address/share-name testmnt --verbose -o domain=workgroup,username=francis,password=xxxxx

ls testmnt

sudo umount testmnt

ls testmnt

sudo mount -t cifs //ip-address/share-name testmnt --verbose -o domain=workgroup,user=francis,pass=xxxxx

ls testmnt

sudo umount testmnt

[Member olsztyn]

Helpful

Up

0

::

Test 1 and 2:
demo@antix1:~
$ sudo mount -t cifs //192.168.0.6/files testmnt –verbose -o vers=1.0,domain=workgroup,username=francis,password=olsztyn1
[sudo] password for demo:
mount.cifs kernel mount options: ip=192.168.0.6,unc=\\192.168.0.6\files,vers=1.0,user=francis,domain=workgroup,pass=********
demo@antix1:~
$ ls testmnt
AMX1 A-Nevada DefaultPicture.png HD2SD32Primo2Install2S700HD
demo@antix1:~
$ sudo umount testmnt
demo@antix1:~
$ ls testmnt
demo@antix1:~
$ demo@antix1:~
$ sudo mount -t cifs //192.168.0.6/files testmnt –verbose -o vers=1.0,domain=workgroup,user=francis,pass=olsztyn1
mount.cifs kernel mount options: ip=192.168.0.6,unc=\\192.168.0.6\files,vers=1.0,user=francis,domain=workgroup,pass=********
demo@antix1:~
$ ls testmnt
AMX1 A-Nevada DefaultPicture.png HD2SD32Primo2Install2S700HD
demo@antix1:~
$ sudo umount testmnt
demo@antix1:~

Test 3 and 4:
$ sudo mount -t cifs //192.168.0.5/files testmnt –verbose -o domain=workgroup,username=francis,password=olsztyn1
mount.cifs kernel mount options: ip=192.168.0.5,unc=\\192.168.0.5\files,user=francis,domain=workgroup,pass=********
demo@antix1:~
$ sudo umount testmnt
demo@antix1:~
$ ls testmnt – produced long list of files in this share
demo@antix1:~
$ sudo mount -t cifs //192.168.0.5/files testmnt –verbose -o domain=workgroup,user=francis,pass=olsztyn1
mount.cifs kernel mount options: ip=192.168.0.5,unc=\\192.168.0.5\files,user=francis,domain=workgroup,pass=********
demo@antix1:~
$ ls testmnt – produced long list of files in this share
$ sudo umount testmnt
demo@antix1:~

I tried to copy all relevant output. listing from ls command in the second share (test 3 and 4) was too long to include here but listed correctly.
Also it looks to me password= and pass= both worked.
Thanks and regards…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin SamK]

Helpful

Up

0

::

olsztyn wrote:

…it looks to me password= and pass= both worked.

OK, moving on to configuring Connectshares.
The config in post #33805 looks generally OK to use as a base.

NAS Server that uses SMB/CIFS v1.0
Edit ~/.config/connectshares/connectshares.conf

Ensure the samba options section looks like the following
SAMBAOPT=vers=1.0,

NAS Server that uses SMB/CIFS v2.1 or greater
Copy connectshares.conf to connectshares2.conf

Edit ~/.config/connectshares/connectshares2.conf

Ensure the correct IP Address is used

Ensure the correct shares are listed

Ensure the samba options section is empty i.e.
SAMBAOPT=

Save the file as connectshares2.conf

Connectshares can be started in various ways.

Manually from
* antiX menu
* Creating launchers in the Personal menu section
* Creating a desktop shortcut
* Added to SpaceFM as shown in the video by dolphin_oracle

In every case the command
* “connectshares” will connect using connectshares.conf
* “connectshares connectshares2.conf” will employ connectshares2.conf

Automatically at boot up (shown in the antiX FAQ)
Control Centre–>Session–>User Desktop-Session–>Startup Tab

To start via connectshares.conf, uncomment the line that contains the command
“connectshares &”

To start via connectshares2.conf, append a line
“connectshares connectshares2.conf &”

[Member olsztyn]

Helpful

Up

0

::

Thanks samK for sorting out all these options.
Would you have a suggestion on best approach to resolve the following issues to make it smooth:

From my testing if antiX shutdown or restart is requested when shares are connected then antiX hangs on such shutdown and requires forced power off. This seems to happen regardless if SMB shares have been connected through Connectshares or CLI commands. This seems necessitating disconnecting SMB shares before antiX shutdown manually, or there this can be requested in antiX shutdown process that all SMB shares be disconnected?

Particularly taking this into account:
When Connectshares is used then CC Disconnectshares gui recognizes such connected SMB shares and allows manually disconnecting them. However if SMB shares have been connected via methods other than Connectshares then Disconnectshares does not seem to detect any shares as connected in order to disconnect and subsequent shutdown of antiX hangs, unless you remember shares are connected via CLI commands and disconnect them in the same fashion before antiX shutdown.

Therefore:
How can I make CC Disconnectshares recognize all SMB shares connected, not just those connected via Connectshares tool?

Any suggestion to resolve these wrinkles would be greatly appreciated…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin SamK]

Helpful

Up

0

::

olsztyn wrote:

How can I make CC Disconnectshares recognize all SMB shares connected, not just those connected via Connectshares tool?

Because of the many different ways of connecting to shares it is not feasible to have a single way to deal with gracefully breaking all connections. For that reason each method of connecting usually provides its own method of disconnecting.

olsztyn wrote:

…antiX shutdown or restart is requested when shares are connected then antiX hangs on such shutdown…

If it the same matter it was fixed in 2014. What version of antiX are you using?

[Member olsztyn]

Helpful

Up

0

::

SamK wrote:

If it the same matter it was fixed in 2014. What version of antiX are you using?

I am using antiX 19, fully updated so in effect equivalent to antiX 19.2 – Hannie Schaft. Kernel is (if it matters) 5.5.
Just to be clear, antiX hangs on shutdown and requires forced power off regardless whether Connectshares was used to connect SMB shares or another way…
Thanks again.

• This reply was modified 3 years, 1 month ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin SamK]

Helpful

Up

0

::

olsztyn wrote:

…antiX hangs on shutdown and requires forced power off regardless whether Connectshares was used to connect SMB shares or another way…

In post #33806 you mentioned using a cable connection with your system. Try the following diagnostic test.

* Boot your system with wireless disabled and network cable connected.
Note it is important that wireless is not employed.

* Make sure your cabled network is operating correctly.

* Connect to your NAS box using only Connectshares, do not use any other method of connecting.

* Browse your shares.

* Do not manually unmount your shares.

* Shut down your system in the usual way while your shares are still connected.

Does the shutdown delay still occur?

[Member olsztyn]

Helpful

Up

0

::

Test done.
– Cable network works fine. 1GB wired connected directly to router. WiFi off.
– Connected to NAS SMB share using Connectshares. Browsed Share files – available.
– Executed antiX Shutdown through CC, without disconnecting SMB share.
– antiX started shutdown and froze solid.
– Forced power off and restarted.

This seems to happen regardless connection is WiFi or wired.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Author]

Posts