Connectshares – Does it still work?

[Member olsztyn]

Unless my memory fails me I think I remember Connectshares used to work when I tested around October-November, when following tricky config gui, followed by execution of Connectshare utility.
Now, trying to do the same it does not seem to connect with what it seems to me the same setup, no matter how much attention I dedicate to correct configuration and trying various options… So I am not able to pinpoint where the issue is…
Can anyone please confirm if Connectshares still works as designed, so I can pursue further problem determination…
If it matters my antiX config is:
Kernel 4.19, Fluxbox, trying to connect to standard CIFS/SMB shares on NAS by IP address, specifying valid username/password authentication and a valid share name…

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

[Forum Admin anticapitalista]

Helpful

Up

0

::

Are you running live? If so do not use disable=lx boot cheat.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Forum Admin SamK]

Helpful

Up

0

::

olsztyn wrote:

Can anyone please confirm if Connectshares still works as designed…

Yes it does.

Confirmation obtained as follows:
* antiX-19.1 as shipped booted live (disable=lx left unchanged)
* No persistence
* No updates applied
* No additional software installed
* Wifi network activated via connman
* Connectshares configured and saved (~/.config/connectshares/connectshares.conf)
** Remote server specified by IP address
** Shares on remote server CIFS/SMB both hidden and normally published
** Automatically authenticated by including username & password in connectshares.conf
* Applications–>Internet–>Connectshares All shares mounted as expected

The above points towards possible culprits:
* The shares being blocked by the firewall on the system on which Connectshares is running
* The configuration of Connectshares is invalid
* A problem at the remote server

Is the firewall interfering?
Post the output of the command
sudo ufw status

Can the Connectshares system see the shares available on the remote server system? This can usually be determined by the output of:
Applications–>Internet–>Connectshares Configuration–>Find remote shares offered by a remote system
Post the output of the following command which provides the above output in a terminal.
findshares

Is the Connectshares configuration correct
Post the output of your Connectshares configuration
cat ~/.config/connectshares/connectshares.conf

Troubleshooting the remote server shares setup is not something Connectshares can help with. You must conduct it yourself.

[Forum Admin anticapitalista]

Helpful

Up

0

::

Thanks SamK.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member olsztyn]

Helpful

Up

0

::

Anti, samK – thanks for confirmation.

anticapitalista wrote:

Are you running live? If so do not use disable=lx boot cheat.

I am running Live. Boot default parameters are ‘quiet splasht disable=F’.

SamK wrote:

s the firewall interfering?
Post the output of the command
sudo ufw status

I was testing first with default firewall on, then disabled: sudo ufw status:
Status: inactive
”
$ findshares
Local Host Name = antix1
Local IP Address = 192.168.0.108 on wlan1

Scanning from 192.168.0.108 on wlan1
Samba/Windows Shares
——————————————————————————–
WORKGROUP
IX2-200B 192.168.0.6 Iomega ix2-200
Backups
Files
Video
Audio
Pics
IPC$ IPC Service (Iomega ix2-200)
”
Also:
Both with CREDAUTO=y and CREDAUTO= (asked me to enter username and password, afterwards)
Neither made a difference. This was with ‘SHARESUSER=Files,’.
‘Files’ is the Share Name on CIFS/SMB NAS server 192.168.0.6, correctly reported by Findshares.
I was suspecting ‘SHARESUSER=Files,’ specification but upon removing ‘Files,’ and leaving just ‘SHARESUSER=’ as I saw in multiple videos by DelphinOracle, I am getting message ‘Config incomplete’, so it seems required now, unlike in those videos…
In effect: Regardless of trying various options I am getting ‘Did not mount Files on 192.168.0.6’…
I will continue to try to figure this out but at this point I may have run out of options and the fact that ‘SHARESUSER=’ is reported as incomplete now, unlike in videos, seems to me there is some difference now vs. antiX 15 (appears to me the latest antiX version in those videos).

• This reply was modified 3 years, 1 month ago by olsztyn.
• 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

[Member olsztyn]

Helpful

Up

0

::

Additional testing observations:
– It appears to me that Findshares reports correctly (as reported in the above post) but erratically. Mostly if Connectshares connect attempt has been already made at some point relatively shortly before. Otherwise sometimes comes back with ‘Not found’. Looks like some timing issue…
– With ‘CREDAUTO=’ it comes back prompting for Username and Password. It seems some authentication handshake with server takes place?
As said before I tried all kinds of config combinations in attempt to make it work and followed exactly videos to make sure I am not missing some tricky options, which are not uncommon and will continue to try to figure it out as antiX connectivity to network shares is important to me…

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:

sudo ufw status:
Status: inactive

This eliminates one potential source of your problems. Keep the firewall inactive during all tests.

