Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #262132 > unrolled thread

Update on problem mounting NFS share

Back to article view | Back to linux.debian.user

Contents

  Update on problem mounting NFS share Steve Matzura <sm@noisynotes.com> - 2023-10-03 21:10 +0200
    Re: Update on problem mounting NFS share piorunz <piorunz@gmx.com> - 2023-10-03 23:30 +0200
    Re: Update on problem mounting NFS share David Christensen <dpchrist@holgerdanske.com> - 2023-10-04 00:10 +0200
      Re: Update on problem mounting NFS share David Christensen <dpchrist@holgerdanske.com> - 2023-10-04 20:40 +0200
        Re: Update on problem mounting NFS share David Christensen <dpchrist@holgerdanske.com> - 2023-10-05 21:40 +0200

#262132 — Update on problem mounting NFS share

[Multipart message — attachments visible in raw view] — view raw

I gave up on the NFS business and went back to good old buggy but 
reliable SAMBA (LOL), which is what I was using when I was on Debian 8, 
and which worked fine. Except for one thing, everything's great.


In /etc/fstab, I have:


//192.168.1.156/BigVol1 /mnt/bigvol1 civs 
vers=2.0,credentials=/root/smbcreds,ro


That should work, right? Well, it does, but only sometimes. If I boot 
the system, the remote share isn't there. If I unmount everything with 
'umount -a', wait a few seconds, then remount everything with 'mount 
-a', I sometimes have to do it twice. Sometimes, the first time I get a 
message from mount about error -95, but if I wait the space of a couple 
heartbeats and try 'mount -a' again, the share mounts. If I look through 
/var/kern.log for errors, I don't find anything that stands out as 
erroneous, but would be glad to supply extracts here that might help me 
to trace this down and fix it.


TIA

[toc] | [next] | [standalone]

#262135

On 03/10/2023 20:03, Steve Matzura wrote:
> I gave up on the NFS business

Why?

> and went back to good old buggy but reliable SAMBA (LOL)

:o

Sorry but I think you created bigger problem that you already had. NFS
works great, I've been using it for years and it never failed me. I
cannot image what was not working for you. Anyway, good luck.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#262137

On 10/3/23 12:03, Steve Matzura wrote:
> I gave up on the NFS business and went back to good old buggy but 
> reliable SAMBA (LOL), which is what I was using when I was on Debian 8, 
> and which worked fine. Except for one thing, everything's great.
> 
> 
> In /etc/fstab, I have:
> 
> 
> //192.168.1.156/BigVol1 /mnt/bigvol1 civs 
> vers=2.0,credentials=/root/smbcreds,ro
> 
> 
> That should work, right? Well, it does, but only sometimes. If I boot 
> the system, the remote share isn't there. If I unmount everything with 
> 'umount -a', wait a few seconds, then remount everything with 'mount 
> -a', I sometimes have to do it twice. Sometimes, the first time I get a 
> message from mount about error -95, but if I wait the space of a couple 
> heartbeats and try 'mount -a' again, the share mounts. If I look through 
> /var/kern.log for errors, I don't find anything that stands out as 
> erroneous, but would be glad to supply extracts here that might help me 
> to trace this down and fix it.


Using Samba to share files over the network requires various steps and 
settings on both the server and on the clients.  I put a lot of effort 
into Samba back in the day, and only went far enough to get basic file 
sharing working.  Since then, I have copied-and-pasted.  But Microsoft 
has not stood still, nor has Samba.


I have attempted to document the current state of Samba on my SOHO, 
below.  But beware -- my Samba setup is insecure and has issues.


My username is "dpchrist" on all computers and on Samba.


My primary group is "dpchrist" on all Unix computers.


My UID and GID are both "12345" (redaction) on all Unix computers.


The server is FreeBSD (I previously used Debian, but switched to get 
native ZFS):

2023-10-03 12:20:58 toor@f3 ~
# freebsd-version -kru
12.4-RELEASE-p5
12.4-RELEASE-p5
12.4-RELEASE-p5


The latest version of Samba seemed to want Kerberos, so I chose an older 
version that does not:

2023-10-03 12:25:25 toor@samba ~
# pkg version | grep samba
samba413-4.13.17_5                 =


I configured Samba to share files:

2023-10-03 14:49:00 toor@samba ~
# cat /usr/local/etc/smb4.conf
[global]
	local master = Yes
	netbios name = SAMBA
	ntlm auth = ntlmv1-permitted
	passdb backend = tdbsam
	preferred master = Yes
	security = USER
	server string = Samba Server Version %v
	wins support = Yes
	workgroup = WORKGROUP
<redacted>
[dpchrist]
	force user = dpchrist
	path = /var/local/samba/dpchrist
	read only = No
	valid users = dpchrist
<redacted>


I validate the configuration file with testparm(1):

