Problem with NASMount

S

soreilly

New Member
Evening,

I've been using the custom firmware for a while (great job on it!) on a Foxsat-HDR and recently installed NASMount (latest version) to get it talking to a SMB share on my NAS (Synology DS918+ running latest version - 7.1).

I try to mount a share on the Foxsat but it fails (and I'm pulling my hair out) with the following in the Foxsat log:

Mon May 01 19:02:41 BST 2023 : ----------------------------------------------------------
Mon May 01 19:02:41 BST 2023 : Found Gadget on : sda1
Mon May 01 19:02:41 BST 2023 : Pinging Host 192.168.2.250
Mon May 01 19:02:43 BST 2023 : 3 packets transmitted, 3 packets received, 0% packet loss
Mon May 01 19:02:43 BST 2023 : Ping of host successfull .... mapping drive
Mon May 01 19:02:43 BST 2023 : Making mount point directory /media/sda1/test
Mon May 01 19:02:43 BST 2023 : Mounting //192.168.2.250/Media onto /media/sda1/test
Mon May 01 19:02:44 BST 2023 : ERROR Mounting //192.168.2.250/Media onto /media/sda1
Mon May 01 19:02:44 BST 2023 : Mount command returns => mount: Mounting //192.168.2.250/Media on /media/sda1/test failed: Not a directory
Mon May 01 19:02:44 BST 2023 : Finished mounting all mount points

The share (Media) is available and I can browse to it from a Windows machine and the user I am trying to mount the share as has access (R/W).

I have also enabled SMB1 and NTLMv1 authentication on the Synology.

If I try the mount from the Foxsat CLI, I get:

Foxsat-HDR/media/sda1# mkdir Synology1
Foxsat-HDR/media/sda1# mount -t cifs -o user=<USER>,password=<PASS> "//192.168.2.250/Media" /media/sda1/Synology1
mount: //192.168.2.250/Media is write-protected, mounting read-only
mount: Mounting //192.168.2.250/Media on /media/sda1/Synology1 failed: Permission denied
Foxsat-HDR/media/sda1#

Not sure why it's reporting that it is write-protected - it isn't.

Any help gratefully welcome.

S.
 
bingbonglong said:
In parallel with posting in this forum, I contacted Synology to see if they could help. They were able to look at the NAS logs and solved it for me. The answer is twofold:

1. Control Panel -> File Settings -> SMB -> Advanced Settings -> Minimum SMB protocol -> SMB1 (as suggested by @Black Hole )
2. Control Panel -> File Settings -> SMB -> Advanced Settings -> Others -> Enable NTLMv1 authentication.

These settings are for a Synology DS218play NAS but might help others identify how to solve a similar problem with their own NAS.

It's all working again now. Thank you for all the help offered.
Click to expand...

About a year ago and immediately following an update of the DSM software on my Synology NAS the Humax HDR could no longer access the SMB share.
Other were affected and I'm grateful to the forum member I've quoted for finding a solution.
NB -> File Settings -> in the above shows on my NAS as -> File Services ->

As you can see the solution related to a Synology DS218play but also worked for my DS218j and quite likely is appropriate for any Synology NAS running DSM 7.1 or later.
No change was needed on the Humax side, which makes me hopeful that it may work for your Foxsat.
 
Given that the command you have run from the CLI is the same as the command that NASMount would be running, it's strange that the error is different:

NASMount reports:
soreilly said:
Mon May 01 19:02:44 BST 2023 : Mount command returns => mount: Mounting //192.168.2.250/Media on /media/sda1/test failed: Not a directory
Click to expand...

CLI is:
soreilly said:
mount: Mounting //192.168.2.250/Media on /media/sda1/Synology1 failed: Permission denied
Click to expand...

Just to rule out some issues that have tripped others up in the past:
  1. Has the samba service been restarted on the NAS since enabling SMBv1 and NTLMv1 (or has the NAS been rebooted)
  2. Does the username and/or password for the user with access to the share contain any special characters? The hash character has caused problems in the past and also the percentage character (there may be others). If this is the case then, just for testing purposes, can you create a new test user with a simple username and password and assign that user permissions to the share. Does that make any difference?
  3. The folder on the NAS is definitely shared as "Media" (with a capital "M" and lower case "edia") right? I note that you have connected from Windows, but Windows doesn't care about case.
 
adrianf36 said:
Given that the command you have run from the CLI is the same as the command that NASMount would be running, it's strange that the error is different:

NASMount reports:


CLI is:


Just to rule out some issues that have tripped others up in the past:
  1. Has the samba service been restarted on the NAS since enabling SMBv1 and NTLMv1 (or has the NAS been rebooted)
  2. Does the username and/or password for the user with access to the share contain any special characters? The hash character has caused problems in the past and also the percentage character (there may be others). If this is the case then, just for testing purposes, can you create a new test user with a simple username and password and assign that user permissions to the share. Does that make any difference?
  3. The folder on the NAS is definitely shared as "Media" (with a capital "M" and lower case "edia") right? I note that you have connected from Windows, but Windows doesn't care about case.
Click to expand...

Evening adrianf36,

1. Yes, NAS has been rebooted (couple of times) since enabling SMB1 and NTLMv1 authentication.
2. The initial user I was testing with had an underscore character in the password. Created a new user with a password which was just alphanumeric characters but no joy. I have updated the password on the test user to something simple "Password1234" but that still fails.
3. The share was created with a capital 'M' (see attached). That's how it appears in the Synology file view and in Windows when browsing the network. I have also connected to the share in Windows using the test user and confirmed they have R/W access.

Latest logs from NASMount and CLI after changing the password.

Tue May 02 20:26:07 BST 2023 : Found Gadget on : sda1
Tue May 02 20:26:08 BST 2023 : Pinging Host 192.168.2.250
Tue May 02 20:26:10 BST 2023 : 3 packets transmitted, 3 packets received, 0% packet loss
Tue May 02 20:26:10 BST 2023 : Ping of host successfull .... mapping drive
Tue May 02 20:26:10 BST 2023 : Making mount point directory /media/sda1/Media
Tue May 02 20:26:10 BST 2023 : Mounting //192.168.2.250/Media onto /media/sda1/Media
Tue May 02 20:26:11 BST 2023 : ERROR Mounting //192.168.2.250/Media onto /media/sda1
Tue May 02 20:26:11 BST 2023 : Mount command returns => mount: Mounting //192.168.2.250/Media on /media/sda1/Media failed: Not a directory
Tue May 02 20:26:11 BST 2023 : Finished mounting all mount points

Foxsat-HDR~# mount -t cifs -o user=Foxsat,password=Password1234 "//192.168.2.250/Media" /media/sda1/Media
mount: Mounting //192.168.2.250/Media on /media/sda1/Media failed: Not a directory
Foxsat-HDR~#

Foxsat-HDR~# ls -las /media/sda1
total 3
1 drwxr-xr-x 6 root root 1024 May 2 20:26 .
0 drwxr-xr-x 3 root root 160 May 2 18:29 ..
1 drwxr-xr-x 2 root root 1024 May 2 20:26 Media

Foxsat-HDR~# ls -las /media/sda1/Media
total 2
1 drwxr-xr-x 2 root root 1024 May 2 20:26 .
1 drwxr-xr-x 6 root root 1024 May 2 20:26 ..
Foxsat-HDR~#


The log file on the Synology shows that the Foxsat user has accessed the share via CIFS using SMB1.

Curious as to why NASMount is is saying "Not a directory".

Edit: Just as a test, I purposefully used a wrong password and it did reject as expected (can only assume I used a wrong password in my earlier test hence the different reponses):

Foxsat-HDR~# mount -t cifs -o user=Foxsat,password=WrongPassword "//192.168.2.250/Media" /media/sda1/Media
mount: //192.168.2.250/Media is write-protected, mounting read-only
mount: Mounting //192.168.2.250/Media on /media/sda1/Media failed: Permission denied
Foxsat-HDR~#



Capture2.JPG

Capture3.JPG




Thanks,

S.
 
Last edited:
Thanks for the additional info. I don't have a Synology NAS to try and reproduce the issue unfortunately. However, Googling synology nas cifs mount "not a directory" seems to throw up some common suggestions that additional parameters may be needed for the mount command. It may be worth trying some of these from the CLI to see if you can get it to mount.

The most common suggestion seems to include specifying the user and group ID in the mount command e.g. https://www.electrical-forensics.com/Linux/mount_Synology_NAS.html

There's a bunch of other things that come up too that may be worth trying.

Sorry I can't be of more help. If you find a solution to mount the share from the CLI I'd be interested in knowing what it was.
 
adrianf36 said:
Thanks for the additional info. I don't have a Synology NAS to try and reproduce the issue unfortunately. However, Googling synology nas cifs mount "not a directory" seems to throw up some common suggestions that additional parameters may be needed for the mount command. It may be worth trying some of these from the CLI to see if you can get it to mount.

The most common suggestion seems to include specifying the user and group ID in the mount command e.g.

There's a bunch of other things that come up too that may be worth trying.

Sorry I can't be of more help. If you find a solution to mount the share from the CLI I'd be interested in knowing what it was.
Click to expand...
Hi adrianf36,

Thanks for your help.

I haven't had much time to look at this recently but I have some time at the end of the month and will dig in to it further then and update accordingly.

Thx.

S.
 
Hi adrianf36,

Quick question, do you happen to have, or know where I could get old versions of the NASMount package for testing? Currently using 2.0.2 (latest).

Thx,

S
 
There are no others in the repository and the current one is nearly 9 years old.
 
soreilly said:
Quick question, do you happen to have, or know where I could get old versions of the NASMount package for testing? Currently using 2.0.2 (latest).
Click to expand...
I doubt that I have any earlier versions I'm afraid. Maybe, somewhere in the depths of my archives, but none that are immediately apparent.

Not entirely sure why you would be asking. At a guess maybe you're wondering if there were any fundamental changes to the mount command issued by NASMount. There were, but only to support things like share names with spaces in them and, I think, some "special" characters in passwords. Nothing that, I believe, would be relevant to your issue.

You can see the rough history of releases in the main NASMount thread on AVForums: https://www.avforums.com/threads/nasmount-plug-in-for-humax-foxsat-hdr-web-interface.1736200/

Incidentally, there are a number of posts that refer to successfully mounting shares on a Synology NAS in the above thread. However, I accept that it was 10 years ago when NASMount was originally released, and that things move on.
 
Morning.

Just a quick update. Had a bit of time to play with this yesterday and as a test, I rolled back the firmware version on the Synology NAS to the previous version (7.1-42661) to test. Rolling back the firmware on the Synology is not straightforward and requires a little editing of system files but can be done.

Once I rolled back, NASMount worked. Nothing changed on the Foxsat-HDR - I'm using the same mount point, directory and user credentials.

Can only presume that Synology have changed something in the latest firmware.

For now, it's working. :)

Thanks to all.

Code: 
Sun May 14 07:58:43 BST 2023 : Virtual USB device mounted OK
Sun May 14 07:59:12 BST 2023 : Mounting required drives .....
Sun May 14 07:59:12 BST 2023 : Found Gadget on : sda1
Sun May 14 07:59:13 BST 2023 : Pinging Host 192.168.2.250
Sun May 14 07:59:15 BST 2023 : 3 packets transmitted, 3 packets received, 0% packet loss
Sun May 14 07:59:15 BST 2023 : Ping of host successfull .... mapping drive
Sun May 14 07:59:15 BST 2023 : Making mount point directory /media/sda1/Synology
Sun May 14 07:59:15 BST 2023 : Mounting //192.168.2.250/Media onto /media/sda1/Synology
Sun May 14 07:59:16 BST 2023 : Successfully Mounted //192.168.2.250/Media onto /media/sda1/Synology
Sun May 14 07:59:16 BST 2023 : Finished mounting all mount points

S.
 
Great to know you got it working. Thanks for posting the information for the "fix". Hopefully it will help others if they experience the same.
 
I was also unable to get the Foxsat to mount an external samba share... until today anyway. The error generated from NASmount (and the Foxsat command line) was the same as soreilly got when using NASmount :

mount: //192.168.0.12 is write-protected, mounting read-only
mount: Mounting //192.168.0.12 on /media/sdb1/media failed: Permission denied
Foxsat-HDR/mnt/hd4/opt#

I believe the reason soreilly got a different error when attempting to mount from the command line is because the local directory on the Foxsat has to exist before you try and mount something onto it. If /media/sda1/test didn't exist, you'd get that error.

This thread touched on 'ntlm' and after setting samba to log at debug level 3 showed that auth was indeed the problem for me.

[2023/05/22 15:25:21.558897, 2] ../libcli/auth/ntlm_check.c:430(ntlm_password_check)
ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user humax
[2023/05/22 15:25:21.559012, 3] ../libcli/auth/ntlm_check.c:449(ntlm_password_check)
ntlm_password_check: Lanman passwords NOT PERMITTED for user humax
[2023/05/22 15:25:21.559137, 3] ../libcli/auth/ntlm_check.c:595(ntlm_password_check)


A Debian 10 machine hosts my samba share without a control panel so for me it was a case of editing the samba conf file manually and adding :
ntlm auth = yes
to the [global] section of
/etc/samba/smb.conf
the Foxsat was able to mount the external share.

Apparently passwords sent using ntlm authentication are easily decrypted, so definately a bad idea to do this if your share is available to the outside world and writable.

This thread has been very helpful. Without it, I'd have got nowhere.

Thanks.
 
I have recently had the same issue connecting to a Synology DS220J and have read through various things including this post in looking for an answer.

I tested the Foxsat against another SMB1 server and it worked fine - a BT hub presenting a USB drive from its USB port (share name = the memory stick's volume name)
I have therefore come to the conclusion that the Synology implementation of Samba is broken for SMB1 (at least in my DSM Version 7.2-64570)

As a workaround, I activated the Samba service on the Foxsat and mounted it from the Synology (share name Video, username: root, password:humax) - this allows file moving/(un)archiving, but not the playing of files on the Synology from the Foxsat.
As I currently understand it, the sidecar files won't be updated when using the Synology File Station file manager to move the files, so when copied back to the Foxsat for playback, the file will need to be moved again within the Foxsat file system to set the sidecars correctly. I don't know what the consequence would be if this final step wasn't done prior to playback.

I would just like to take the opportunity to thank everyone involved in the custom firmware for Foxsat and the HDR-Fox-T2. You make the world of difference to me in my Humax use. Well done, and I'd be pleased to be involved in any way I can to contribute.
 
You must log in or register to reply here.
Back
Top