не пойму , почему у меня не работает Samba

посмотри сдес hxxp://www.rmschneider.com/writing/xp_and_samba.html

security = share

А вообще - Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу. - там профи в этом деле.

Посмотри здесь:Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу.
и попробуй внести ...рациональные дополнения в smb.conf

после этих дополнений (захожу на вдр логином root) у меня проблем с доступом не стало!

/etc/services-посмотри здесь все про порты

проблема наверное аппаратная и связана со свичем
можно попробовать переткнуть машины в другие порты,
сбросить свичь, посмотреть может он конфигурится.
попробуй зайти на его адрес браузером ...
может доку на свич внимательнее посмотреть или в инете поискать?

Переустанавливал только что ArVDR 0.5.2 и попутно решил настроить Самбу. Изменил в конфиге smb.conf строку

security = share

и добавил юзера без пароля:

smbpasswd nobody

Перезапуск Самбы - и я вижу ресурсы ArVDR в своей локальной сети.

МС

Варианта только два - разрешена ли запись в конфиге Самбы и прописаны ли права на запись на директорию, в которую собираешься писать. Другого не дано.

Цитата

Со слов пользователя romantik
видеть, то и я вижу ресурсы VDR в локалке и даже скачать с VDR могу, проблема в том, что по локалке на VDR я ничего залить не могу.

Я сравнил твой и мой конфиг, разница только в wins support = yes

#  interfaces = eth0   
  wins support = yes
  syslog = 1
  encrypt passwords = true
  passdb backend = smbpasswd 
  unix charset = UTF8
  display charset = UTF8

Попробуй ещё с этими параметрами поиграться

writeable = yes 
 guest ok = yes

Цитата

security = share

извените это было интересно когда у людей Windows for Workgroups 3.11 стоял.
А человек который дает совет по деактивации сменой /bin/sh -> /bin/false и одновременно открывает share как то не вяжется вместе.

Ты говоришь неправду. В Самбе до сих пор с успехом используются метод security = share. Ты намекаешь на несекьюрность этого метода? Так он позволяет закрыть паролем любой созданный в Самбе ресурс - ты об этом знаешь? Почитай что-ли документацию на Пожалуйста зарегистрируйся для просмотра данной ссылки на страницу. - возможно, в твоих будущих "дистрибутивах" появится действительно НАСТРОЕННАЯ Самба ;-))))

Цитата

Со слов пользователя free-x
извените это было интересно когда у людей Windows for Workgroups 3.11 стоял.
А человек который дает совет по деактивации сменой /bin/sh -> /bin/false и одновременно открывает share как то не вяжется вместе.

о! да я вижу достойного опонента!
Тогда читаем внимательно! [man smb.conf]

Цитата

security (G)

This option affects how clients respond to Samba and is one of the most important settings in the smb.conf file.

The option sets the "security mode bit" in replies to protocol negotiations with smbd(8) to turn share level security on or off. Clients decide based on this bit whether (and how) to transfer user and password information to the server.

The default is security = user, as this is the most common setting needed when talking to Windows 98 and Windows NT.

The alternatives are security = share, security = server or security = domain .

In versions of Samba prior to 2.0.0, the default was security = share mainly because that was the only option at one stage.

There is a bug in WfWg that has relevance to this setting. When in user or server level security a WfWg client will totally ignore the username and password you type in the "connect drive" dialog box. This makes it very difficult (if not impossible) to connect to a Samba service as anyone except the user that you are logged into WfWg as.

If your PCs use usernames that are the same as their usernames on the UNIX machine then you will want to use security = user. If you mostly use usernames that don't exist on the UNIX box then use security = share.

You should also use security = share if you want to mainly setup shares without a password (guest shares). This is commonly used for a shared printer server. It is more difficult to setup guest shares with security = user, see the map to guestparameter for details.

It is possible to use smbd in a hybrid mode where it is offers both user and share level security under different NetBIOS aliases.

The different settings will now be explained.

SECURITY = SHARE

When clients connect to a share level security server they need not log onto the server with a valid username and password before attempting to connect to a shared resource (although modern clients such as Windows 95/98 and Windows NT will send a logon request with a username but no password when talking to a security = share server). Instead, the clients send authentication information (passwords) on a per-share basis, at the time they attempt to connect to that share.

Note that smbd ALWAYS uses a valid UNIX user to act on behalf of the client, even in security = share level security.

As clients are not required to send a username to the server in share level security, smbd uses several techniques to determine the correct UNIX user to use on behalf of the client.

A list of possible UNIX usernames to match with the given client password is constructed using the following methods :

*

If the guest only parameter is set, then all the other stages are missed and only the guest account username is checked.
*

Is a username is sent with the share connection request, then this username (after mapping - see username map), is added as a potential username.
*

If the client did a previous logon request (the SessionSetup SMB call) then the username sent in this SMB will be added as a potential username.
*