2023-10-03 13:37:31 toor@samba ~
# testparm
Load smb config files from /usr/local/etc/smb4.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
	ntlm auth = ntlmv1-permitted
	preferred master = Yes
	security = USER
	server string = Samba Server Version %v
	wins support = Yes
	idmap config * : backend = tdb
<redacted>
[dpchrist]
	force user = dpchrist
	path = /var/local/samba/dpchrist
	read only = No
	valid users = dpchrist
<redacted>


I created a Samba user account:

root@samba:~ # pdbedit -a dpchrist
new password:
retype new password:


Whenever I change anything related to Samba on the server, I reboot and 
verify before I attempt to connect from a client.


On Debian clients:

2023-10-03 12:44:39 root@taz ~
# cat /etc/debian_version ; uname -a
11.7
Linux taz 5.10.0-25-amd64 #1 SMP Debian 5.10.191-1 (2023-08-16) x86_64 
GNU/Linux


I installed the Samba client file sharing package:

2023-10-03 12:55:06 root@taz ~
# dpkg-query -W cifs-utils
cifs-utils	2:6.11-3.1+deb11u1


I created a mount point for the incoming share:

2023-10-03 12:58:13 root@taz ~
# ls -ld /samba/dpchrist
drwxr-xr-x 2 dpchrist dpchrist 0 Jun 18 14:31 /samba/dpchrist


I created an /etc/fstab entry for the incoming share:

2023-10-03 12:59:41 root@taz ~
# grep samba\/dpchrist /etc/fstab
//samba/dpchrist					/samba/dpchrist		cifs	 
noauto,vers=3.0,user,username=dpchrist		0	0


I mount the incoming share manually:

2023-10-03 13:01:07 dpchrist@taz ~
$ mount /samba/dpchrist
Password for dpchrist@//samba/dpchrist:

2023-10-03 13:01:46 dpchrist@taz ~
$ mount | grep samba\/dpchrist
//samba/dpchrist on /samba/dpchrist type cifs 
(rw,nosuid,nodev,relatime,vers=3.0,cache=strict,username=dpchrist,uid=12345,forceuid,gid=12345,forcegid,addr=192.168.5.24,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,user=dpchrist)


Note that there is a maddening issue with Samba on Unix clients -- the 
Unix execute bits vs. MS-DOS System, Hidden, and Archive bits:

https://unix.stackexchange.com/questions/103415/why-are-files-in-a-smbfs-mounted-share-created-with-executable-bit-set


On Windows 7 clients, I needed to change a Registry entry to allow 
Windows to use deprecated file sharing security:

Start
-> Command Prompt
-> Run as administrator
-> C:\Windows\system32>secpol.msc

Security Settings
-> Local Policies
-> Security Options
-> Network Security: LAN Manager authentication level
-> Send LM & NTLM - use NTLMv2 session security if negotiated


Note that there is an issue with Samba on Windows 7 clients -- Windows 
Explorer -> Network does not find or list the Samba server.  The 
work-around is to enter a UNC path in the Windows Explorer address box 
(either IP address, or host name if I have configured such on the DHCP 
server):

\\192.168.1.23\dpchrist


On Windows 7/ Cygwin clients, I map a drive letter to the connected 
Samba share.  The execute bits issue is present.


On macOS clients, there are issues with finding and listing the Samba 
server and with execute bits.  The work-around for the former is to 
enter a URL into Finder -> Go -> Connect to Server:

smb://192.168.1.23/dpchrist


See also:

https://www.samba.org/

https://lists.samba.org/


Comments and suggestions for any of the above are welcome.


HTH,

David

[toc] | [prev] | [next] | [standalone]

#262165

On 10/4/23 05:03, Steve Matzura wrote:
> On 10/3/2023 6:06 PM, David Christensen wrote:
>> On 10/3/23 12:03, Steve Matzura wrote:
>>> I gave up on the NFS business and went back to good old buggy
>>> but reliable SAMBA (LOL), ...


>> I have attempted to document the current state of Samba on my
>> SOHO, below.  ...

> Wow but that's an awful lot of work for something that seems to be a
> timing problem. But at least I learned something.

What is posted is the results of a lot of work -- trying countless
combinations of settings on the server and on the client via edit,
rebooting, and test cycles; until I found a combination that seems to work.


Your OP of /etc/fstab:

//192.168.1.156/BigVol1 /mnt/bigvol1 civs
vers=2.0,credentials=/root/smbcreds,ro

* The third field is "civs".  Should that be "cifs"?

* The fourth field contains "ro".  Is that read-only?  If so, how do you
create, update, and delete files and directories on /mnt/bigvol1?


David

[toc] | [prev] | [next] | [standalone]

#262184

