Forum

Hi all,

I have an externel HDD plugged into the USB-Port, which is mounted and I can find it in my Network.
But I can't write on the HDD.
I already checked / edited the /etc/usbmount/usbmount.conf, but it looks like it doesn't care xbian what config is made in this file!?
Is there already a solution and I'm only blind?

greetings

Cre@tsheR

if you want guest ok writes (so connecting to rpi without be asked of user/pass, setting in usbmount.conf must be

sharesmb=yes
sharerw=yes
sharelt=no

also, the mounted storage needs to be writable for user xbian in that case.

That's what I've done.
But it doesn't work
Even if I disable smb in the usbmount.cfg, the HDD can be found over network.

even after restart ? actually the mounts are being shared with disk being mounted (and removed if disk lost or unmounted).

but if you change the setting, it will become effective for those mount/umount events only on next reboot.
if they still are visible, provide please output of

Hey,
I got the same issue. However, thanks to you @mk01 I know what was going on and how to fix it. There was no problem with the package (it was the newest one).

Here comes the output of net conf list:
XBMC and Backup are labels of my partition, xbmc-backup share is made by xbian I guess.

So here is what I've done (as a superuser but net conf list required it earlier):
1. Copied all what's above to clipboard.
2. nano anyname.conf
3. Pasted.
4. Changed every read only = yes to read only = no and saved changes.
5. net conf drop (not sure if it is necessary but did it to clear earlier version)
6. net conf import anyname.conf
7. Reboot!

And now it works!
Thanks again @mk01 and hope it will help you, @Cre@tsheR, as well!

@biba

my feeling now is that the shares have been created initially with default setting (RO only). later even if you changed to RW, usbmount.conf was updated (so for completely new disk attached the share would be RW, but existing shares are not properly destroyed + recreated with new settings upon reboot. it was designed that way for Beta2 and since then this workflows have not been touched.

than means that now at the times of RC3 something on wheezy changed and broke the expected behaviour. And of course since Beta2 Wheezy delivered new pkg versions for almost all tools/programs related to that starting with init, initscripts, upstart, smb, libsmb and we can continue.

easiest solution (and more elegant than today) would be to migrate the hotplug storage shares config from net conf registry into net usershares. because their exact period validity is from creation until reboot. just two things to quick check there - if they survive smbd process restart (it would be ugly if on smbd crash + restart they disappeared or also disappeared because of running apt-get update on *smb* packages. second - their difference to share specified via full registry record is that we can't set all share relevant settings (the command accepts few limited options during creation, nothing more and doesn't allow later edit (they can be just removed).

maybe bibu you find 20-30min to recheck that ? looks like you feel comfortably with shell. if you confirm my two fears of too much useshare limitations, I will recheck the booting / share purge / recreation on boot.

To be honest, I'm not sure if I get it properly and I can't play with this RPi too much (it isn't mine). However, I did many restarts before my changes (every time was read only) and after (now no problems, remains read write). Also, I had done all methods like changing owner, changing mode etc., so my config may not be the same as the clean one. And really, shell isn't my strength I just know some commands I found on the Internet but that's all. Figured it out by logical thinking and --help
Sorry I couldn't help you more. Maybe there are some commands I could type but I'd rather not change anything there. Maybe file system is relevant – it is ext4.

(9th Oct, 2014 06:20 AM)bibu Wrote: [ -> ]Hey,
I got the same issue. However, thanks to you @mk01 I know what was going on and how to fix it. There was no problem with the package (it was the newest one).

Here comes the output of net conf list:

Code:

[XBMC]
        path = /media/XBMC
        guest ok = yes
        read only = yes
        browseable = yes
        read list = xbian
        write list = xbian
        force user = xbian

[Backup]
        path = /media/Backup
        guest ok = yes
        read only = yes
        browseable = yes
        read list = xbian
        write list = xbian
        force user = xbian

[xbmc-backup]
        path = /xbmc-backup
        read only = no
        guest ok = yes
        force user = root
        browseable = yes

XBMC and Backup are labels of my partition, xbmc-backup share is made by xbian I guess.

So here is what I've done (as a superuser but net conf list required it earlier):
1. Copied all what's above to clipboard.
2. nano anyname.conf
3. Pasted.
4. Changed every read only = yes to read only = no and saved changes.
5. net conf drop (not sure if it is necessary but did it to clear earlier version)
6. net conf import anyname.conf
7. Reboot!

And now it works!
Thanks again @mk01 and hope it will help you, @Cre@tsheR, as well!

Thank you both! After trying everything I could think of for hours, this worked perfectly.

Hi!

I had the exact same problem and was fiddling around without success. Then this "net conf" stuff solved my problem.

Thanks for sharing.

I see this xbian behaviour as a bug. Is it already put into xbian's the bug tracking system?

Not sure, can you check and if not, post it?

(9th Oct, 2014 10:36 PM)mk01 Wrote: [ -> ]@biba

my feeling now is that the shares have been created initially with default setting (RO only). later even if you changed to RW,
...
maybe bibu you find 20-30min to recheck that ? looks like you feel comfortably with shell. if you confirm my two fears of too much useshare limitations, I will recheck the booting / share purge / recreation on boot.

I can confirm that I did exactly what you described in exactly that order and it resulted in the described behaviour that I could not write to the share.