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

Groups > linux.debian.user > #262184

Re: Update on problem mounting NFS share

Show all headers | View raw

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

Back to linux.debian.user | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web