olsztyn wrote:

$ findshares
Local Host Name = antix1
Local IP Address = 192.168.0.108 on wlan1

Scanning from 192.168.0.108 on wlan1
Samba/Windows Shares
——————————————————————————–
WORKGROUP
IX2-200B 192.168.0.6 Iomega ix2-200
Backups
Files
Video
Audio
Pics
IPC$ IPC Service (Iomega ix2-200)

This eliminates a further potential source of your problem. It indicates your remote shares are known to the system on which Connectshares runs.

olsztyn wrote:

…unlike in videos, seems to me there is some difference now vs. antiX 15 (appears to me the latest antiX version in those videos).

Your assumption is incorrect.

The confirmation of correct working documented in post #33788 above proves Connectshares works as expected on antiX-19.1. Additionally it is in daily use here on antiX-17.4.1. The version of antiX is irrelevant.

olsztyn wrote:

Both with CREDAUTO=y and CREDAUTO= (asked me to enter username and password, afterwards)
Neither made a difference.

If you mean you are prompted for credentials in both cases, the most likely cause is invalid configuration.

Are all the shares on the remote server set up to require username+password?

olsztyn wrote:

With ‘CREDAUTO=’ it comes back prompting for Username and Password.

This is normal and expected behaviour.

olsztyn wrote:

I was suspecting ‘SHARESUSER=Files,’ specification but upon removing ‘Files,’ and leaving just ‘SHARESUSER=’ […] I am getting message ‘Config incomplete’, so it seems required now…

Again you are making an incorrect assumption.

Whether SHARESUSER requires a value depends on how you set up the share on the remote server system. If the remote share requires authenication before granting access, SHARESUSER needs a value. If the remote share has been set up to grant access without requiring authentication, SHARESUSER does not need a value.

olsztyn wrote:

…sometimes comes back with ‘Not found’.

If your remote shares are sometimes seen and sometimes not seen, it might indicate an intermittent connection problem somewhere in your local or remote system, or both. If so, Connectshares is not the cause . Connectshares is just like any other app, it requires a stable, reliable connection.

olsztyn wrote:

Regardless of trying various options I am getting ‘Did not mount Files on 192.168.0.6’…
[…]
I tried all kinds of config combinations in attempt to make it work…

You have not provided the contents of your connectshares.conf as requested in post #33788. Post it if you want any further help.

You have made multiple references to following videos but have you looked at the Connectshares FAQ? It contains guidance and a worked example that might assist you if you decide to troubleshoot by yourself.

[Member olsztyn]

Helpful

Up

0

::

Thank you samK for elaborate response.

SamK wrote:

f you mean you are prompted for credentials in both cases, the most likely cause is invalid configuration.

No. Prompting for Username/Pass was only in case ‘CREDAUTO=’.

SamK wrote:

Are all the shares on the remote server set up to require username+password?

Yes.

SamK wrote:

If your remote shares are sometimes seen and sometimes not seen, it might indicate an intermittent connection problem somewhere in your local or remote system, or both. If so, Connectshares is not the cause . Connectshares is just like any other app, it requires a stable, reliable connection.

My next testing step will be on wired connection, not WiFi.

SamK wrote:

You have not provided the contents of your connectshares.conf as requested in post #33788. Post it if you want any further help.

The reason I have not provided connectshares.conf was that I was constantly changing parameters. If I know what configuration actually works (whatever is recommended) with security I will work on testing from there.

But if it helps, this is:
$ cat ~/.config/connectshares/connectshares.conf

# ————-
# Remote System
# ————-

# The name or IP address of the remote system serving the share(s)
# Examples
# REMOTE=shareserver
# REMOTE=192.168.1.50
REMOTE=192.168.0.6

# ————
# Samba Shares
# ————

# Enable/disable the mounting of Samba shares from the remote system
# When disabled, all other entries in “Samba Shares” section are ignored
# Leave empty to disable mounting, add y to enable mounting
# Examples
# SAMBA=
# SAMBA=y
SAMBA=y

# The name of the domain in which the remote system serves Samba shares(s)
# Examples
# WORKGROUP=company
# WORKGROUP=workgroup
WORKGROUP=WORKGROUP

# Samba shares on the remote system that require a user name and password
# Leave empty to disable mounting shares of this type
# Each listed share must include only the share name terminated by a comma
# Multiple shares must be specified as a comma separated list
# A space immediately before or immediately after a comma is not allowed
# Examples
# SHARESUSER=
# SHARESUSER=homes,
# SHARESUSER=accounts,homes,video clips,
SHARESUSER=Files,
#
# Enable/disable automatically supplying user name and password to remote Samba server
# When disabled a request to manually input credentials is displayed
# Leave empty to disable automatic credentials mode, add y to enable automatic credentials mode
# Examples
# CREDAUTO=
# CREDAUTO=y
CREDAUTO=
#
# The name and password to be supplied when automatic credentials mode is enabled
# When automatic credentials mode is disabled, these entries are ignored and may be left empty
# Examples
# CREDNAME=popeye
# CREDPASS=spinach
CREDNAME=
CREDPASS=

