#911

I’ll give it a shot too. I’m reckless :smiley:

#912

Had to change tar xzvf fates200106.tgz to tar xvf fates200106.tgz as it doesn’t think it’s gzipped.
System is up after that but samba doesn’t work.
Notable info from the install:

cp: cannot stat 'config/smb.conf': No such file or directory
...
cp: cannot stat '/home/we/fates/install/norns/files/samba': No such file or directory
cp: cannot stat '/home/we/maiden/dist/catalogs/*.json': No such file or directory
#913

oops. forgot to push the samba file to fates repo. Should be better now. Checking on the smb.conf error now

The maiden errors are normal.

I’ll try to clean those up and repost it cleaned up and reposted

also - should be

tar -xvf fates200106.tgz

uploading a new archive file now…

#915

Still getting

scp: cannot stat 'config/smb.conf': No such file or directory

after it pulls

Fast-forward
install/norns/Norns_disk_image_install.md |  9 +++------
install/norns/files/191230/update.sh      | 67 -------------------------------------------------------------------
install/norns/files/samba                 | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 73 deletions(-)
#916

try this just to get your install working correctly
sudo cp ~/update/200106/config/smb.conf /etc/samba/

#917

Should we rerun the update after that?
I get this after updating again.

Reading state information... Done samba is already the newest version (2:4.9.5+dfsg-5+deb10u1+rpi1). samba-common-bin is already the newest version (2:4.9.5+dfsg-5+deb10u1+rpi1). 0 upgraded, 0 newly installed, 0 to remove and 103 not upgraded. Already up to date. cp: cannot stat 'config/smb.conf': No such file or directory

#918

no - you already have samba installed, so that’s OK. Not sure why the smb.conf file won’t work - the file is there in config.

Can you try sudo cp ~/update/200106/config/smb.conf /etc/samba/?

Also - Just updated the update archive

1 Like
#919

No worries, I wasn’t in a hurry to get it going. Just wanted to help test.

Copying the smb.conf works fine and samba starts.
I had to create /var/log/samba for it to log.

smb authentication is failing. I upped the log level to 3 and now see this

  check_ntlm_password:  Authentication for user [we] -> [we] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1

using the ‘we’ user, obviously.

also check_sam_security: Couldn't find user 'we' in passdb.

1 Like
#920

aw crap - forgot something else. Thanks for finding that.

(echo "sleep"; echo "sleep") | sudo smbpasswd -s -a we
sudo /etc/init.d/samba restart

re-re-re-uploading archive. (also cleaned out some stuff that’s not needed, so it’s smaller)

(too much coffee today!)

3 Likes
#921

Yep, smb working now!

1 Like
#922

20200106_192936
20200106_1929364032×1960 4.87 MB

So far so good, bit out of my depth here, assuming that I want the smb.conf to use the WINS settings?

1 Like
#923

I said no to that, but i think its not relevant because the next step just replaces smb.conf so either way is probably fine? (assuming the smb.conf file copies properly)

2 Likes
#924

Thanks!

All went well, only exceptions that stood out to me were near the end:

“find: cannot delete ‘/home/we/dust/audio/samples/Roland CR-78/.DS_Store’: Permission denied
find: cannot delete ‘/home/we/dust/audio/samples/Roland CR-78/._.DS_Store’: Permission denied”

and another just above that prefaced with “Please ignore the following error”

Can post the wall-o-text if it helps

EDIT: yep, thanks, moved those over via sftp. “group” and “we” don’t have write permissions.

#925

You probably should check your file permissions on dust/audio/samples - i’m guessing that’s your own folder of uploaded stuff so it probably doesn’t matter.

#926

I just ran the update and it was smooooth.

1 Like
#927

Any luck with that right channel?

#928

No luck unfortunately!

#929

I’m kinda at a loss to explain what might be happening there.

Looking back at the screenshot of the signal path - maybe it’d be worthwhile to check continuity between various points in the path - maybe to confirm there’s not some issue with the pcb traces (which I’ve never seen happen, but who knows)

#930

It might be that there is a short on the right headphone trace, or remotely, the DAC just has a blown right headphone output… various reasons (shorting to ground during initial install/test, maybe ESD, maybe just a dud chip)… if @Hiraeth has a spare DAC chip, might be worth a shot too, after validating the signal path isn’t itself accidentally shorted to ground anywhere.

1 Like
#931

I’ve run a continuity test and all is fine with the pcb it would seem.
I might buy a new DAC and give that a shot.