On 10/5/23 05:01, Steve Matzura wrote:
> On 10/4/2023 2:32 PM, David Christensen wrote:
>> On 10/4/23 05:03, Steve Matzura wrote:
>>> On 10/3/2023 6:06 PM, David Christensen wrote:
>>>> On 10/3/23 12:03, Steve Matzura wrote:
>>>>> I gave up on the NFS business and went back to good old buggy
>>>>> but reliable SAMBA (LOL), ...
>>>> 
>>>> I have attempted to document the current state of Samba on my 
>>>> SOHO, below.  ...
>>> 
>>> Wow but that's an awful lot of work for something that seems to 
>>> be a timing problem. But at least I learned something.
>> 
>> What is posted is the results of a lot of work -- trying countless
>> combinations of settings on the server and on the client via edit,
>> rebooting, and test cycles; until I found a combination that
>> seems to work.
>> 
>> Your OP of /etc/fstab:
>> 
>> //192.168.1.156/BigVol1 /mnt/bigvol1 civs vers=2.0,credentials=/root/smbcreds,ro
>> 
>> * The third field is "civs".  Should that be "cifs"?
>> 
>> * The fourth field contains "ro".  Is that read-only?  If so, how 
>> do you create, update, and delete files and directories on 
>> /mnt/bigvol1?
>
> The 'civs' is indeed cifs. That was hand-transcribed, not 
> copied/pasted. My bad.


Please "reply to List".


Please using inline posting style.


Copy-and-paste can require more effort, but precludes transcription 
errors.  On the Internet, errors are not merely embarrassing: they can 
cause confusion forever.


> I mount the drive read-only because it 
> contains my entire audio and video library, so anyone to whom I give 
> access on my network must not ever have the slightest possibility of 
> being able to modify it.


So, you create, update, and delete content via some means other than 
/mnt/bigvol1 (?).


TIMTOWTDI for multiple-user Samba shares.


ACL's would seem to be the canonical solution, but they introduce 
complexities -- Unskilled users?  Usage consistency from Windows 
Explorer, Command Prompt, Finder, Terminal, Thunar, Terminal Emulator, 
etc.?  Unix or Windows ACL's?  Backup and restore?  Integrity auditing 
and validation?


I chose to implement a "groupshare" share with read-write access for all 
Samba users and a social contract for usage (I also implemented a 
"groupshare" group/user and configured Samba to force ownership of content):

2023-10-05 11:51:52 toor@samba ~
# cat /usr/local/etc/smb4.conf
[global]
	local master = Yes
	netbios name = SAMBA
	ntlm auth = ntlmv1-permitted
	passdb backend = tdbsam
	preferred master = Yes
	security = USER
	server string = Samba Server Version %v
	wins support = Yes
	workgroup = WORKGROUP
<redacted>
[dpchrist]
	force user = dpchrist
	path = /var/local/samba/dpchrist
	read only = No
	valid users = dpchrist
<redacted>
[groupshare]
	create mask = 0777
	directory mask = 0777
	force create mode = 0666
	force directory mode = 0777
	force unknown acl user = Yes
	force user = groupshare
	path = /var/local/samba/groupshare
	read only = No

2023-10-05 11:54:48 toor@samba ~
# grep groupshare /etc/group /etc/passwd
/etc/group:groupshare:*:999:
/etc/passwd:groupshare:*:999:999:Groupshare:/home/groupshare:/usr/sbin/nologin

2023-10-05 12:00:55 toor@samba ~
# find /var/local/samba/ -type d -depth 1 | egrep 'dpchrist|groupshare' 
| xargs ls -ld
drwxrwxr-x  98 dpchrist    dpchrist    102 Oct  3 14:13 
/var/local/samba/dpchrist
drwxrwxr-x   8 groupshare  groupshare   13 Oct  5 11:32 
/var/local/samba/groupshare


Debian client:

2023-10-05 11:45:42 root@taz ~
# egrep 'dpchrist|groupshare' /etc/fstab | perl -pe 's/\s+/ /g'
//samba/dpchrist /samba/dpchrist cifs 
noauto,vers=3.0,user,username=dpchrist 0 0
//samba/groupshare /samba/groupshare cifs noauto,vers=3.0,user 0 0


> By the way, another friend to whom I showed my problem came up with a
> similar solution surrounding my original hypothesis that there is a
> delay between the time fstab is processed and networking is 
> available. He said he tested it probably a dozen times and it worked 
> every time. His suggested fstab line is this:
> 
> //192.168.1.156/BigVol1 /mnt/bigvol1 cifs vers=3.1.1,credentials=<credentials-file>,rw,GID=1000,uid=1000,noauto,x-systemd.automount


It's a matter of edit-reboot-test cycles with a consistent and complete 
test protocol.


"GID=1000,uid=1000" -- looks similar to my "groupshare" idea, but from 
the client side.  That should produce the same results for most use-cases.


"credentials=<credentials-file>,noauto,x-systemd.automount" -- I assume 
this is a work-around for unreliable mounting at system start-up (?).  I 
tried similar tricks, and ended up going back to KISS -- typing mount(8) 
commands by hand once per boot.


David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web