# Samba shares on the remote system that do not require a user name and password
# The shares must allow access to guests
# Leave empty to disable mounting shares of this type
# Each listed share must include only the share name terminated by a comma
# Multiple shares must be specified as a comma separated list
# A space immediately before or immediately after a comma is not allowed
# Examples
# SHARESGUEST=
# SHARESGUEST=anyone,
# SHARESGUEST=anyone,guest only,
SHARESGUEST=

# Options to be applied when mounting Samba shares (both with and without a password)
# Leave empty to disable the use of options
# An option must be terminated by a comma
# Multiple options must be specified as a comma separated list
# A space immediately before or immediately after a comma is not allowed
# Examples
# SAMBAOPT=
# SAMBAOPT=nounix,cache=none,
SAMBAOPT=

# ——————–
# NFS Shares (Exports)
# ——————–

# Enable/disable the mounting of NFS shares from the remote system
# When disabled, all other entries in “NFS Shares (Exports)” section are ignored
# Leave empty to disable mounting, add y to enable mounting
# Examples
# NFS=
# NFS=y
NFS=

# NFS shares on the remote system that do not require a user name and password
# The shares must be accessible by a local system that has a vaild IP address or DNS name
# Each listed share must include the full path of the exported directory on the remote system
# Each listed share must be terminated by a comma
# Multiple shares must be specified as a comma separated list
# A space immediately before or immediately after a comma is not allowed
# Examples
# SHARESIPDNS=/home/nfs/backups,
# SHARESIPDNS=/home/nfs/audio clips,/home/nfs/backups,/home/nfs/images,
SHARESIPDNS=

# Options to be applied when mounting NFS shares
# Leave empty to disable the use of options
# An option must be terminated by a comma
# Multiple options must be specified as a comma separated list
# A space immediately before or immediately after a comma is not allowed
# Examples
# NFSOPT=
# NFSOPT=rw,hard,intr,timeo=30,retry=0,
NFSOPT=
demo@antix1:~
$

Thanks again for your help!
Greatly appreciated.

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

[Member olsztyn]

Helpful

Up

0

::

Update:
Wired connection 1GB did not make a difference for me for Connectshares.
Currently typing wired with disabled WiFi.
Just to add, NAS on which CIFS/SMB shares are is rock solid RAID 1 with no indication of any network instability. Access from Windows is also rock solid, if it is appropriate at all to mention Windows in this forum…
I still plan to connect to shares on this NAS using CIFS-Tools, just to narrow down the issue but I still hope Connectshares will eventually work for me…

Thanks again for your willingness to help with Connectshares…

• 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

::

The connectshares.conf you posted looks OK. In this form will prompt you to enter username+password upon each connection attempt.

So we have now established:
* The firewall is not implicated
* The system running Connectshares can see the shares on the remote server
* The configuration of Connectshares is valid

One final corroborating test.
Run the following commands in your home directory

mkdir testmnt

sudo su

mount -t cifs //192.168.0.6/Files testmnt --verbose -o user=olsztyn 
Note if you use a different username to login to the share use that instead of olsztyn

ls testmnt

Can you see your files on the remote server share?
Are there any error messages when running the mount command?

[Member olsztyn]

Helpful

Up

0

::

Executed as per your commands and strangely getting:

$ mkdir testmnt
demo@antix1:~
$ sudo su
root@antix1:/home/demo# mount -t cifs //192.168.0.6/Files testmnt –verbose -o user=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,user=francis,pass=********
mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
root@antix1:/home/demo# ls testmnt

No idea why because Findshares has no problem seeing:
root@antix1:/home/demo# findshares
Local Host Name = antix1
Local IP Address = 192.168.0.108 on wlan1

Scanning from 192.168.0.108 on wlan1
Samba/Windows Shares
——————————————————————————–
WORKGROUP
IX2-200B 192.168.0.6 Iomega ix2-200
Backups
Files
Video
Audio
Pics
IPC$ IPC Service (Iomega ix2-200)

root@antix1:/home/demo#

Can you see your files on the remote server share? Yes, from other systems, but not from antiX.
Are there any error messages when running the mount command? No error reported.

Thanks again for your help…

• 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

::

We now know Connectshares and mount.cifs work OK, however not when run on your antiX network client system connecting to your NAS box.

