Would-be clients can see the server. Can see the shares. However
trying to ACCESS the shares by 'mount cifs' or any other means
always results in either a blank, or usually some species of
'permission denied'.
On Mon, 17 Feb 2025 23:58:51 -0500, c186282 wrote:
Would-be clients can see the server. Can see the shares. However
trying to ACCESS the shares by 'mount cifs' or any other means
always results in either a blank, or usually some species of
'permission denied'.
Turn on some more of the server-side logging options, to see if that gives some clues.
On Tue, 18 Feb 2025 01:44:13 -0500, c186282 wrote:
On 2/18/25 1:06 AM, Lawrence D'Oliveiro wrote:
Turn on some more of the server-side logging options, to see if that
gives some clues.
Worth a try.
Another tip: get better names for your log files with something like this:
log file = /var/log/samba/log.%I-%R
That puts the client IP address and the protocol version they’re using
into the log file name. I have found this useful for spotting patterns in which clients are having trouble.
There are of course other fields you can include in the name.
On 2/18/25 1:06 AM, Lawrence D'Oliveiro wrote:
Turn on some more of the server-side logging options, to see if that
gives some clues.
Worth a try.
I used to use SAMBA quite a lot - Linux servers
in a mostly-Win office environment. It was easy
to set up, offered fine-grained control options.
Point smb.conf entries at most any folder and
it would share it without issues.
BUT, starting with some Bullseye and esp now
in Bookworm, what Used To Work just DOESN'T
seem to work anymore.
I set up an SMB user, set the password. Set the
target folder permissions kind of, sometimes
VERY, liberally.
Would-be clients can see the server. Can see
the shares. However trying to ACCESS the shares
by 'mount cifs' or any other means always
results in either a blank, or usually some
species of 'permission denied'.
OK, what the hell changed so radically ???
Have perused many online tutorials, no luck.
This is not just one machine ... both PIs
and AMD64s are both reluctant.
CAN do NoFileSecurity shares OK - but SAMBA
offers a lot more nuance. All my boxes are
Linux.
Today's need is to mount an external multi-disk
usb drive. Bookworm does NOT seem to automount
those on reboot. DID find a code snippet that
resets the bus, and the external drives mount
at /media/user/xxxx as expected. I'd LIKE to
point SAMBA at those - ez-peazy. However I
could mount the /dev/sdx somewhere else after
boot by direct command, create symlinks or
whatever.
Oh wow ... this is an actual LINUX question :-)
Today's need is to mount an external multi-disk
usb drive. Bookworm does NOT seem to automount
those on reboot. DID find a code snippet that
resets the bus, and the external drives mount
at /media/user/xxxx as expected. I'd LIKE to
point SAMBA at those - ez-peazy. However I
could mount the /dev/sdx somewhere else after
boot by direct command, create symlinks or
whatever.
Oh wow ... this is an actual LINUX question 🙂
On 2/18/25 1:06 AM, Lawrence D'Oliveiro wrote:
On Mon, 17 Feb 2025 23:58:51 -0500, c186282 wrote:
Would-be clients can see the server. Can see the shares. However
trying to ACCESS the shares by 'mount cifs' or any other means
always results in either a blank, or usually some species of
'permission denied'.
Turn on some more of the server-side logging options, to see if that
gives
some clues.
Worth a try.
However those logs tend to be SO detailed that
the needed Truth gets buried.
But I'll give it a shot.
Anyway, this issue appeared late in Bullseye
and is now endemic in Bookworm. SOMETHING
changed. Required group memberships ???
On 2/18/25 2:43 AM, Lawrence D'Oliveiro wrote:
On Tue, 18 Feb 2025 01:44:13 -0500, c186282 wrote:
On 2/18/25 1:06 AM, Lawrence D'Oliveiro wrote:
Turn on some more of the server-side logging options, to see if that
gives some clues.
Worth a try.
Another tip: get better names for your log files with something like
this:
log file = /var/log/samba/log.%I-%R
That puts the client IP address and the protocol version they’re using
into the log file name. I have found this useful for spotting patterns in
which clients are having trouble.
Noted.
There are of course other fields you can include in the name.
The typical problem with logs is TOO MANY fields.
Can't sort the wheat from the chaff.
SAMBA isn't anything NEW - it SHOULDN'T be this
difficult. High success a few years ago, now crap.
SOMETHING changed but I can't pin it down yet.
PROBABLY some "security enhancement", poorly
documented. It ought to Just Work.
This is the samba version problem.
It moved from 2 to 3, and as of some distribution, default is 3 and not 2. >They are not compatible.
D <[email protected]> wrote:
This is the samba version problem.
It moved from 2 to 3, and as of some distribution, default is 3 and not 2. >> They are not compatible.
Samba version (4.21 at the moment), or SMB Protocol version? Both
beasts are different.
Greetings
Marc
Idiot
D <[email protected]> wrote:
This is the samba version problem.
It moved from 2 to 3, and as of some distribution, default is 3 and not 2. >> They are not compatible.
Samba version (4.21 at the moment), or SMB Protocol version? Both
beasts are different.
Greetings
Marc
Idiot
SAMBA isn't anything NEW - it SHOULDN'T be this difficult.
On Tue, 18 Feb 2025 02:59:35 -0500, c186282 wrote:
SAMBA isn't anything NEW - it SHOULDN'T be this difficult.
It isn’t. I find when I test things with smbclient, they usually work.
It’s invariably the Windows clients that cause problems.
On 2/18/25 8:49 PM, Lawrence D'Oliveiro wrote:
On Tue, 18 Feb 2025 02:59:35 -0500, c186282 wrote:
SAMBA isn't anything NEW - it SHOULDN'T be this difficult.
It isn’t. I find when I test things with smbclient, they usually work.
It’s invariably the Windows clients that cause problems.
In this exact case, it's Linux clients.
Tried and tries, checked smb,conf against recent
examples, checked /etc/groups, checked permissions
and ownership. Just WON'T work.
As said, I used SAMBA in a mixed environment for
many many years. Then, decidedly by bookworm,
SOMETHING nasty changed. This is terrible.
Did NFS shares instead. Don't love NFS, SAMBA
offers much more fine-grained options and
more nuanced security. If this was a work
environment I'd be even more upset - but
this is a 'home' system now that I've retired
and Vlad probably ain't looking.
Anyway, a root @reboot runs a script that mounts
the /dev/sdx USBs. They DO show up where they
are supposed to be. Liberal permissions. SAMBA
just CAN'T share them properly, nothing but
permission errors on the client no matter how I
set things - and I've used Linux since 'X' was
introduced (no fun setting mouse/keyboard/mon
back then) on floppies.
Dunno WHAT the hell they changed, but it's not
documented worth a damn.
On 2/19/25 1:27 AM, c186282 wrote:
On 2/18/25 8:49 PM, Lawrence D'Oliveiro wrote:
On Tue, 18 Feb 2025 02:59:35 -0500, c186282 wrote:
SAMBA isn't anything NEW - it SHOULDN'T be this difficult.
It isn’t. I find when I test things with smbclient, they usually work. >>>
It’s invariably the Windows clients that cause problems.
In this exact case, it's Linux clients.
Tried and tries, checked smb,conf against recent
examples, checked /etc/groups, checked permissions
and ownership. Just WON'T work.
As said, I used SAMBA in a mixed environment for
many many years. Then, decidedly by bookworm,
SOMETHING nasty changed. This is terrible.
Did NFS shares instead. Don't love NFS, SAMBA
offers much more fine-grained options and
more nuanced security. If this was a work
environment I'd be even more upset - but
this is a 'home' system now that I've retired
and Vlad probably ain't looking.
Anyway, a root @reboot runs a script that mounts
the /dev/sdx USBs. They DO show up where they
are supposed to be. Liberal permissions. SAMBA
just CAN'T share them properly, nothing but
permission errors on the client no matter how I
set things - and I've used Linux since 'X' was
introduced (no fun setting mouse/keyboard/mon
back then) on floppies.
Dunno WHAT the hell they changed, but it's not
documented worth a damn.
followup :
DID have to do it all with NFS alas.
Root crontab @reboot, after a safe delay, mounts
the USB drives into local subdirs.
@reboot sleep 100 && /root/scripts/mountUSB.sh &
#!/bin/bash
# mount the external USBs
sleep 10
mount -t ext4 /dev/sdb1 -o defaults /home/nas/share/MyShare1
mount -t ext4 /dev/sdc1 -o defaults /home/nas/share/MyShare2
/etc/exports has the proper NFS share defs. Note
that the syntax can be fiddly.
/home/nas/share/MyShare1 192.168.0.0/24(rw)
/home/nas/share/MyShare2 192.168.0.0/24(rw)
All clients have the proper /etc/fstab mount defs.
192.168.0.123:/home/nas/share/MyShare1 /mnt/shar1 nfs defaults,timeo=900,retrans=5,_netdev 0 0
192.168.0.123:/home/nas/share/MyShare2 /mnt/shar2 nfs defaults,timeo=900,retrans=5,_netdev 0 0
Root crontab runs a backup bash script twice a day.
The USB drives all have a tag file - "USB-Mounted" -
on them. The script makes sure it's there. If so
then it's "rsync -a --delete <whatever>/ <wherever>".
Pretty quick. Appends the datetime and 'ok' to a
log file. If the tag file is NOT found then it
appends the datetime with "fail" to the log.
5 6,18 * * * /root/scripts/dupSDB1.sh
#!/bin/bash
# use rsync to copy sdb1 (samsung ssd) to sdc (wd black)
# when run, it will do rsync and append 'backups.log'
# with either the success datetime OR the datetime
# with 'fail' afterwards.
# our test file - if not there then usb
# is not properly mounted
FILE=/home/nas/share/MyShare1/USB-Mounted
if test -f $FILE ; then
rsync -a --delete /home/nas/share/MyShare1/ /home/nas/share/MyShare2
echo "backup done"
dt=$(date)
dt2=${dt}" ok"
touch /home/nas/backups.log
echo $dt2 >> /home/nas/backups.log
else
dt=$(date)
dt2=${dt}" fail"
touch /home/nas/backups.log
echo $dt2 >> /home/nas/backups.log
fi
Early morning, root crontab reboots the whole box.
0 1 * * * /sbin/shutdown -r +1
It works, it's easy, not even any Python or 'C'.
Quick improvement, test for the "USB-Mounted" on
the proposed mirror drive as well, to be sure.
Client NFS connections SEEM to hold thru a reboot
of the NAS - at least if it's not TOO lengthy.
Auto-backups MIGHT want to run a 'mount -a' though
just to be sure.
Set the usb SSD as the prime backup point since
it's a bit faster. For now the mirror is a WD
Black magnetic. Decided against softRAID.
This NAS runs on the latest MX Linux. You'll
rarely go wrong with MX.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 170:01:38 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,846 |