The name of the service the client requested is added as a potential username.
*

The NetBIOS name of the client is added to the list as a potential username.
*

Any users on the user list are added as potential usernames.

If the guest only parameter is not set, then this list is then tried with the supplied password. The first user for whom the password matches will be used as the UNIX user.

If the guest only parameter is set, or no username can be determined then if the share is marked as available to the guest account, then this guest user will be used, otherwise access is denied.

Note that it can be very confusing in share-level security as to which UNIX username will eventually be used in granting access.

See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.

SECURITY = USER

This is the default security setting in Samba 3.0. With user-level security a client must first "log-on" with a valid username and password (which can be mapped using the username map parameter). Encrypted passwords (see the encrypted passwords parameter) can also be used in this security mode. Parameters such as user and guest only if set are then applied and may change the UNIX user to use on this connection, but only after the user has been successfully authenticated.

Note that the name of the resource being requested is not sent to the server until after the server has successfully authenticated the client. This is why guest shares don't work in user level security without allowing the server to automatically map unknown users into the guest account. See the map to guest parameter for details on doing this.

See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.

SECURITY = DOMAIN

This mode will only work correctly if net(8) has been used to add this machine into a Windows NT Domain. It expects the encrypted passwords parameter to be set to yes. In this mode Samba will try to validate the username/password by passing it to a Windows NT Primary or Backup Domain Controller, in exactly the same way that a Windows NT Server would do.

Note that a valid UNIX user must still exist as well as the account on the Domain Controller to allow Samba to have a valid UNIX account to map file access to.

Note that from the client's point of view security = domain is the same as security = user. It only affects how the server deals with the authentication, it does not in any way affect what the client sees.

Note that the name of the resource being requested is not sent to the server until after the server has successfully authenticated the client. This is why guest shares don't work in user level security without allowing the server to automatically map unknown users into the guest account. See the map to guest parameter for details on doing this.

See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.

See also the password server parameter and the encrypted passwords parameter.

SECURITY = SERVER

In this mode Samba will try to validate the username/password by passing it to another SMB server, such as an NT box. If this fails it will revert to security = user. It expects the encrypted passwords parameter to be set to yes, unless the remote server does not support them. However note that if encrypted passwords have been negotiated then Samba cannot revert back to checking the UNIX password file, it must have a valid smbpasswd file to check users against. See the chapter about the User Database in the Samba HOWTO Collection for details on how to set this up.
Note

This mode of operation has significant pitfalls since it is more vulnerable to man-in-the-middle attacks and server impersonation. In particular, this mode of operation can cause significant resource consuption on the PDC, as it must maintain an active connection for the duration of the user's session. Furthermore, if this connection is lost, there is no way to reestablish it, and futher authentications to the Samba server may fail (from a single client, till it disconnects).
Note

From the client's point of view security = server is the same as security = user. It only affects how the server deals with the authentication, it does not in any way affect what the client sees.

Note that the name of the resource being requested is not sent to the server until after the server has successfully authenticated the client. This is why guest shares don't work in user level security without allowing the server to automatically map unknown users into the guest account. See the map to guest parameter for details on doing this.

See also the section NOTE ABOUT USERNAME/PASSWORD VALIDATION.

See also the password server parameter and the encrypted passwords parameter.

SECURITY = ADS

In this mode, Samba will act as a domain member in an ADS realm. To operate in this mode, the machine running Samba will need to have Kerberos installed and configured and Samba will need to be joined to the ADS realm using the net utility.

Note that this mode does NOT make Samba operate as a Active Directory Domain Controller.

Read the chapter about Domain Membership in the HOWTO for details.

Default: security = USER

Example: security = DOMAIN

Показать весь код

Значит доки ты все же читаешь - приятно слышать! Это все очень круто, но в доке упоминается баг в WfWg (Windows for Workgroups - Винда 3.1 и 3.11, но никак не 98/Me/XP/NT/2000/2003) - вот он и позволяет обойти авторизацию. И все. Я не вижу других противопоказаний. А ты?

Кроме прочего, прошу заметить вот эту фразу:

If your PCs use usernames that are the same as their usernames on the UNIX machine then you will want to use security = user. If you mostly use usernames that don't exist on the UNIX box then use security = share.

Я считаю, что второй способ более чем подходит для ArVDR - я не думаю, что у человека имена пользователей на РС совпадают с именами в Linux'е

Цитата

Со слов пользователя free-x
о! да я вижу достойного опонента!
Тогда читаем внимательно! [man smb.conf]

я уже давно не пользовал Винду...но насколько я помню при подключении удаленного ресурса, выскакивает окно в котором запрашивает имя и пароль и они совсем не обязательно должны совпадать с локальными именами и паролями

а доки я читаю и на моем пути уже не одна настроенная самба с приколами которые не каждому 08/15 пользователю известны. Так что грызите гранит знаний, они вам пригодяться