Because you are able to access remote shares from your Windows system, but not from a known good antiX system, it is a strong indication the problem emanates from your NAS box.

Is the NAS new?

What operating system and version is run on the NAS box?

What versions of the SMB/CIFS protocol does the NAS box work with?

What version of Windows is on your Windows network client system?

What version of the SMB/CIFS protocol does the Windows system use?

[Member olsztyn]

Helpful

Up

0

::

SamK wrote:

We now know Connectshares and mount.cifs work OK, however not when run on your antiX network client system connecting to your NAS box.

Regarding your questions:
– This NAS is not new. This is Iomega IX-200 StoreCenter. Has been in place on my home network for a few years though..
– Firmware on this NAS is Lenovo/Iomega/EMC Version 3.2.14 – Cloud
– All standard CIFS/SMB protocols typically used by NAS systems.
– Version of Windows is Ver. 10 Professional
– I am not sure (will find out) what exactly version of CIFS/SMB protocols Windows 10 is using for standard network sharing but it is typical network drives mapping of CIFS/SMB shares located on this NAS.

Just to add in addition to your questions:
– In my home network I have three Lenovo/Iomega NAS Boxes: Two IX2-200 (as tested) for SMB and one Lenovo IX2 NAS box on which I run both SMB shares and part of it dedicated to iSCSI protocol, which is mapped only to Windows as a local drive, since as we know in practicality Linux systems are not supporting iSCSI easily…
– All three NAS servers are configured as RAID1.
– In addition on my home network is also Seagate GoFlex NAS, which is standalone disk (No RAID).

Next steps I see in my attempt to identify my problem with Connectshares accessing my SMB NAS:
– I will try to test Connectshares access from antiX to the other NAS servers in addition to the one reported all along.
– Test if these NAS servers can be accessed from other Linux systems using CIFS Tools.

Thanks again for any your help in making network shares work under antiX 19 as well…

• 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

[Member olsztyn]

Helpful

Up

0

::

Connectshares testing update:

Regarding Connectshares connecting to other NAS RAID1 servers:
– So far it looks like Connectshares consistently refuses to connect to SMB shares on both IX-200 Iomega NAS boxes. Access to these boxes on Windows 10 and from all Android TV boxes works fine using either WiFi or Wired connection.
– I was able to connect with Connectshares to IX2 Lenovo NAS SMB shares (also RAID1, if it matters). So possibly there is a difference in version of SMB protocol or something… However Disconnectshares from the antiX Control Panel comes back with plain ‘Failure unmounting’. trying to unmount from the File Manager results in message: udevil: denied 71: ‘mnt/192.168.0.5’ is not an allowed media directory.
– Regarding testing SMB access from other Linux systems I was able to find one of my laptops that still has Linux Peppermint, used before I converted every laptop to antiX… Booted that Peppermint and right there on File Manager all SMB shares are visible and accessible on all four NAS SMB servers. Files properly accessible after login to SMB server of course…

I want to make my point of observation that on antiX 19 I am finding in general that both Connectshares, Disconnectshares and Findshares appear shaky, unreliable and moody to say the least. Since antiX is a Linux system that has replaced all others on all my laptops I would like to see such critical functions as networking reliably working as well. Since I am not a developer (not for a long time at least) I am willing to put effort in all testing necessary, if needed.
Thanks to antiX development team for already great distro and I hope this effort will continue and extend to improving networking functions as well…

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:

Thanks again for any your help in making network shares work under antiX 19 as well…

It has been verified that Connectshares and the mount command both work in all current versions of antiX. It has been in daily use for a period of years and is so today. It is your parrticular circumstances that are problematical.

olsztyn wrote:

All standard CIFS/SMB protocols typically used by NAS systems.

This response does not provide sufficient information to be useful. Which versions?

olsztyn wrote:

I am not sure (will find out) what exactly version of CIFS/SMB protocols Windows 10 is using…

This will be helpful to know.

olsztyn wrote:

…NAS servers are configured as RAID1.

RAID is unlikely to be relevant.

olsztyn wrote:

Booted that Peppermint and right there on File Manager all SMB shares are visible and accessible…

What kernel is used?
What version of the SMB/CIFS protocol does the Peppermint system use?

olsztyn wrote:

I am finding in general that both Connectshares, Disconnectshares and Findshares appear shaky, unreliable and moody to say the least

That is wrong. They all work OK. I must again remind you that earlier in this topic that has been verified.

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.

One thing crops up repeatedly in those reports is a mismatch in the SMB/CIFS protocol on the client and server. For this reason it is important to establish what is in use on your NAS boxes and network clients.

One possible way to test for a mismatch would be to force the use of v1.00 of the protocol on both server and client. Otherwise, because the protocol version in use is not yet known, it will require guesswork.

[Author]

Posts